Pixel-by-pixel comparison each frame
BlitzMax Forums/BlitzMax Programming/Pixel-by-pixel comparison each frame
| ||
| I am looking for the fastest way to go about this: Execute some drawing commands Do a pixel-by-pixel read of the resulting image, comparing it to another set of data If necessary, revert image to the state it was in before the drawing operation. Do it all over, again on the new image. I had this (somewhat) working many months ago, but it was just too slow. I fiddled around with different combinations of pixmaps, and TImages, and various pixel reading strategies, and OpenGL commands, but I could never get a decent speed except on tiny images. I also tried breaking the image up into segments and only checking dirty panels, but that didn't help much and made the program way more complex than I intended. If anyone has suggestions on streamlining the process listed above, let me know. I don't mind using third-party libraries, but I'd rather not have to wrap them, myself. Any help would be appreciated. |
| ||
| That is never going to be fast. What are you trying to do? Perhaps there could be another way. Or perhaps a faster, but not 100% accurate, method could be devised. If it's for a game, you'd be suprised how unnoticable <100% can be for many things. Last edited 2011 |
| ||
| No, it isn't for a game, so I don't need 60 (visual) frames per second, but the faster the better. In a nutshell, I want to compare two images every frame to see if they have become more similar or less similar. If they have become more similar, I carry on. If they have become less similar, or there has been no change, I want to revert the image to its previous state. If it's faster, I can revert the image by re-executing all the drawing commands that have led it to its current state, minus the ones from the current frame. I only need to draw to one of the images. |
| ||
| You'd probably be better off with C++ or something, and "drawing" them to a buffer in memory instead of a real graphic. It might be faster to keep copies of the images at different stages rather than redrawing them from scratch each time you revert, if that takes a long time. Have you profiled the code to determine which step takes longest? How do you define more similar? |
| ||
| Yeah, I thought about taking a stab at this in C#. BlitzMax long ago became my go-to language for reasonably simple graphics-oriented projects, though. I fiddled with arrays for a while, but you can eat up some serious RAM that way. Keeping different copies is what I was doing when I was grabbing the entire image each frame. I would simply put back the grabbed image from the last frame if I needed to roll back the image state. The vast majority of time was burned in grabbing and releasing pixmaps, if I remember correctly. I can't recall exactly which function it was. Similarity is a pixel-by-pixel comparison using the RGB values of the pixels. So, you sum the fitness of each individual pixel into an overall total. If the fitness goes up, we keep the changes, if the fitness goes down, we revert to the previous state. Last edited 2011 |
| ||
| if you can post some code I might be able to help you figure out the best alternative. there might be a better way or not. |
| ||
| You ever go back and look at your own code after a really long time? Yeah. I seem to have left the program in a broken state, and I have no idea where to start getting it back to where I had it when it was workingish. I was planning to just start from scratch. I'll see if I can just dig out the bits that ate all the time. |
| ||
| sounds like your trying to do the old 'mona lisa evolution with genetic algorithms'. If so, your method is not really the best way. I wrote a bmax version the day roger alsing announced it back in '08 (b4 he released the source), your welcome to it, but you can get the jist of it by looking at his source as well. |
| ||
| I am working on something similar, but not exactly like Alsing's program. In fact, I've already done it, it worked fine, but it was too slow to make me happy. What part of my approach is wrong, in your opinion? |
| ||
| Just the part about reverting to a previous image. The way I did it was create a fixed population of pixmaps. Then do a squared error calcutlation between the source pixmap and each updated pixmap. pixmaps that didn't mutate for that generation would be skipped. I never kept the drawn images between generations, just the drawing commands. That way your most fit image(parent) can be cloned(to children) much faster. If you need to clear the pixmap 'Clearpixels' is pretty fast and so is just replacing it with a new pixmap. Also when doing the squared error check between pixels you can try doing every other pixel or less to get a the same fitness measurement. |
| ||
| dunno but maybe this is a fast way : copy both images to a bank and compare the banks with some "C" or asm code Last edited 2011 |
| ||
| You could also try using a histogram compare-- tally all the values for each color R,G,B and use that to compare to other histograms. You could even break it down further (split R,G,B in half). If brute force comparing takes too long, you could try alternating pixels or randomizing the sample pixel set. Last edited 2011 |
   |