Prev: Free large dimension image hosting
Next: REGISTER FREE ! EARN FROM HOME
From: bugbear on 6 May 2008 06:27
I've just started messing with RAW, courtesy
of those nice CHDK chaps.

AFAIK my Canon A630 does not have 16 bit A/D
inside; but when I run dcraw -4 I *do*
get a full range of values;

I checked this by performing:

dcraw -4 -c CRW_2934.CRW | pamdepth 255 > hist.ppm

and then looking at the histogram (logarithmic) of hist.ppm
in Gimp 2.4.

The values range from 0-255 in all 3 channels.

I would NOT expect the values to be that
high, and I would NOT expect all 3 channels to have
the same range.

I was expecting 12 bit or 14 bit data (whatever my A/D
kicks out), and variation between the r-g-b channels.

Can anyone explain?

BugBear

refs:

http://chdk.wikia.com/wiki/Main_Page
http://cybercom.net/~dcoffin/dcraw/
http://www.dpreview.com/reviews/specs/Canon/canon_a630.asp
From: bugbear on 6 May 2008 10:05
Jim Townsend wrote:
> bugbear wrote:
>
>> I've just started messing with RAW, courtesy
>> of those nice CHDK chaps.
>>
>> AFAIK my Canon A630 does not have 16 bit A/D
>> inside; but when I run dcraw -4 I *do*
>> get a full range of values;
>>
>> I checked this by performing:
>>
>> dcraw -4 -c CRW_2934.CRW | pamdepth 255 > hist.ppm
>>
>> and then looking at the histogram (logarithmic) of hist.ppm
>> in Gimp 2.4.
>>
>> The values range from 0-255 in all 3 channels.
>>
>> I would NOT expect the values to be that
>> high, and I would NOT expect all 3 channels to have
>> the same range.
>>
>> I was expecting 12 bit or 14 bit data (whatever my A/D
>> kicks out), and variation between the r-g-b channels.
>>
>> Can anyone explain?
>>
>> BugBear
>
> Canon's early RAW images were 12 bit. The newer cameras
> produce 14 bit CRW images. The are saved as 16 bit images.

Ah hah!

> There are 12 or 14 bits of actual image data and the remaining
> bits are padded with zeros.
>
>
> 8 bits = 255 (Binary 11111111)
> An 8 bit color image is composed of three channels X 255
>
> 16 bits = 65535 (Binary 1111111111111111)
> A 16 bit color image is composed of three channels x 65535
>
> DCraw might be able to process 16 bit images, but GIMP cannot.
> GIMP converts 16 bit images to 8 bit images when you open them.
>
> The value of 255 per channel in GIMP's histogram is normal for
> an 8 bit image. I don't know why you think this is high. (Open
> an 8 bit JPEG in GIMP and you'll see the histogram still shows
> 0-255 per channel).

Because I was missing the info you gave me!

I was expecting 12 (or maybe 14 bit) data, UNPADDED,
which would have given me 4 (or maybe 6) bit data after crunching
down to 8 bit in netpbm (which divides everything by 257)

BugBear
From: bugbear on 6 May 2008 11:45
Jim Townsend wrote:
> bugbear wrote:
>
> Canon's early RAW images were 12 bit. The newer cameras
> produce 14 bit CRW images. The are saved as 16 bit images.
>
> There are 12 or 14 bits of actual image data and the remaining
> bits are padded with zeros.

Aak. It appears that CHDK on Canon powershots
is only giving me 10 bits.

I'm not sure (at this stage) wether
the limitation is the software or the d/a converter.

BugBear
From: Floyd L. Davidson on 6 May 2008 12:54
Jim Townsend <not(a)real.address> wrote:
>bugbear wrote:
>
>> I've just started messing with RAW, courtesy
>> of those nice CHDK chaps.
>>
>> AFAIK my Canon A630 does not have 16 bit A/D
>> inside; but when I run dcraw -4 I *do*
>> get a full range of values;
>>
>> I checked this by performing:
>>
>> dcraw -4 -c CRW_2934.CRW | pamdepth 255 > hist.ppm

The input file (assuming it is 12-bits) has a maximum
value of 4095. That will be *scaled* to result in a
16-bit output file that has a maximum value of 64535, or
an 8-bit output file with a maximum value of 255. Those
numbers *all* represent the exact same intensity of
brightness when displayed.

By piping /dcraw/ output through /pamdepth/ /256/ the
above command line guarantees that those maximum
intensity values are represented in 8 bits, with a
maximum value of 255.

>> and then looking at the histogram (logarithmic) of hist.ppm
>> in Gimp 2.4.
>>
>> The values range from 0-255 in all 3 channels.

Exactly what should be expected. What might be
interesting is to compare, byte for byte, the output of
that command to just using /dcraw/ to generate an 8-bit
depth PPM file. I don't, for example, expect that
/dcraw/ and /pamdepth/ would necessarily use exactly the
same conversion algorithm, and therefore would expect at
least some difference in the result.

>> I would NOT expect the values to be that
>> high, and I would NOT expect all 3 channels to have
>> the same range.
>>
>> I was expecting 12 bit or 14 bit data (whatever my A/D
>> kicks out), and variation between the r-g-b channels.
>>
>> Can anyone explain?

The 12/14-bit data is converted to 8/16-bit values. It
is *not* simply padded more or less with zeros.

>> BugBear
>
>Canon's early RAW images were 12 bit. The newer cameras
>produce 14 bit CRW images. The are saved as 16 bit images.
>
>There are 12 or 14 bits of actual image data and the remaining
>bits are padded with zeros.

To begin with, the 12 or 14 bit raw data is not RGB per
pixel, but per sensor and is encoded with a linear
analog-to-digital transfer function. The 16-bit image
file generated by /dcraw/ or some other raw conversion
program is an RGB (three 16-bit values, one for each
color, per pixel) and is encoded with a "gamma
corrected" transfer function.

It is *not* a case of "bits are padded with zeros" at
any point in the processing stream.

>8 bits = 255 (Binary 11111111)
>An 8 bit color image is composed of three channels X 255
>
>16 bits = 65535 (Binary 1111111111111111)
>A 16 bit color image is composed of three channels x 65535

True, and a point that is valid and relates to the OP's
questions. It perhaps needs some expansion though.

I'm not going to work this out for a gamma-corrected
value set, but showing how it would work if the files
were linear data is useful. With the 16-bit file, the
top zone has values from 65535 to half that, 32768.
Those values are converted to an 8-bit range of 255 to
half that, 128. So there are 32767 possible values in
the 16-bit file, and 127 values in the 8-bit file (for
the brightest zone). Therefore each 8-bit value would
be valid for any of 32767/127 different values in the
16-bit file. That is 258 possible different values
originally in a 16-bit linear file for each value in the
8-bit file.

There need only be a single value for each color in the
range of 65277 to 65535 to result in an 8-bit file that
has a 255 maximum value for each color.

>DCraw might be able to process 16 bit images, but GIMP cannot.
>GIMP converts 16 bit images to 8 bit images when you open them.
>
>The value of 255 per channel in GIMP's histogram is normal for
>an 8 bit image. I don't know why you think this is high. (Open
>an 8 bit JPEG in GIMP and you'll see the histogram still shows
>0-255 per channel).

Precisely!

--
Floyd L. Davidson <http://www.apaflo.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) floyd(a)apaflo.com
From: bugbear on 7 May 2008 03:57
Floyd L. Davidson wrote:
> bugbear <bugbear(a)trim_papermule.co.uk_trim> wrote:
>> Jim Townsend wrote:
>>> Canon's early RAW images were 12 bit. The newer cameras
>>> produce 14 bit CRW images. The are saved as 16 bit
>>> images.
>> Ah hah!
>
> But when "saved as 16 bit images", the data is re-encoded
> using 16 bit values. It is *never* padded with zeros.
>
>>> There are 12 or 14 bits of actual image data and the
>>> remaining bits are padded with zeros.
>>> 8 bits = 255 (Binary 11111111)
>>> An 8 bit color image is composed of three channels X 255
>>> 16 bits = 65535 (Binary 1111111111111111)
>>> A 16 bit color image is composed of three channels x 65535
>>> DCraw might be able to process 16 bit images, but GIMP
>>> cannot. GIMP converts 16 bit images to 8 bit images
>>> when you open them. The value of 255 per channel in
>>> GIMP's histogram is normal for an 8 bit image. I
>>> don't know why you think this is high. (Open an 8 bit
>>> JPEG in GIMP and you'll see the histogram still shows
>>> 0-255 per channel).
>> Because I was missing the info you gave me!
>>
>> I was expecting 12 (or maybe 14 bit) data, UNPADDED,
>> which would have given me 4 (or maybe 6) bit data after crunching
>> down to 8 bit in netpbm (which divides everything by 257)
>
> That does not make sense. Regardless of conversion to a
> 16-bit format, when encoded in an 8-bit file you would have
> 8 bits, not 4 or maybe 6.

I wasn't counting leading zeroes in my bit counts.

*IF* you take my assumption that the true-raw data is 12 bit,
(i.e. 16 bit with 4 leading zeroes) *AND*
that dcraw preserves this convention *AND* you simply divide
the 16 bit data by 257 (which *IS* what pamdepth does) you would *expect*
the resulting file to be 8 bit with 4 leading zeroes, which
most people would call 4 bit.

It appears that no less than two of my assumptions are wrong;
The data (I think) in the CRW file is right padded with zero,
not left, and in any case it appears that dcraw normalises to
"full" 16 bit.

Given my assumptions, I claim that both my reasoning
and conclusions were valid.

Shame about the assumptions.

BugBear
 |  Next  |  Last
Pages: 1 2
Prev: Free large dimension image hosting
Next: REGISTER FREE ! EARN FROM HOME