cloister
Full Member
Offline
Posts: 138
Re: Creating Mosaics from Photographs
Reply #7 - Mar 1st , 2009, 5:04am
Johnny-- I've been reading your write-ups, and three ideas occur to me that would probably help your mosaics a lot: 1. There are a lot of ways you can compare two colors to see which is closer, some of which will work better than others for this and similar tasks. I would encourage you to compare the results you get from different color difference metrics to pick one that works better than simple RGB difference. Sure, RGB is easy because computers fundamentally work in RGB, but the sensitivities of human vision are modeled much better by the HSB color space. In particular, humans are VERY sensitive to changes and alterations in brightness, and considerably less so to variations in hue and saturation. If you don't believe me, try this sometime: separate an image into its hue, saturation, and brightness channels. Apply a mild gaussian blur to the brightness channel only; leave the hue and saturation channels alone. Now reconstitute the image and be amazed at how obvious that minor blur in the brightness channel is. Repeat the experiment with blurs in hue and saturation only. I guarantee that you'll get some insights into how people perceive color and what some better ways are to compare two colors. 2. Instead of looking for the image with the smallest cumulative color difference (no matter what metric you're using), try using a least-squares fit or other mathematical definitions of error that have better statistical properties. Wikipedia has a good write-up of least squares if you don't remember the math from school, or you can e-mail me. 3. Instead of comparing pixel-by-pixel, you could attempt to match sub-regions of each image with the average colors of sub-regions in the target image. This would have two advantages: it should be faster, because you can pre-compute the sub-region color averages for all the images in your pool of pictures, and cache them. When you're working on a pixel-by-pixel basis, it makes no sense to try to cache anything, and as a result your code is going to be really slow. Careful choice of the number of sub-regions (e.g. 2x2 or 3x3 or 4x3 or whatever) should enable you to balance compute time with fidelity in matching, while still doing a good job with matching the source image's structure to the target image's structure. Feel free to send me a message if you'd like clarification on any of those ideas.