File talk:1Mcolors.png

This file does not require a rating on Wikipedia's content assessment scale. It is of interest to the following WikiProjects:

Color This file is supported by WikiProject Color, a project that provides a central approach to color-related subjects on Wikipedia. Help us improve articles to good and 1.0 standards; visit the wikiproject page for more details.ColorWikipedia:WikiProject ColorTemplate:WikiProject Colorcolor articles Visual arts This file is within the scope of WikiProject Visual arts, a collaborative effort to improve the coverage of visual arts on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.Visual artsWikipedia:WikiProject Visual artsTemplate:WikiProject Visual artsvisual arts articles

This image could never be constructed from 1 million discrete colours sequentionally laid out as this would need at least 24 bit colour one million times over. That's 3mb.

An overall million colours is possible using repetition algorithms, in this case for the 100 identical 100 X 100 red/green squares. 100 different blue squares are added in. Each small square saves as 30kb uncompresssed and the wholeis about 3mb uncompressed as predicted. That's three colours over 1000000 pixels, but that's not how it is done.

This demonstrates the power of a compression algorithm when repetition is involved, here to construct 100 identical red/green squares and then add in 100 boxes of different blue colours. Thus we have a million differently coloured pixels across the gamut from black to white, all in a 4.64kb file.

The only suggestion I would make is to reverse the blue layer putting white at the top right which looks more even.

keoka 03:27, 24 March 2012 (UTC)

Where's a 4096px version with the entire 8bpc RGB color model? ;) 76.64.76.62 (talk) 00:27, 13 May 2009 (UTC)[reply]

• There you are -> http://commons.wikimedia.org/wiki/File:16Mcolors.png Despotak (talk) 20:55, 10 April 2013 (UTC)[reply]

This image appears to be a compressed as it's going to get without color or quality loss. Optipng -np -nc -nb -o9 reveals no change in size. 173.81.25.50 (talk) 21:31, 30 August 2010 (UTC)[reply]

As far as I can tell from the algorithm and general description of this image, there is no need for it to be 1000 pixels wide. It seems to be just 10 copies of identical columns. How is it that all the pixels have a different color, then?

In more detail: The only channel that differentiates in the horizontal direction is the red one, and that one repeats. Therefor the entire image repeats horizontally. —Preceding unsigned comment added by 129.67.168.71 (talk) 17:49, 7 May 2010 (UTC)[reply]

• Nope, the blue channel changes horizontally, too, but so slowly (1% per "small" square), that you don't really notice it. You see it best in the lowest row in the black & white separation, very light gray -> white. The algorithm calculates z, i.e. blue, from x and y. --Janke | Talk 07:03, 8 May 2010 (UTC)[reply]

Just to note, whilst the two versions in the reversion history *do* clearly render differently in browsers (tested with Chrome23 and Firefox17 in Linux), I this different appears to be due to the original having an embedded colour profiles (especially: iCCP chunk) whilst the PNGOUT re-compressed image does not have any such information.

(in fact, the main space saving seems to not be due to IDAT recompression, but through removing other chunks (iCCP, cHRM and so on)

Secondly, PGM is is *grey* scale format, and so is not suitable to compare. Perhaps Ysangkok meant PPM? (which I have converted both to (using pngtopnm), and diff'd those to find no difference).

IMHO, either image could do the stated job of illustrating a million colours. --.../Nemo (talk • Contributions) 03:10, 2 January 2013 (UTC)[reply]