Hi,

I am developing an application to verify firmware for an embedded device. 
One aspect involves verifying the display of the device.  What I'm doing now 
is rendering an image of what the screen *should* look like alongside a 
video frame of what the device is actually displaying, then asking the user 
"Do these two images match?" - it works, but of course there is the human 
error factor and it is a bit easy for the user to just press the "yes" 
button without really looking at the images.

I would rather compare the two images programmatically.

Here is an example of the images I need to compare:

Source Image:
http://pmddirect.com/temp/LCD%20screen%20photo.jpg

Rendered image to compare to:
http://pmddirect.com/temp/rendered%20LCD%20output.jpg

It's hare to tell from looking at the images separately, but they aren't 
exactly the same.  The LCD font that I'm using to render the "expected" 
display output has slightly different pixel spacing (simulated LCD).  A 
pixel by pixel comparison would surely fail.  I've evaluated a couple 
different OCR solutions but haven't been able to find one that can 
accurately recognize the captured display output.

I'm VERY new to GDI (and graphics work in general) and I'm not aware of 
other comparison techniques or algorithms for evaluating VERY similar, yet 
different images.  One idea I had was to work with blocks of pixels, say 
5x5, convert pixel RGB values to hue and compare the sum of the block's hue 
against the other image's same block.  It might not make any sense, just 
seems like it would allow some degree of variance while still being accurate 
enough to determine if the area is similar.   Of course the block size 
depends on the resolution of the image and would be adjusted accordingly.

That's it for ideas on my side ;0)

I would REALLY like to know if there are better techniques out there, I'm 
sure some of you see these images and know of a much better solution than 
the one I have mentioned.  Performance is an important factor, I would like 
to compare several images a second.  I haven't worked with GetPixel() enough 
to know just how slow it is, but if it's too slow I understand the 
alternative is to go unsafe and hit the pixels with a pointer.  I'm fine 
with that.

That's it, thanks for reading and like I said, I would really appreciate 
some guidance or suggestions on this problem.

-Steve

Quiet NG...  ;0|

In case anyone has read this post and is curious, my design is working 
pretty well.  Currently I'm dealing with the old issue of "garbage in, 
garbage out" - I need to add some code to adjust for "registration issues" 
(EG: slight rotation in one image, slightly different positioning, etc)

Here are some screen shots of the testbench application.  If anyone has any 
thoughts on adjusting the registration of the two images to better prepare 
them for analysis I would really like to here them.

Sample using a block size of 8 pixels square
http://www.pmddirect.com/temp/image%20compare%208%20block%20size.PNG

Sample using a block size of 20 pixels square
http://www.pmddirect.com/temp/image%20compare%2020%20block%20size.PNG

I'm comparing the sum of the luminance (brightness) for each block.  An 
initial calibration step before each batch is processed would most likely 
yield far better results.
Comments, suggestions, etc very welcome.

-Steve

"sklett"  wrote in message 
news:eIy0eSb3HHA.4676@TK2MSFTNGP05.phx.gbl...

> Hi,
>
> I am developing an application to verify firmware for an embedded device. 
> One aspect involves verifying the display of the device.  What I'm doing 
> now is rendering an image of what the screen *should* look like alongside 
> a video frame of what the device is actually displaying, then asking the 
> user "Do these two images match?" - it works, but of course there is the 
> human error factor and it is a bit easy for the user to just press the 
> "yes" button without really looking at the images.
>
> I would rather compare the two images programmatically.
>
> Here is an example of the images I need to compare:
>
> Source Image:
> http://pmddirect.com/temp/LCD%20screen%20photo.jpg
>
> Rendered image to compare to:
> http://pmddirect.com/temp/rendered%20LCD%20output.jpg
>
> It's hare to tell from looking at the images separately, but they aren't 
> exactly the same.  The LCD font that I'm using to render the "expected" 
> display output has slightly different pixel spacing (simulated LCD).  A 
> pixel by pixel comparison would surely fail.  I've evaluated a couple 
> different OCR solutions but haven't been able to find one that can 
> accurately recognize the captured display output.
>
> I'm VERY new to GDI (and graphics work in general) and I'm not aware of 
> other comparison techniques or algorithms for evaluating VERY similar, yet 
> different images.  One idea I had was to work with blocks of pixels, say 
> 5x5, convert pixel RGB values to hue and compare the sum of the block's 
> hue against the other image's same block.  It might not make any sense, 
> just seems like it would allow some degree of variance while still being 
> accurate enough to determine if the area is similar.   Of course the block 
> size depends on the resolution of the image and would be adjusted 
> accordingly.
>
> That's it for ideas on my side ;0)
>
> I would REALLY like to know if there are better techniques out there, I'm 
> sure some of you see these images and know of a much better solution than 
> the one I have mentioned.  Performance is an important factor, I would 
> like to compare several images a second.  I haven't worked with GetPixel() 
> enough to know just how slow it is, but if it's too slow I understand the 
> alternative is to go unsafe and hit the pixels with a pointer.  I'm fine 
> with that.
>
> That's it, thanks for reading and like I said, I would really appreciate 
> some guidance or suggestions on this problem.
>
> -Steve
>