Photogtaphy Forums

Photography Forums > Photography Newsgroups > Photography Archive > Digital Cameras > "16-bit" mode.

Reply
Thread Tools Display Modes

"16-bit" mode.

 
 
JPS@no.komm
Guest
Posts: n/a

 
      11-16-2004, 04:28 AM
First I thought it was strange when I found out that Photoshop's 16-bit
mode was actually 15-bit. Then, I though it was stranger still when I
found out there was one additional level (32768; it was explained that
this made certain types of math faster). Now, this evening, I was
writing an applet to extract RAW data from the uncompressed output of
the DNG converter, and decided to create a raw greyscale bitmap 256*256,
containing every possible 16-bit value, to see what PS would do with
them. I assumed that PS would make 0 and 1 0, 2 and 3 1, 4 and 5 2,
etc, but it does not. This is a sample of what it does:

real
16-bit PS values
data

0 0
1 0
2 0
3 3
4 3
5 3
6 3
7 3
8 3
9 5

2044 19128
2045 19131
2046 19131
2047 19131
2048 19131
2049 19131
2050 19131
2051 19134
2052 19134

4085 32762
4086 32762
4087 32766
4088 32766
4089 32766
4090 32766
4091 32766
4092 32766
4093 32768
4094 32768
4095 32768

Does anyone have any idea why they posterize the data even more than the
15-bit limitation?

This is basically about 13.5 bits of level-resolution.
--

<>>< ><<> ><<> <>>< ><<> <>>< <>>< ><<>
John P Sheehy <(E-Mail Removed)>
><<> <>>< <>>< ><<> <>>< ><<> ><<> <>><

 
Reply With Quote
 
 
 
 
Ken Weitzel
Guest
Posts: n/a

 
      11-16-2004, 05:03 AM


(E-Mail Removed) wrote:
> First I thought it was strange when I found out that Photoshop's 16-bit
> mode was actually 15-bit. Then, I though it was stranger still when I
> found out there was one additional level (32768; it was explained that
> this made certain types of math faster). Now, this evening, I was
> writing an applet to extract RAW data from the uncompressed output of
> the DNG converter, and decided to create a raw greyscale bitmap 256*256,
> containing every possible 16-bit value, to see what PS would do with
> them. I assumed that PS would make 0 and 1 0, 2 and 3 1, 4 and 5 2,
> etc, but it does not. This is a sample of what it does:
>
> real
> 16-bit PS values
> data
>
> 0 0
> 1 0
> 2 0
> 3 3
> 4 3
> 5 3
> 6 3
> 7 3
> 8 3
> 9 5
>
> 2044 19128
> 2045 19131
> 2046 19131
> 2047 19131
> 2048 19131
> 2049 19131
> 2050 19131
> 2051 19134
> 2052 19134
>
> 4085 32762
> 4086 32762
> 4087 32766
> 4088 32766
> 4089 32766
> 4090 32766
> 4091 32766
> 4092 32766
> 4093 32768
> 4094 32768
> 4095 32768
>
> Does anyone have any idea why they posterize the data even more than the
> 15-bit limitation?
>
> This is basically about 13.5 bits of level-resolution.


Hi John...

Just quickly off the top of my head... is it possible
that they've used a base 1 array?

Take care.

Ken

 
Reply With Quote
 
 
 
 
usenet@imagenoir.com
Guest
Posts: n/a

 
      11-16-2004, 07:29 PM
Kibo informs me that (E-Mail Removed) stated that:

>16-bit PS values

[...]
>0 0
>1 0

[...]
>2052 19134
>
>4085 32762

[...]
>4095 32768
>
>Does anyone have any idea why they posterize the data even more than the
>15-bit limitation?


Off the top of my head, my #1 guess would be that it's a colour-space
conversion. (There are plenty of other possibilities, but that seems by
far the most likely.)

Questions:
What format are you using to store your artificial data?
What colour-space have you got PS configured to work in?
What rules have you told PS to use when loading a file with a different
model to the default, or no model at all?

--
W
. | ,. w , "Some people are alive only because
\|/ \|/ it is illegal to kill them." Perna condita delenda est
---^----^---------------------------------------------------------------
 
Reply With Quote
 
JPS@no.komm
Guest
Posts: n/a

 
      11-16-2004, 09:43 PM
In message <(E-Mail Removed)>,
(E-Mail Removed) wrote:

>Kibo informs me that (E-Mail Removed) stated that:
>
>>16-bit PS values

>[...]
>>0 0
>>1 0

>[...]
>>2052 19134
>>
>>4085 32762

>[...]
>>4095 32768


Sorry; I messed up on that chart. I had 12-bit values in my head when I
wrote that. The numbers in the "real 16-bit column" should have been
starting at zero, around 32768, and around 65535, like so:

real
16-bit PS values
data

0 0
1 0
2 0
3 3
4 3
5 3
6 3
7 3
8 3
9 5

32764 19128
32765 19131
32766 19131
32767 19131
32768 19131
32769 19131
32770 19131
32771 19134
32772 19134

65525 32762
65526 32762
65527 32766
65528 32766
65529 32766
65530 32766
65531 32766
65532 32766
65533 32768
65534 32768
65535 32768



>>Does anyone have any idea why they posterize the data even more than the
>>15-bit limitation?

>
>Off the top of my head, my #1 guess would be that it's a colour-space
>conversion.


Can't be in this case. This is "open as .raw"

Even if there were a color space, I can't think of any reason to
posterize in it. Color space is about things like gamma, saturation,
combinations of primary colors, not about quantization.

>(There are plenty of other possibilities, but that seems by
>far the most likely.)


>Questions:
>What format are you using to store your artificial data?
>What colour-space have you got PS configured to work in?
>What rules have you told PS to use when loading a file with a different
>model to the default, or no model at all?


..raw

The things you are asking about would affect curves, not quantization.
--

<>>< ><<> ><<> <>>< ><<> <>>< <>>< ><<>
John P Sheehy <(E-Mail Removed)>
><<> <>>< <>>< ><<> <>>< ><<> ><<> <>><

 
Reply With Quote
 
JPS@no.komm
Guest
Posts: n/a

 
      11-16-2004, 09:52 PM
In message <(E-Mail Removed)>,
(E-Mail Removed) wrote:

>What format are you using to store your artificial data?


A binary file of 2-byte unsigned integers from 0 to 65535, loaded as
..raw.
--

<>>< ><<> ><<> <>>< ><<> <>>< <>>< ><<>
John P Sheehy <(E-Mail Removed)>
><<> <>>< <>>< ><<> <>>< ><<> ><<> <>><

 
Reply With Quote
 
Mike Engles
Guest
Posts: n/a

 
      11-16-2004, 11:43 PM
(E-Mail Removed) wrote:
>
> First I thought it was strange when I found out that Photoshop's 16-bit
> mode was actually 15-bit. Then, I though it was stranger still when I
> found out there was one additional level (32768; it was explained that
> this made certain types of math faster). Now, this evening, I was
> writing an applet to extract RAW data from the uncompressed output of
> the DNG converter, and decided to create a raw greyscale bitmap 256*256,
> containing every possible 16-bit value, to see what PS would do with
> them. I assumed that PS would make 0 and 1 0, 2 and 3 1, 4 and 5 2,
> etc, but it does not. This is a sample of what it does:
>
> real
> 16-bit PS values
> data
>
> 0 0
> 1 0
> 2 0
> 3 3
> 4 3
> 5 3
> 6 3
> 7 3
> 8 3
> 9 5
>
> 2044 19128
> 2045 19131
> 2046 19131
> 2047 19131
> 2048 19131
> 2049 19131
> 2050 19131
> 2051 19134
> 2052 19134
>
> 4085 32762
> 4086 32762
> 4087 32766
> 4088 32766
> 4089 32766
> 4090 32766
> 4091 32766
> 4092 32766
> 4093 32768
> 4094 32768
> 4095 32768
>
> Does anyone have any idea why they posterize the data even more than the
> 15-bit limitation?
>
> This is basically about 13.5 bits of level-resolution.
> --
>
> <>>< ><<> ><<> <>>< ><<> <>>< <>>< ><<>
> John P Sheehy <(E-Mail Removed)>
> ><<> <>>< <>>< ><<> <>>< ><<> ><<> <>><



Hello

There was a discussion about this kind of thing on the scanner group,
comp.periphs.scanner. Post your observation there. You might get a
explanation.

Mike Engles
 
Reply With Quote
 
usenet@imagenoir.com
Guest
Posts: n/a

 
      11-17-2004, 12:58 AM
Kibo informs me that (E-Mail Removed) stated that:

>In message <(E-Mail Removed)>,
>(E-Mail Removed) wrote:

[...]

>Sorry; I messed up on that chart. I had 12-bit values in my head when I
>wrote that. The numbers in the "real 16-bit column" should have been
>starting at zero, around 32768, and around 65535, like so:
>
> real
>16-bit PS values
>0 0
>9 5
>32772 19134
>65535 32768

(etc)

Okay, that seems a much better choice of data set.

>>>Does anyone have any idea why they posterize the data even more than the
>>>15-bit limitation?

>>
>>Off the top of my head, my #1 guess would be that it's a colour-space
>>conversion.

>
>Can't be in this case. This is "open as .raw"


But what kind of .raw? - You obviously don't mean a Canon (etc) camera
RAW file. ISTR that PS has some sort of generic, simple binary image
format. Is that what you mean?

>Even if there were a color space,


Unless you've disabled it, PS colour-manages by default, & will convert
to your working space, or bitch about your input file, etc. If it were
me, I'd check the colour-management settings & ensure that they're set
to ask what to do when opening a file that doesn't have an embedded
colour-space, or one that doesn't match your working space.

> I can't think of any reason to
>posterize in it. Color space is about things like gamma, saturation,
>combinations of primary colors, not about quantization.


I don't know if this is what's happening to you, but if your working
space is (for example) sRGB, & your image file is maxing out the
absolute limits of what PS can process (which it does, because that's
the whole point of your test!), then I woldn't be greatly surprised if
PS rescales/transforms that data to fit within the working colour-space.
Think about it from the point of view of the PS programmers - your test
image is the very definition of a pathological program input, & it has
to do *something* to shrink the input gamut into something that won't
choke the image-processing functions.

>>(There are plenty of other possibilities, but that seems by
>>far the most likely.)

>
>>Questions:
>>What format are you using to store your artificial data?
>>What colour-space have you got PS configured to work in?
>>What rules have you told PS to use when loading a file with a different
>>model to the default, or no model at all?

>
>.raw
>
>The things you are asking about would affect curves, not quantization.


Same difference in this context. Your problem, as you've stated it, is
that you are inputting a data set containing the maximum & minimum
possible data values allowable (we assume, at least) by the file format.
If that data is transformed in any way whatsoever, (offsets, scaling,
curves, anything at all), you'll lose the 1:1 correspondance that you're
expecting to see.
What I suspect is that it'll turn out that PS doesn't /really/ permit
pixels to stretch from the -2^15 to +2^15 range implied by the signed 16
bit/channel/pixel data format, & that at minimum, it transforms any data
that pathological into some internal pseudo-colour-space that's bigger
than any of the standard spaces.

--
W
. | ,. w , "Some people are alive only because
\|/ \|/ it is illegal to kill them." Perna condita delenda est
---^----^---------------------------------------------------------------
 
Reply With Quote
 
usenet@imagenoir.com
Guest
Posts: n/a

 
      11-17-2004, 01:01 AM
Kibo informs me that (E-Mail Removed) stated that:

>In message <(E-Mail Removed)>,
>(E-Mail Removed) wrote:
>
>>What format are you using to store your artificial data?

>
>A binary file of 2-byte unsigned integers from 0 to 65535, loaded as
>.raw.


Got any data on that format? You've gotten me interested enough in this
question to want to try a few experiments myself.

--
W
. | ,. w , "Some people are alive only because
\|/ \|/ it is illegal to kill them." Perna condita delenda est
---^----^---------------------------------------------------------------
 
Reply With Quote
 
JPS@no.komm
Guest
Posts: n/a

 
      11-17-2004, 02:33 AM
In message <(E-Mail Removed)>,
(E-Mail Removed) wrote:

>Kibo informs me that (E-Mail Removed) stated that:
>
>>In message <(E-Mail Removed)>,
>>(E-Mail Removed) wrote:
>>
>>>What format are you using to store your artificial data?

>>
>>A binary file of 2-byte unsigned integers from 0 to 65535, loaded as
>>.raw.

>
>Got any data on that format? You've gotten me interested enough in this
>question to want to try a few experiments myself.


I just wrote an applet in C that stripped the RAW data out of
uncompressed .dng files and multiplied them by 16 so that there wouldn't
be any quantization (the .dng files use the numbers 0 to 4095 in 16-bit
space) . I modified it slightly to create a string of 65536 2-byte
integers, 0 to 65535, and loaded it into PS as a 256*256 16-bit
greyscale bitmap. I placed the "Info" cursor over it, and got those
values.
--

<>>< ><<> ><<> <>>< ><<> <>>< <>>< ><<>
John P Sheehy <(E-Mail Removed)>
><<> <>>< <>>< ><<> <>>< ><<> ><<> <>><

 
Reply With Quote
 
JPS@no.komm
Guest
Posts: n/a

 
      11-17-2004, 02:36 AM
In message <(E-Mail Removed) >,
(E-Mail Removed) (Mitch Alsup) wrote:

>This looks like somebody is applying the gamma correction to the RAW data
>ouptut = input**2.2 / some-fixed-scaling


No; it's totally linear. 6 sequential 16-bit values become one "PS
16-bit" value (except for the highest and lowest values, which are 3 to
1).

I think its time for Adobe to realize that people have fast machines,
and that they need to stop cutting corners on quality for speed.
--

<>>< ><<> ><<> <>>< ><<> <>>< <>>< ><<>
John P Sheehy <(E-Mail Removed)>
><<> <>>< <>>< ><<> <>>< ><<> ><<> <>><

 
Reply With Quote
 
 
 
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off