Comments on The Lowly Programmer: Visualizing RGB, take two

Ok, the follow-up post is now up detailing the res...

2010-03-17T00:55:59.037-04:00

Ok, the follow-up post is now up detailing the results of adding error diffusion. Sorry for the delay!

Adding a priority mask turned out to be a bad idea, as it didn't really change the image perceptually except by making a hard division between the sky and buildings.

Re-running the luminance experiments with the new version gives results similar to before - I'm thinking that my algorithm is not really equipped to deal with minor variations in the colour scheduling algorithm like that. Still, it was worth a try.

Quick update (I'll post the pictures and expla...

2010-02-25T17:18:41.584-05:00

Quick update (I'll post the pictures and explain better when I have some real time): I implemented error diffusion, and it makes a huge difference, especially with the 4096x4096 images. Capping the error terms lets me trade off uniform noise and graying-out with the "hot" colours, which turns out to be a good trade-off to make. It can reproduce the original image considerably better now and the sky becomes a uniform noise in the places it was going psychedelic before, which I think is an improvement.

A version with the sky masked as low priority is generating now as well, so I'll see if that makes a difference as well tomorrow or so.

I'll try it against Mona Lisa next, for comparison to http://allrgb.com/mona-lisa-ycrbr.

Ok, I tried varying the luminance as you suggested...

2010-02-21T13:52:46.684-05:00

Ok, I tried varying the luminance as you suggested:

1/8: 2_allRGBv2_L1%8.png
1/4: 2_allRGBv2_L1%4.png
1/2: 2_allRGBv2_L1%2.png
1: 2_allRGBv2_L1.png
2: 2_allRGBv2_L2.png
4: 2_allRGBv2_L4.png
4: 2_allRGBv2_L8.png

At low values in either direction there is not too much change, and at higher values the increase in noise kills off any gains there might be. However, I'm interested in your idea of adding error diffusion, which after looking into it I think has a lot of promise for this algorithm. I will try it out next, and assuming it does as well as expected, I will re-run the luminance experiments with it turned on.

I agree about the sky, in your image and mine as well. It is just too large in area for the current algorithms to have a hope with, I suspect. We'll see how it changes with error diffusion.

This one took a few hours, I really don't like...

2010-02-21T12:07:21.251-05:00

This one took a few hours, I really don't like what it did with the sky.

http://churchturing.org/y/lowly-programmer-scaled.png.8.0.4096.29.png

If you want to display photos the problem is how to do take a fixed set of pixels and present the photo in such a way that is perceptually similar. In most cases it can't be exact. If you look at a lot of the AllRGB entries you'll see that they get away with it because they simply resized the image so the small details are not needed. If you want small details to be important then you'll have to be more careful where you hide the noise.

This is like the MP3 problem, you have so much signal to share, but what part of the signal do you really need and can you hide the error. If it is piano music there's no where to hide the error.

You could try error diffusion or a dithering algorithm. It'll have to be changed a little to deal with permutations.

Thanks for the render! I do like how yours comes o...

2010-02-20T23:21:08.610-05:00

Thanks for the render! I do like how yours comes out a lot smoother - I assume it's the same basic algorithm you described on http://allrgb.com/high-quality-render-of-wedding-photos ? I'm definitely going to have to sit down and think about it a lot more.

I hadn't realized luminance was the dominant component in human perception - I would have thought hue would be. I will try generating a couple low-res versions with my program tomorrow when I get home using different luminance multipliers, so we'll see how much difference that makes. Although I will note that I tried changing the hue multiplier on a different image without much luck, so it may be that luminance works the same way. Part of the problem is simply having a constant set of colours to work with.

I thought I'd give your picture a try, so I di...

2010-02-20T21:15:50.345-05:00

I thought I'd give your picture a try, so I did a low res render that took about 1.5 hrs. It did 30 iterations of optimally swapping pixel sets of size 4, using YCrBr color distance (with 4*Yd). Generally though larger pixel sets (8, 32, 128) produce better color mappings.

I am not happy with the results. There is much more detail in the picture that is for sure but the sky is a great example of not quite overfitting but just something not that tasteful. Those smearing fuzzy edges really bother me. Also I wish there was a bit more definition in the decoration.

I think you should try HSL against except weight L higher. Luminence is main component in our perception in an image, this is why videos are often encoded at 4:2:2 or 4:1:1, because the brightness and darkness is more important to our perception than the color. That said in both of our cases we're left with very "hot" colors.

A sample: http://churchturing.org/y/quarter.lowly-programmer-scaled.png.4.0.4096.29.png

The real big deal: (48 mb) http://churchturing.org/y/lowly-programmer-scaled.png.4.0.4096.29.png

The software: http://churchturing.org/y/24bit-randomschedule-ycbcr

If you mean the source image, yeah the linked imag...

2010-02-20T20:02:06.259-05:00

If you mean the source image, yeah the linked image is the one I used. The source is scaled dynamically to the required size, so as long as it is square and decently sized things work fine.

If you are talking about the final result, I have linked to it at allRGB.com - there is nowhere else to host an image that size easily.

Does that help?

Hi, is that the full size image you were using? If...

2010-02-20T19:46:36.922-05:00

Hi, is that the full size image you were using? If not can you the share original image?