Topic: imagediff

[DarkWolf]

Okay this started as a fairly simple project.  Make an application where you could move different images and have only the pixels that match in each image appear in the final result.  Have everything else appear as a neutral color.



Well I come to find that controls in .NET can't have a transparent background.  Transparent in .NET means, "take the color of the parent control/form" and make it the background color.  So I had to re-write the way the drag and drop worked and things rendered.  In the long run it ended up better as zooming was easier to accomplish.



Anyway, this is a beta release. I've been working on it off and on for two weeks and before I go to bed I want to at least release it here.  It's main purpose is to rip sprites, but it could have a mapping use as well methinks.  Anyway let me know what you think.  After all this experimenting I might get around to finishing Raw Candy too.



imagediff

[Maxim]

How exactly does it help rip sprites? As I understand it, it requires me to have two screenshots with the same sprite frame but different backgrounds, and then align them so the sprites line up, so the "diff" shows just the sprite. I presume the main reason for this is to deal with the "black on black problem" when you disable background layers. It may also mean that in cases where "sprites" are not really sprites, eg. they're "burned" into background layers, or it's just a PC game without sprite hardware, there's a possibility to isolate them automatically. But how does it make it any easier than just pixel-pushing? If I can make my sprite appear on different backgrounds then I can just choose one that doesn't have black, and flood-fill may way to isolation. That, or harass emulator authors to give non-black backgrounds.



Perhaps what I'm saying is: can you give an example?

[DarkWolf]

If you can disable layers or flood fill around the sprite then this tool isn't for you.  It's mainly for PC games and emulators without layer toggle.  Basically any situation where you'd have to delete the individual pixels around a sprite.



It is mainly for higher color graphics, or lower color graphics where dithering is used (flood fill doesn't help there).  I will try to create a visual example when I get home.

[DarkWolf]

Ok, I put together a quick example.  I did the stage backgrounds for Street Smart (Arcade version) not too long ago.  Some of the stages have the same spectators in the background, so I loaded up three of the stages and got the people in the crow as a result.  There are some stray pixels to edit out, but it beats doing all of them.







While doing this example I noticed I have some speed issues to workout.  I will try to do that this weekend and do a proper release.

[Revned]

Hmm, not quite what I had imagined when you first mentioned this. I thought you were talking about the longest-common-subsequence functionality of diff, not just comparing pixels with the ones beneath them. You could probably achieve this in Photoshop or similar tools using difference layers.



Regardless, I can definitely see the applications, though they're more suited for sprite ripping. I did run into something just a couple of weeks ago that this would have helped with, but I ended up doing something else altogether.

[DarkWolf]

Alright, I fixed some issues.  Large images are still a bit slow, but now the program doesn't grind to a halt when you drag other windows over it.  Also I added the feature to paste images from the clipboard with Ctrl+V.  The link in the first post is updated with the new url.

[Salemis]

Alright, I fixed some issues.  Large images are still a bit slow, V tight gel how it works? but now the program doesn't grind to a halt when you drag other windows over it.  Also I added the feature to paste images from the clipboard with Ctrl+V.  The link in the first post is updated with the new url.

yes large images queality are stills low