April 09, 2006

YCbCr

I have refactored quite a lot, and allowed the colourspace to be selected at mosaic build time. This lets me use the same tile index file and experiment with various colourspaces and weightings without rebuilding the index. I've built up the corpus to about 80 000 tiles, and since the vectors are held in RAM, I needed to move off my laptop and onto a machine with more RAM.

Here is a mosaic from a photo I took on Georgian Bay:

50 tiles wide from an 80k+ tile corpus.  YCbCr colourspace matching with an even weighting.

Here is a close up of a transition area (sky -> trees -> water):

zoomed view

The repeat limit was manhattan distance of 40, the build order was shuffled. I used the YCbCr colourspace, which I think performs way, way better than HSV/HSL. YCbCr is, I think, the 8-bit version of YUV, and I think that it does a good job of mapping colour perceptually. It gives two components to chroma, rather than HSVs one, which makes for a clean color match. I found that RGB tended to favour blue disproportionately... in fact primaries seemed to match more strongly. The YUV/YCbCr matching gives a softer, more 'real' and slightly more impressionistic feel, I think. I intend to run this again with just RGB, for a straight comparison of the two.

HSL/HSV also represent chroma as a loop... which means that at the 360-0 boundary, the maximum span, there is great similarity. This resulted in poor matches near the boundary. The two dimensional chroma space of YUV/YCbCr place perceptual extremes at the edges, with no wrapping. This means that matches appear good throughout the perceived colour gamut. I'm not a graphics expert in the least, so you'll excuse some heavy misuse of jargon and some similarly heavy glossing.

For those who want the full 4.3MB bomb, here is the full-size version (3750x6450 pixels). Be forewarned, I just selected the images based on license characteristics, I didn't review all 80k tiles for appropriateness, etc.

I think that the fine detail improves considerably as I add to the corpus, but obviously that is RAM limited. Each tile requires an in-RAM 75 element array to represent the vector. It also extends the runtime of the match linearly... this mosaic ran overnight, for about 9 hours.

 

Comments

Ooh, I'm glad YCbCr seemed to work out better.

RGB would seem to favour blue, as blue is the colour we perceive the least, so, with equal weighting, it would seem to be bluer. (That's why in the Y calculation, Green and Red are weighted most, and blue hardly at all).

It's really quite cool looking at the full picture and seeing the entire picture.

Out of curiosity, how are you downsampling to 5*5, and I'd also be curious how it would look at 10*10 (it'd be a quarter the size, but I'm curious as to how the details would fit) Wanna play!

Earlier (and before I had such a large corpus), I ran some tests with 10x10 and 15x15, and found that the details do in fact get mapped a bit more cleanly, but overall photos with much lower contrast are selected. It meant that overall, the image was a lot greyer and washed out.

Daniel tried with a 3x3, and the noise level was much higher, and basically all the detail was lost. I read somewhere that someone found that 5x5 was the sweetspot, and so far my minimal tests have borne that out.

For averaging, we are just resizing the tile to 5x5, and selecting the values for each pixel in the resulting image. This uses whatever the resize averaging GD uses, which it says is a "weighted average of the pixels". I'm not sure what the weighting is.