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
> From: Roy Harrington
>
> 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.
>
> 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.
You're right! I had assumed that they divided by 256, not 257. I stand
corrected. When I repeated the test to produce numbers that are not
multiples of 257, it did indeed do some dithering.
What's odd is that in RGB mode it dithers all the colors with the same
pattern. You'd think they'd use uncorrelated dither noise for the three
colors.
> 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 8bit and see the dithered pixels.
What I'd like to know is how you managed to convert from 8bpc to 16bpc. You
must have a different version of PS, because mine doesn't let you do that.
I'm using v7.01 for Windows.

Ciao, Paul D. DeRocco
Paul mailto:pderocco@ix.netcom.com

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