Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 

   


   


   















      :: Filmscanners
Filmscanners mailing list archive (filmscanners@halftone.co.uk)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[filmscanners] Re: 8bits vs.16bits/channel:cantheeyeseethedifference



on 3/21/03 12:22 AM, Paul D. DeRocco at pderocco@ix.netcom.com wrote:

>> From: Roy Harrington
>>
>> Did you see my example showing that PS does in fact do more than just
>> truncating 16 bits to 8 bits?   PS in a 16 to 8 bit mode change simulates
>> intermediate values by dithering exactly like the gradient tool does.
>> I don't know whether it's done by adding noise and truncating or a more
>> elaborate algorithm but PS does make the average 8 bit gray value keep as
>> much of the 16bit data that it can.
>
> How did you get it to do this? Here's the experiment I performed.
>
> 1) Since PS doesn't let you create a 16bpc image from scratch or up-convert
> an 8bpc image, I opened an existing 16bpc TIFF file.
>
> 2) Since PS won't let you fill a 16bpc image, I used Levels to squeeze the
> entire dynamic range down to nothing, by setting the Output Levels range to
> 128 to 128. That gave me a uniform gray.
>
> 3) I used Levels again to stretch the dynamic range by setting the Input
> Levels range to 126 to 129. This converts the value 128 into 2/3 of full
> scale, or 170 on an 8-bit scale, but with some fractional bits.
>
> 4) I saved it with no compression, and opened the file in a hex editor. The
> 16bpc values were all 0xAAA9, proving that it did indeed have fractional
> bits.
>
> 5) I converted the image to 8bpc. Moving the cursor over it still showed a
> value of 170 on every pixel.
>
> 6) I resaved it, and the hex editor showed the 8bpc values as all being
> 0xAA.
>
> If it had dithered, I would expect 2/3 of the values to be 171, or 0xAB.
>
> --
>
> Ciao,               Paul D. DeRocco
> Paul                mailto:pderocco@ix.netcom.com
>

I tried your particular construction and by sheer coincidence the numbers
you get happen to be an almost exact match of 16 bit versus 8 bit.
0xAAAA is the exact mapping of 0xAA so when you converted, it was extremely
close.  When I tried it I actually got .26% of the pixels to come out 169
with the rest all being 170.

Here's a much easier construction that will show what you want.  Fill the
canvas in 8 bit mode -- say Gray=128.  Convert to 16 bit now you have an
exact 16bit representation of an 8bit value.  Now do a very minor Levels
change.  Set the white point from 255 to 254.  That will nudge every gray
value X = X*(255/254).  So 128 will go up by a half, if you had picked
Gray = 85 to start it would go up by a third, ... etc.

Now convert to 8-bit and see the dithered pixels.

------

I have a feeling my above 8bit to 16bit mapping will raise questions so
I'll run through the logic and an easy way to check it.

8 bit goes from 0 to 255 (in hex 0xFF)
16 bit goes from 0 to 65535 (in hex 0xFFFF)

Both the black and the white points must match in mapping, 0 to 0 is
trivial but 65535/255 = 257 so you need to multiply 255 by 257 to convert
from 8 to 16 bit.  So:

X16 = X8 * 257

Its particularly easy to see in hex (if you're into that kind of thing).
0xFF maps to 0xFFFF, 0x12 maps to 0x1212, 0xAA maps to 0xAAAA -- you just
duplicate the top byte into the new bottom byte.

Going the other way you just start with doing the opposite:

X8 = X16 / 257

This is an integer divide i.e. it truncates and leaves a remainder.  The
remainder is how far off X8 is from matching the X16 gray value we
really want.  So with probability p = (remainder/257) we add one to X8.
This is the dithering step that produces an "average" 8bit gray by
using X8 and X8+1.

------

I've looked at the output from PS by using the Raw output format and
a hex dump to confirm this.  There is one other very minor (but to be
exact I'll mention it) quirk.  Internally, PS uses just 15 bits of data
in the 16 bit mode -- I believe that this is purely for efficiency
reasons.  Because of this whenever you save as TIFF or as Raw the
bottom bit is always fixed.  Note that this is a very minor issue and
shouldn't be blown out of proportion, I only mention it because if you
look at hex dumps it'll be obvious.

Roy


Roy Harrington
roy@harrington.com
Black & White Photography Gallery
http://www.harrington.com


----------------------------------------------------------------------------------------
Unsubscribe by mail to listserver@halftone.co.uk, with 'unsubscribe 
filmscanners'
or 'unsubscribe filmscanners_digest' (as appropriate) in the message title or 
body



 




Copyright © Lexa Software, 1996-2009.