So Im looking at an image and trying to select one from a set of other images that is the most similar (least different).
Currently I simply look at the average difference between the RGB parts of each pixel, but this has a tendency of picking grey colors. If half the picture is white and the other is black, it's going select some grey shade even though there is no grey in the picture.
I'm assuming there are better algorithms to compare images or trying to achieve what I'm trying to do.
Note that the actual content of the image is not that interesting, just that the colors "look" similar.
For the record what Im trying to do is match someones clothing to a texture-file, if that makes any difference.
Any suggestions or points in the directions of some resources would be greatly appreciated.
EDIT: My solution was to remove the grey colors from the set I was selecting from and it worked pretty well, if anyone else have any better solutions feel free to post.
I just posted this yesterday, I don't want to duplicate the post, but it is very similar.
Making smaller Bitmaps from a Bitmap object
My open source project Transparency Maker creates a Pixel Database, which is actually a list of PixelInformation objects.
Each pixel has properties for Red Green Blue of course, but there are also properties for Total, BlueGreen, BlueRed, and GreenRed, which is just the sum of Blue + Green, Blue + Red, etc.
You can then do Linq queries or for each loops and compare the total for two Pixels (Pixel Information class), and then you can compare on different things like:
Comparing the totals is as easy as:
int difference = pixel1.Total - pixel2.Total;
Which is the same as typing all this if you are using a standard BitMap:
int redDiff = Pixel1.Red - Pixel2.Red;
int green = Pixel1.Green - Pixel2.Green;
int blueDiff = Pixel1.Blue - Pixel2.Blue;
int diff = redDiff + greenDiff + blue;
As a thought, you could refine your algorithm to where each difference gets weighted more,
so for the above the last line could be:
int difference = (redDiff * 17) + (greenDiff * 17) + (blueDifference * 17);
I just made up 17 as an example, what value for weight you use it is up to you.
In theory, the above would give you a closer number to closer images.
Here is the link to my open source project if you want the full code:
https://github.com/DataJuggler/TransparencyMaker
Maybe this will give you some ideas.
Related
I have an RGB image.Suppose say I have two circles in it.I want to know which one is filled and which one is not.I followed the following steps:
-imported the image as Bitmap
-converted into grayscale and used CannyEdgeDetector filter to find the edges. I get the following image
circle containing the letter "D" gives two edges, where as I need only one circle edge. Secondly, how do I find out which circle is filled and which one is not.
For the MCQ answers sheet, it might be easier to go by positions of the circles.
Just compare stock images of the clear, circled A, B, C and D's to the scanned images and see which differ the most. A simple darkness summation might be enough.
Also: Comparing the circles against each other might be useful too to compensate for a bad/dark/light scan or smudgy paper.
For special cases if the test isn't absolutely sure I'd probably pass it to a human being for further investigation. E.g., when you allow students to undo an answer by circling their second guess or when a student decides to make a real mess by using a bad eraser.
Final tip: make sure you do not accept answers that have the correct circle filled; make sure the other circles are clear at the same time so students can't cheat by filling all circles. (Some professors use a paper mask that overlays all bad answers so they can quickly spot unmarked correct answers. But if the student just marks all answers this fails big time.)
I would not know any "formal" algorithm matching your criteria. I would also doubt that you would find any.
When you say the circles are "darkened", this can be interpreted as this: "Many pixels (above a population threshold) would be black, or at least dark (above a colour threshold).". Based on known circle and radius, I would follow this approach (written in pseudocode but I suppose you get the meaning):
//define thresholds
colourThreshold=...
populationThreshold=...
centerPoint = getCircleCenter();
radius = getCircleRadius();
darkPixelsCount = 0;
for(x=centerPoint.X-radius;x<centerPoint.X+radius;x++){
for(y=centerPoint.Y-sqrt(abs(radius^2-(x - centerPoint.X)^2));centerPoint.Y+sqrt(abs(radius^2-(x - centerPoint.X)^2));y++){
if (image(x, y) > colourThreshold){
darkPixelsCounter++;
if(darkPixelsCounter > populationThreshold){
//If you reach this point, circle has been darkened
return;
}
}
}
}
//If you reach this point, circle has not been darkened
return;
I don't know if it is efficient, or if there is a more elegant way to do it. I suppose you could play with performance and accuracy by moderating the thresholds.
Hope I helped!
Perform blob detection, with a pixel count
or even simpler count the black pixels
or even simpler and faster, take middle line and count how often it switches from white to black
How can I set the colour of every pixel in a image to it's closest colour match from a list of colours in RGB format (no alpha), that can be of any length, in C#?
It's basically creating a custom BitmapPalette, but since you can't do that
(Trust me, I've tried everything possible for that), I need an alternative.
Does anyone know a way to do this?
Boy...I hope you loves your maths...
This is a tough question. To determine the "closeness of fit" between two colors, you first must understand the color space/color model in which your are working. The RGB color model (not counting the alpha channel) is essentially Euclidean in nature: each color maps to a point in 3D space. Ergo, the putative distance between two colors, C1 and C2 is
Distance = SQRT( (C1red - C2red)2 + (C1green - C2green)2 + (C1blue - C2blue)2 )
WRT "normal" human visual perception, this is not necessarily correct. To take that into account gets much more complicated.
Try these two papers as jumping-off points:
Colour Metric
The Color FAQ
The Color FAQ also provide many links to other colorspace resources.
Some more links at http://www.golden-gryphon.com/software/misc/color-links.html
Here's a paper on color differences that might help also: http://www.axiphos.com/Reports/ColorDifferences.pdf
Bruce Lindbloom's web site has lots of stuff as well, including a color difference calculator, that works in the CIE color space (which has provision for distance computations).
ColorMine is open source C# library that has methods for converting between color spaces and comparing via a couple delta-e methods
For example, this will give you a similarity score based on the most common delta-E method (Cie76)
var a = new Rgb { R = 23, G = 117, B = 114 }
var b = new Rgb { R = 113, G = 27, B = 11 }
var deltaE = a.Compare(b,new Cie1976Comparison());
I am using webcamera in C# (using AForge). I also have some default background. I need to extract the difference between current image and background and create a new image which contains only the objects which are not present on the default background. For example, if I move my hand in front of webcamera, I need to output only that hand (with the rest of backgound white). If I just compare pixel by pixel it gets ugly, since there is a lot of noise. I have tried using threshold value for difference, but the result is still very bad. I think that maybe there is some filter or a known algorithm how to do that? Any help would be very much appreciated.
You can always try to compare the grayscale images of the two. Assuming that your webcam is stationary (because if not, then you would have to do much more adjusting to pixel shifts), then you can convert the images to grayscale, and have a threshold by which you think the images differ:
int threshold = 30;
PixAvg1[i,j] = (Pix1.R + Pix1.G + Pix1.B)/3
PixAvg2[i,j] = (Pix2.R + Pix2.G + Pix2.B)/3
if (Math.Abs(PixAvg1[i,j] - PixAvg2[i,j+1])>threshold)
difPixel == true;
The threshold is how much tolerance between the pixels you want to get. That value can come from the difference in brightness of the images.
With this you won't get the crispiest results, because some pixels you cover will match, however, you can then run an extra scan (if you want), and doing some kind of an area fill.
I have a picture:
size of 1000x1000 white with random black dots. (It may contain a black square (size 50x50))
Is there an easy way to know if the picture contains a black square (size 50x50)? I thought of scanning every pixel of the picture and if a black pixel was found, scan the one next to him till I get a 50x50 square or till I get a white pixel and keep scanning. but it will have to scan over a million pixel (if he hasn't found the square).
Thats the basically the code (no need to complete it, as I said before, it will take way too much time to scan it. million times if the whole picture is white and a lot more according to the number of black pixels.)
for (int i = 0; i < pic.Width; i++)
{
for (int j = 0; j < pic.Height; j++)
{
if (pic.GetPixel(i, j) == Color.Black)
{
//Search for the entire square at that area
}
}
}
And yes, time is important (thats why I don't want to get pixel over a million times). Any ideas?
Like the Boyer-Moore string searching algorithm, if the item you are looking at is not part of what you are looking for, you can skip the whole size of the what you are looking for. In your case, you can check to see if a given pixel is black. If it's not, you can skip forward 50 pixels. If it is, you have a small box to look for your black square in.
In this case, though, you may not need anything so complicated. I'm guessing that if your algorithm is too slow it's because you're calling the GetPixel function a million times, and that is the slow part. If you can get your pixels into a 2D array, your algorithm will probably go fast enough to not need to be rewritten.
Assuming that you're using a System.Drawing.Bitmap check out the LockBits documentation to see a small sample that includes copying a bitmap to a 1D array for super-fast access.
If you are only looking for a square of a specific size, then you can optimise this by only scanning every 50th row (or column) of pixels, thereby cutting your workload dramatically.
Theoretically, you only need to check for a black/white in 1 pixel from every 50x50 block. If it's black, then you try spreading from there, if it's white then just skip to the next block: clearly there is a white pixel in this block so there isn't a black box here. Following this, you've already cut your work to 1 / 2500th of what it was originally, you are now only checking 400 pixels initially.
Usually the best optimisations, especially when first designing an algorithm, are around reducing work done rather than doing it more efficiently. Try to think of creative ways to reducing the input to a more manageable size.
check out AForge.net framework suite. It has imaging library with Blob and pattern searching. You can search shapes too. Its free.
You can find it here http://www.aforgenet.com/framework/
Here is the link that lists features
http://www.aforgenet.com/framework/features
Edit
Here is the sample for shape checking. I have used Aforge in a prototype and it worked for me.
http://www.aforgenet.com/articles/shape_checker/
I am looking for an EASY way to check if an image is a scaled version of another image. It does not have to be very fast, it just should be "fairly" accurate. And written in .NET. And for free.
I know, wishful thinking :-)
I am pretty sure, even without having tried it, that converting the bigger image to the smaller scale and comparing checksums is not working (especially if the smaller version was done with another software then .NET).
The next approach would be to scale down and compare pixels. But first of all, it seems like a really bad idea running a loop over all pixels with a bool comparison results, I am sure there will be some pixels off by a bit or so...
Any library coming to mind? Way back in the university we had some MPEG7 classes, so I am thinking about using a combination of "statistics" like tone distribution, brightness, etc..
Any ideas or links for that topic?
Thanks,
Chris
I think this is going to be your best solution. First check the aspect ratio. Then scale the images to the smaller of the 2 if they're not the same size. Finally, do a hash comparison of the 2 images. This is a lot faster than doing a pixel compare. I found the hash compare method in a post from someone else and just adapted the answer here to fit. I was trying to think of the best way to do this myself for a project where I'm going to have to compare over 5200 images. After I read a few of the posts here I realized I already had everything I needed for it and figured I'd share.
public class CompareImages2
{
public enum CompareResult
{
ciCompareOk,
ciPixelMismatch,
ciAspectMismatch
};
public static CompareResult Compare(Bitmap bmp1, Bitmap bmp2)
{
CompareResult cr = CompareResult.ciCompareOk;
//Test to see if we have the same size of image
if (bmp1.Size.Height / bmp1.Size.Width == bmp2.Size.Height / bmp2.Size.Width)
{
if (bmp1.Size != bmp2.Size)
{
if (bmp1.Size.Height > bmp2.Size.Height)
{
bmp1 = (new Bitmap(bmp1, bmp2.Size));
}
else if (bmp1.Size.Height < bmp2.Size.Height)
{
bmp2 = (new Bitmap(bmp2, bmp1.Size));
}
}
//Convert each image to a byte array
System.Drawing.ImageConverter ic = new System.Drawing.ImageConverter();
byte[] btImage1 = new byte[1];
btImage1 = (byte[])ic.ConvertTo(bmp1, btImage1.GetType());
byte[] btImage2 = new byte[1];
btImage2 = (byte[])ic.ConvertTo(bmp2, btImage2.GetType());
//Compute a hash for each image
SHA256Managed shaM = new SHA256Managed();
byte[] hash1 = shaM.ComputeHash(btImage1);
byte[] hash2 = shaM.ComputeHash(btImage2);
//Compare the hash values
for (int i = 0; i < hash1.Length && i < hash2.Length && cr == CompareResult.ciCompareOk; i++)
{
if (hash1[i] != hash2[i])
cr = CompareResult.ciPixelMismatch;
}
}
else cr = CompareResult.ciAspectMismatch;
return cr;
}
}
One idea to achieve this:
If the image is 10x10, and your original is 40x40
Loop each pixel in the 10x10, then retrieve the 4 pixels representative of that looped pixel.
So for each pixel in the smaller image, find the corresponding scaled amount of pixels in the larger image.
You can then take the average colour of the 4 pixels, and compare with the pixel in the smaller image. You can specify error bounds, IE -10% or +10% bounds are considered a match, others are considered a failure.
Build up a count of matches and failures and use the bounds to determine if it is considered a match or not.
I think this might perform better than scaling the image to the same size and doing a 1pixel:1pixel comparison as I'm not sure how resizing algorithms necesserially work and you might lose some detail which will give less accurate results. Or if there might be different ways and methods of resizing images. But, again I don't know how the resize might work depends on how you go about doing it.
Just scale the larger image back to the size of the smaller one, then compare each pixel by taking the absolute value of the difference in each of the red, green and blue components.
You can then set a threshold for deciding how close you need to be to count it as a match, e.g. if 95%+ of the pixels are within 5% of the colour value, you have a match.
The fuzzy match is necessary because you may have scaling artefacts / anti-aliasing effects.
You'll have to loop over the pixels at some point or another.
Something that is easy to implement yet quite powerful is to calculate the difference between individual color components (RGB) for each pixel, find the average, and see if it crosses a certain threshold. It's certainly not the best method, but for a quick check it should do.
I'd have said roughly what Tom Gullen except I'd just scale down the bigger image to the smaller before comparing (otherwise you're just going to have hard maths if you are comparing a 25x25 with a 30x30 or something).
The other thing I might consider depending on image sizes is to scale them both down to a smaller image. ie if you have one that is 4000x4000 and another that is 3000x3000 then you can scale them both down to 200x200 and compare them at that size.
As others have said you would then need to do a check with a threshold (preferably on colour components) and decide what tolerances work best. I'd suggest this is probably best done by trial and error.
The easiest way is just to scale the biggest image to the smaller images size and compare color difference. Since you don't know if the scaling is cubic or linear (or something else) you have to accept a small difference.
Don't forget to take the absolute value of each pixel difference. ;)
Having absolutely no authority or experience in this area I'm going to make a stab at helping you.
I'd start with the aspect ratio matching by some tolerance, unless you're comparing cropped sections of images, which will makes things a bit harder.
I'd then scan the pixels for regions of similarity, no exactness, again a tolerance level is needed. Then when an area is similar, run along in a straight line comparing one to the other, and find another similarly coloured area. Black & white's gonna be harder.
If you get a hit, you'll have two areas in a line with patches of likeness. With two points you have a reference of length between them and so now you can see what the scaling might be. You could also scale the images first, but this doesn't account for cropped sections where aspects don't match.
Now choose a random point in the source image and get the colour info. Then using the scale factor, find that same random point on the other image and see if the colour checks out. Do it a few times with random points. If many turn up similar it's likely a copy.
You might then want to mark it for further, more CPU intensive, inspection. Either a pixel by pixel comparison or something else.
I know Microsoft (Photosynth) use filters like "outline" (the sort of stuff in Photoshop) to remove the image colours and leave just squrly lines which leave just the 'components' of the picture for matching (they match boundaries and overlap).
For speed, I'd break the problem down into chunks and really think about how humans decide two photos are similar. For non-speed, exhaustively comparing colour will probably get you there.
The process in short:
If you hole punched a sheet of paper randomly 4 times, then put it over two photos, just by seeing the colours coming through you could tell if they were likely a copy and need further inspection.