Hi,

I would like to convert 16-bit scan values to 8-bit values but am unsure
of the correct method. I am assuming a gamma of 2.2.

My current formula is :

output = ((input / 65536) E (1 / 2.2)) * 256

Is this correct ?

Some of my scans have 8-bit values of 1 or 2. This surprises me as the
minimum non-zero 16-bit scan value my scanner can produce is 4.
Applying the above formula gives me an 8-bit value of 3 so I should
never get an 8-bit value of 1 or 2 in a raw file. These are colour
files not greyscale.

-- Steven

"SJS" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Hi,
>
> I would like to convert 16-bit scan values to 8-bit values but am unsure
> of the correct method. I am assuming a gamma of 2.2.
>
> My current formula is :
>
> output = ((input / 65536) E (1 / 2.2)) * 256
>
> Is this correct ?
>
> Some of my scans have 8-bit values of 1 or 2. This surprises me as the
> minimum non-zero 16-bit scan value my scanner can produce is 4.
> Applying the above formula gives me an 8-bit value of 3 so I should
> never get an 8-bit value of 1 or 2 in a raw file. These are colour
> files not greyscale.
>
> -- Steven
>

To convert 16 bit to 8 bit drop the upper 8 bits or divide by 256.
Do an integer divide to drop the fractions.

There are three 16 bit values in color, 16 bits of red, 16 bits of green and
16 bits of blue. For a total of 48 bits.

So, you would divide the Red value by 256, the Green Value by 256 and the
Blue value by 256, leaving 24 bit color.

--
CSM1
http://www.carlmcmillan.com
--

On Fri, 04 Jun 2004 14:02:05 GMT, "CSM1" <(E-Mail Removed)> wrote:

>"SJS" <(E-Mail Removed)> wrote in message
>news:(E-Mail Removed)...
>> Hi,
>>
>> I would like to convert 16-bit scan values to 8-bit values but am unsure
>> of the correct method. I am assuming a gamma of 2.2.
>>
>> My current formula is :
>> output = ((input / 65536) E (1 / 2.2)) * 256
>
>To convert 16 bit to 8 bit drop the upper 8 bits or divide by 256.
>Do an integer divide to drop the fractions.

Oops, in my post I should have stated that the 16-bit values are gamma
1.0 and the 8-bit values are gamma 2.2. Are you sure that I simply drop
the lower 8 bits ? Wouldn't this just reduce my density range to 256 ?

-- Steven

"SJS" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On Fri, 04 Jun 2004 14:02:05 GMT, "CSM1" <(E-Mail Removed)> wrote:
>
> >"SJS" <(E-Mail Removed)> wrote in message
> >news:(E-Mail Removed)...
> >> Hi,
> >>
> >> I would like to convert 16-bit scan values to 8-bit values but am
unsure
> >> of the correct method. I am assuming a gamma of 2.2.
> >>
> >> My current formula is :
> >> output = ((input / 65536) E (1 / 2.2)) * 256
> >
> >To convert 16 bit to 8 bit drop the upper 8 bits or divide by 256.
> >Do an integer divide to drop the fractions.
>
> Oops, in my post I should have stated that the 16-bit values are gamma
> 1.0 and the 8-bit values are gamma 2.2. Are you sure that I simply drop
> the lower 8 bits ? Wouldn't this just reduce my density range to 256 ?
>
> -- Steven
>
Do not drop the lower 8 bits, drop the upper 8 bits.
In a 16 bit word, you want to drop the high byte and keep the low byte.
If you know how to shift bits the operation is a << 8 or a left shift of 8
bits.

16 bit values are 0-65535 and 8 bit values are 0-255

By dropping the high byte you reduce the the number of colors that can be
represented from 65536 to 256 in each Red, Green or Blue color.

I do not know if it will affect gamma.

All I know is that the output of the scanner is nothing but data. How much
data depends on what the software has told the scanner to do.

Check out www.scantips.com.
Wayne Fulton is really good with scanners. Also check http://hamrick.com/
He writes software for scanners. (VueScan)

--
CSM1
http://www.carlmcmillan.com
--

In article <jRkwc.2834$(E-Mail Removed)>, CSM1
<(E-Mail Removed)> writes
>>
>Do not drop the lower 8 bits, drop the upper 8 bits.
>In a 16 bit word, you want to drop the high byte and keep the low byte.
>If you know how to shift bits the operation is a << 8 or a left shift of 8
>bits.
>
I think you need to revise both of those statements.

Left hand... meet right hand!

>16 bit values are 0-65535 and 8 bit values are 0-255
>
So in 16 bit format, we get red=61217 for example, or EF21 in
hexadecimal.

Drop the upper 8 bits, results in 21 in hexadecimal, or 33 decimal.
Now, 61217 is quite a high luminance red in 16-bit colour, but 21 is a
low luminance red in 8-bit colour - so quite clearly, dropping the upper
8 bits is complete rubbish. Indeed, doing so results in very small
changes in luminance having quite large changes in the converted data.
For example, 61182 in 16-bit colour is only 0.06% darker than the
original colour but, since it is EEFE in hexadecimal then using your
conversion results in an 8-bit colour level of FE, or 254, which is
nearly saturated!

Now look at your other suggestion, left shifting the data by 8 bits.
61217 decimal, EF21 hexadecimal, becomes EF2100 hexadecimal, which is a
24-bit number of value 15671552 in decimal. More rubbish! That os
because left shifting is equivalent to *multiplying* the data by 2 for
each shift! So what do we do with this meaningless huge number? Drop
the upper bits as in your other suggestion and end up with zero for
everything?
>
>I do not know if it will affect gamma.
>
Or, apparently, what you are talking about! If you do find that your
operation works then you have a more fundamental problem with your data,
such as reading big endians as little endians or vice versa.

SJS original suggestion gives the correct solution, although dropping
the lower 8-bits is irrelevant if the division is integer.
Alternatively, shift *right* by 8 bits!

As for gamma, I don't think he need make any adjustment at all. Gamma
is applied to the 16-bit and 8-bit data scaled to the peak white and
black levels, so it automatically works. Having said that, SJS later
post indicated that the gamma of the two data sets was different, so he
will have to apply gamma to the 16-bit data prior to converting - doing
so after will result in missing codes.
--
Kennedy
Yes, Socrates himself is particularly missed;
A lovely little thinker, but a bugger when he's ****ed.
Python Philosophers (replace 'nospam' with 'kennedym' when replying)

On Sat, 5 Jun 2004 21:23:44 +0100, Kennedy McEwen
<(E-Mail Removed)> wrote:

>As for gamma, I don't think he need make any adjustment at all. Gamma
>is applied to the 16-bit and 8-bit data scaled to the peak white and
>black levels, so it automatically works. Having said that, SJS later
>post indicated that the gamma of the two data sets was different, so he
>will have to apply gamma to the 16-bit data prior to converting - doing
>so after will result in missing codes.

Hi Kennedy,

I think the formula does gamma conversion ( ^(1/2.2) ). I have since
read that formula changes at low luminence values so the slope is
limited to 4.5 (apologies if my terminology is incorrect here). This
slope limiting explains how I could get an 8-bit sample of 1 or 2 from a
16-bit sample with a granularity of 4 (14-bits << 2).

This slope limiting seems a bit excessive for a scanner as it limits the
density range to just over 1000. Testing with my Canon scanner
indicates that the slope is limited to 9 instead of 4.5.

Regards,

Steven

On Sat, 05 Jun 2004 14:33:51 GMT, "CSM1" <(E-Mail Removed)> wrote:

>Check out www.scantips.com.
>Wayne Fulton is really good with scanners. Also check http://hamrick.com/
>He writes software for scanners. (VueScan)

Thanks for the scantips link.

-- Steven

"Kennedy McEwen" <(E-Mail Removed)> wrote in message
news:8Pmu+(E-Mail Removed)...
SNIP
> SJS original suggestion gives the correct solution, although dropping
> the lower 8-bits is irrelevant if the division is integer.
> Alternatively, shift *right* by 8 bits!

Although binary correct, the proper thing to do is divide by 257.
If we assume 255 to be the brightest value one can represent in 8 bits and
65535 the brightest in 16 bits, then dividing by 257 will preserve that
relation. Doing so will preserve slightly more accuracy.
This of course assumes equal gamma, or prior gamma adjustment.

Bart

"Bart van der Wolf" <(E-Mail Removed)> wrote in message
news:40c2653a$0$15440$(E-Mail Removed)...
>
> "Kennedy McEwen" <(E-Mail Removed)> wrote in message
> news:8Pmu+(E-Mail Removed)...
> SNIP
> > SJS original suggestion gives the correct solution, although dropping
> > the lower 8-bits is irrelevant if the division is integer.
> > Alternatively, shift *right* by 8 bits!
>
> Although binary correct, the proper thing to do is divide by 257.
> If we assume 255 to be the brightest value one can represent in 8 bits and
> 65535 the brightest in 16 bits, then dividing by 257 will preserve that
> relation. Doing so will preserve slightly more accuracy.
> This of course assumes equal gamma, or prior gamma adjustment.
>
> Bart
>
Thanks, Bart. You are so correct.

--
CSM1
http://www.carlmcmillan.com
--

In article <qEMwc.4557$(E-Mail Removed)>, CSM1
<(E-Mail Removed)> writes
>"Bart van der Wolf" <(E-Mail Removed)> wrote in message
>news:40c2653a$0$15440$(E-Mail Removed)...
>>
>> "Kennedy McEwen" <(E-Mail Removed)> wrote in message
>> news:8Pmu+(E-Mail Removed)...
>> SNIP
>> > SJS original suggestion gives the correct solution, although dropping
>> > the lower 8-bits is irrelevant if the division is integer.
>> > Alternatively, shift *right* by 8 bits!
>>
>> Although binary correct, the proper thing to do is divide by 257.
>> If we assume 255 to be the brightest value one can represent in 8 bits and
>> 65535 the brightest in 16 bits, then dividing by 257 will preserve that
>> relation. Doing so will preserve slightly more accuracy.
>> This of course assumes equal gamma, or prior gamma adjustment.
>>
>> Bart
>>
>Thanks, Bart. You are so correct.
>
Faint praise indeed - we have seen your math skills in action!
--
Kennedy
Yes, Socrates himself is particularly missed;
A lovely little thinker, but a bugger when he's ****ed.
Python Philosophers (replace 'nospam' with 'kennedym' when replying)