Depth of raw RGB data

[starfry]

I am processing some raw RGB data that I perceive to be RGB (1 byte Red, 1 byte Blue and 1 byte Green). The data is written to a file such that each triplet (3 bytes in the order red-green-blue, totalling 3*8=24 bits) represents one pixel. The image is 1920x1080 = 2073600 = 6220800 bytes. The resulting RGB file is exactly 6220800 bytes in size.

Now I would usually refer to this as 24 bit RGB but when I try to process it thru "convert" it only works when a depth of 8 is specified and the resulting PNG is also 8 bit.

Code: Select all

$ convert -size 1920x1080 -depth 8 data.rgb image.png
$ identify image.png
image.png PNG 1920x1080 1920x1080+0+0 8-bit sRGB 5.935MB 0.000u 0:00.000

If I try specifying a depth of 24 bits then convert errors with an unexpected end of file. I've also tried specifying "-depth 24" again before the final filename bit it made no difference.

SO my question is to clarify whether I just misunderstand what "depth" means and to ask, given a file containing three byte triplets of RGB data, what is the right way to convert it to a 24-bit true-colour image?

My system details are:
ImageMagick 6.8.9-7 Q16 x86_64 2014-08-25
Linux 3.16.4-1-ARCH #1 SMP PREEMPT Mon Oct 6 08:22:27 CEST 2014 x86_64 GNU/Linux

[snibgo]

If in doubt, read the documentation: http://www.imagemagick.org/script/comma ... .php#depth

This the number of bits in a color sample within a pixel. ...

RGB files have three colour samples per pixel.

Does than answer the question?

[starfry]

I have already read that and have performed many searches before asking the question.

RGB files do indeed have three colour samples per pixel. In my raw data that is three bytes which is 24 bits. I would have expected that the "depth" would be 24 but I found that convert didn't accept the input data unless I set the depth to 8. This is contrary to what I expect, given I know the input data has 3 bytes or 24 bits per pixel.

So, it's still unanswered

[snibgo]

"-depth", as the documentation says, is the number of bits per colour sample per pixel. Set it to 8 if each sample (red, green or blue) has 8 bits.

Put it another way: if an image has 8 bits/channel/pixel and 3 channels, it has a total of 24 bits/pixel.

"-depth" refers to bits/channel/pixel, not total bits/pixel.

[starfry]

The exact wording is "the number of bits in a color sample within a pixel" and I didn't interpret that sub-phrase correctly. Had it said "per colour sample per pixel" I think I might have interpreted it differently and understood it a lot quicker

So it's down to my misunderstanding. I think the average joe would understand "normal" RGB used in computers, televisions and the like to be 24 bit if he understands the concept at all. My searches gave me results like this so I think there's conflcting contexts that use the term "depth" differently when describing the number of bits in an RGB triple.

I did find this which explains the differences nicely (and also explains why you might want more than 8 bits per colour).

Also, looking at at the generated PNG file, I now understand that the "8-bit sRGB" reported by identify really means 8 bits per colour. Incidentally "file" is clearer in that regard: it reports "8-bit/color RGB". As I understand it, this is a "PNG24" format. If I prefixed the outfile with "PNG8" (just to see what happens) I get a smaller file that identify reports as "8-bit sRGB 256c" and file reports as "8-bit colormap".

Anyway thanks for clarifying it for me, I think I understand now but I do think this depth terminology is confusing to the uninitiated

[snibgo]

... but I do think this depth terminology is confusing to the uninitiated.

I agree. The thing to remember is that there are two different numbers: bits/channel/pixel, and bits/channel. Documentation is not always clear which is meant. There are typically 1, 3, 4 or 5 channels.

Colormaps add an extra complication, because the pixel value is a single index into a table of colours. The index (each pixel value) will have a number of bits (typically 8 ) but the colour table may have three channels each of some other number of bits (typically 8 bits/channel).