Spot The Difference (STD 1.3) *Updated* 04/11/13

[Xoemab]

About app
Compare the source image with compressed image and find the differences.

Please leave feedbacks and suggestions.

Installation guide (Windows Only):
No installation, the app is portable, smaller than 400kb, just download & run.

Download:
STD v1.3 (04/11/13)
STD v1.2 (29/10/13)
STD v1.1 (20/10/13)
STD v1.0 (19/10/13)

Source
STD v1.3

Changelog v1.3
-A lot of design changes
-Color comparison is 20x times faster than previous version
-Added drag and drop feature
-Added copy from clipboard feature (have strange bug will try to fix it in next versions)
-Added option to find color difference based on human perception (CIE76 algorithm - its 5x times slower than machine perception comparison)
-Changed algorithm of finding color difference based on machine perception (faster and more accurate)

Changelog v1.2
- A lot of design changes
- Added progress bar

Changelog v1.1
- Added error handler. (No more crashes only warning messages)
- Added default value for distance color percentage. (Default Value = 2)
- Added supported image file formats.

[raffriff42]

Sorry, but you are reinventing ImageMagick's compare.
Your name for it is "catchier" though...

[Xoemab]

I didn't know about ImageMAgick's, the idea came to me that time and after a quick google search I didn't find anything so I wrote it.. Still my app is 340kb and I have gui.. More to come who know maybe it will become better

[Sparktank]

Originally Posted by Xoemab

the app is just 336kb

Originally Posted by Xoemab

my app is 340kb

o_O That's a huge discrepancy!

Originally Posted by raffriff42

Sorry, but you are reinventing ImageMagick's compare.
Your name for it is "catchier" though...

Interesting. I keep seeing ImageMagick on this forum and other places but have not gotten around to seeing it's full potential. There seems to be quite a bit fun to be had with IM.

+1 for a GUI. Waiting for approval to give this a looksy.

Maybe after having my fun with this, I'll give ImageMagick a deeper look.
I like finding small programs like this. Simplistic and thought-provocative (as in I'm going to really expand my knowledge to similar projects; ie, IM).

EDIT1: Perhaps use a file host like MediaFire to share your app? Would save time from pending attachment approvals.

[Xoemab]

Now its approved.. tomorrow I will upload the updated version where I will add error handling, now there are many ways to make the program crash so if you testing it now and the program crashing just close and open it again... As I said I made it in hurry just wanted to see if anyone was interested

[Groucho2004]

Originally Posted by Xoemab

now there are many ways to make the program crash

Actually, I didn't manage to find a way to make it not crash...

[Xoemab]

Originally Posted by Groucho2004

Actually, I didn't manage to find a way to make it not crash...

First you should load 2 images (in my example I used 2 .png files, not tested other formats), second you should write distance color percentage range from 0 to 100, third press compare and it give you the output.

Note: The two images should have same resolution

Edit: If you still getting crash wait until tomorrow's update

[Xoemab]

I just uploaded the updated version STD v1.1

[Xoemab]

Uploaded STD v1.2.. the main differences is in the design (as you can see from video demonstration).

[wonkey_monkey]

I hope you'll take this as the constructive criticism it's meant to be, but STD seems incredibly slow for what it does (which is useful, don't get me wrong). What's it written in?

Have you considered implementing pasting images from the clipboard instead of opening files?

David

[Xoemab]

Originally Posted by davidhorman

I hope you'll take this as the constructive criticism it's meant to be,

Of course, criticism is very important for everyone that want to make his app better.

Originally Posted by davidhorman

but STD seems incredibly slow for what it does (which is useful, don't get me wrong).

The speed is depends on your cpu, for my bad cpu (AMD Athlon II P340 Dual Core 2.20GHz it took 13 seconds to compare two 1920x800 images which is not too much if you consider that it makes 1,536,000 times computations that needed to the color distance. I think you though that I just compare two pixels to see if their equal but I not, I using this algorithm. If I just compare for equality it would be much faster.

It wasn't slow for me but I understand that for someone 10-20 seconds is slow so I will try to optimize somehow my code and also will add parallelism.

Originally Posted by davidhorman

What's it written in?

It's written in C#

Originally Posted by davidhorman

Have you considered implementing pasting images from the clipboard instead of opening files?

I have considered to implement drag and drop but I also liked your idea, will add for sure this two features in next version

[wonkey_monkey]

Would you consider sharing your source code (or part of it) for examination? I would expect even a "slow" CPU like yours to be able to make such a comparison, even on HD images, in fractions of a second.

One optimisation springs to mind: if you want to check whether sqrt((r2-r1)^2+(g2-g1)^2+(b2-b1)^2) is less than x, do this comparison instead:

(r2-r1)^2+(g2-g1)^2+(b2-b1)^2 < x^2

to save yourself the square root (which is probably the most expensive part of your computation).

I would also recommend weighting your colour differences per channel, too, as the human eye is more sensitive to green, then red, then blue.

David

[Xoemab]

Originally Posted by davidhorman

Would you consider sharing your source code (or part of it) for examination? I would expect even a "slow" CPU like yours to be able to make such a comparison, even on HD images, in fractions of a second.

One optimisation springs to mind: if you want to check whether sqrt((r2-r1)^2+(g2-g1)^2+(b2-b1)^2) is less than x, do this comparison instead:

(r2-r1)^2+(g2-g1)^2+(b2-b1)^2 < x^2

to save yourself the square root (which is probably the most expensive part of your computation).

David you was right, it shouldn't take so much time, it was slow because I was using one built-in C# function to get pixel colour, I read that this built-in function is very slow and found alternative way, now it will need some miliseconds to find the difference even on shitty machine ... I will upload soon the updated version.

I will upload also the source code after cleaning my code a bit and adding some comments for better understanding.

Originally Posted by davidhorman

I would also recommend weighting your colour differences per channel, too, as the human eye is more sensitive to green, then red, then blue.

We don't need to take in consideration the human eye because we want to see how close is the pixel color to the source and not how close it is for human eyes.

[wonkey_monkey]

Originally Posted by Xoemab

We don't need to take in consideration the human eye because we want to see how close is the pixel color to the source and not how close it is for human eyes.

But ultimately all pixels are for human viewing. Encoders take this into account when they allow these differences in the first place (blue is allowed to be more different than green, very roughly speaking), so to me it would make sense to have this option.

Great that you've been able to speed it up!

David

[Gavino]

Originally Posted by davidhorman

I would expect even a "slow" CPU like yours to be able to make such a comparison, even on HD images, in fractions of a second.

As demonstrated by the Avisynth Compare filter.

[Xoemab]

Originally Posted by davidhorman

But ultimately all pixels are for human viewing. Encoders take this into account when they allow these differences in the first place (blue is allowed to be more different than green, very roughly speaking), so to me it would make sense to have this option.

Great that you've been able to speed it up!

David

Oh if so then I will add 2 options, the one I have and one for human eye so everyone could be happy

[Xoemab]

Originally Posted by Gavino

As demonstrated by the Avisynth Compare filter.

Do you mean that Compare filter do what STD do? If yes then the answer is no, the compare filter doesn't do what STD do and vice versa.

[wonkey_monkey]

If you're still open to suggestions, I had an idea that I'd find useful - using left/right arrows to switch between original, compressed, and original+red overlay. Then you could easily flip between any two of those, so you could use the red overlay to find the differences and then flip between original and compressed to compare small areas of difference.

[Xoemab]

Originally Posted by davidhorman

If you're still open to suggestions, I had an idea that I'd find useful - using left/right arrows to switch between original, compressed, and original+red overlay. Then you could easily flip between any two of those, so you could use the red overlay to find the differences and then flip between original and compressed to compare small areas of difference.

Yeah its good idea, I had planned this for future version, I though instead of having two windows I will do like AviSynth, one window with tabs and you will switch between tabs like you said with arrows or mouse.

I was overwriting the compressed image with compressed+red but I think your idea is great to keep also the compressed. So in the next version there will be a lot of changes.. I think tomorrow it will be ready.

[Xoemab]

Added STD v1.3 with a lot of changes (see changelog, try the application). I also added the source code for anyone that want to help to improve the program.