"16-bit" mode.

Discussion in 'Digital Cameras' started by JPS@no.komm, Nov 16, 2004.

  1. Guest

    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 <>
    ><<> <>>< <>>< ><<> <>>< ><<> ><<> <>><
    , Nov 16, 2004
    #1
    1. Advertising

  2. Ken Weitzel Guest

    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
    Ken Weitzel, Nov 16, 2004
    #2
    1. Advertising

  3. Guest

    Kibo informs me that 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
    ---^----^---------------------------------------------------------------
    , Nov 16, 2004
    #3
  4. Guest

    In message <>,
    wrote:

    >Kibo informs me that 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 <>
    ><<> <>>< <>>< ><<> <>>< ><<> ><<> <>><
    , Nov 16, 2004
    #4
  5. Guest

    In message <>,
    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 <>
    ><<> <>>< <>>< ><<> <>>< ><<> ><<> <>><
    , Nov 16, 2004
    #5
  6. Mike Engles Guest

    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 <>
    > ><<> <>>< <>>< ><<> <>>< ><<> ><<> <>><



    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
    Mike Engles, Nov 16, 2004
    #6
  7. Guest

    Kibo informs me that stated that:

    >In message <>,
    > 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
    ---^----^---------------------------------------------------------------
    , Nov 17, 2004
    #7
  8. Guest

    Kibo informs me that stated that:

    >In message <>,
    > 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
    ---^----^---------------------------------------------------------------
    , Nov 17, 2004
    #8
  9. Guest

    In message <>,
    wrote:

    >Kibo informs me that stated that:
    >
    >>In message <>,
    >> 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 <>
    ><<> <>>< <>>< ><<> <>>< ><<> ><<> <>><
    , Nov 17, 2004
    #9
  10. Guest

    In message <>,
    (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 <>
    ><<> <>>< <>>< ><<> <>>< ><<> ><<> <>><
    , Nov 17, 2004
    #10
  11. wrote:

    > In message <>,
    > 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
    >

    In my testing of photoshop on real images, I find the following
    equation:

    PS = int(IP/2),

    where PS = the photoshop "16-bit" value and
    IP = the 16-bit output from ImagesPlus.

    Roger
    Roger N. Clark (change username to rnclark), Nov 17, 2004
    #11
  12. "Mike Engles" <> wrote in message
    news:...
    SNIP
    > 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.


    You probably are referring to these:
    1. Chris Cox's 'explanation' of the internal format of 15bits+1:
    <http://groups.google.nl/groups?selm=190520021813529214%ccox@minds
    pring.com&output=gplain>
    2. The way Photoshop converts (16-bits to 8-bits)
    <http://groups.google.com/groups?selm=060620042031159126%ccox@mind
    spring.com&output=gplain>

    Bart
    Bart van der Wolf, Nov 17, 2004
    #12
  13. Guest

    In message <>,
    wrote:

    > wrote:
    >
    >> (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.

    >
    >Form your own table:
    >
    > 32764/19128 = 1.713
    >
    > 65525/32762 = 2.000
    >
    >So it isn't exactly linear. From these two points (essentially all
    >you posted) it looks like there is a gamma-esque hump in the transfer
    >function. You should fetch gnuplot or a similar plotting tool and
    >plot the entire "real" vs "photoslop" correspondance you obtained.


    Yes, you're right; it isn't perfectly linear, due to color management.
    It is almost linear (gamma close to 1), but that isn't the most
    disturbing problem. The problem is that the data is severely
    posterized. Even with color management disabled, this only happens with
    greyscale; 16-bit RGB bitmaps transfer very simply; they are
    psvalue=int((inputvalue+1)/2)). Greyscale only uses 1/3 as many levels
    as RGB; 6 input values become 1 PS value, as opposed to 2 becoming 1.
    --

    <>>< ><<> ><<> <>>< ><<> <>>< <>>< ><<>
    John P Sheehy <>
    ><<> <>>< <>>< ><<> <>>< ><<> ><<> <>><
    , Nov 17, 2004
    #13
  14. Guest

    In message <419b5fc7$0$14941$4all.nl>,
    "Bart van der Wolf" <> wrote:

    >"Mike Engles" <> wrote in message
    >news:...
    >SNIP
    >> 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.

    >
    >You probably are referring to these:
    >1. Chris Cox's 'explanation' of the internal format of 15bits+1:
    ><http://groups.google.nl/groups?selm=190520021813529214%ccox@minds
    >pring.com&output=gplain>
    >2. The way Photoshop converts (16-bits to 8-bits)
    ><http://groups.google.com/groups?selm=060620042031159126%ccox@mind
    >spring.com&output=gplain>


    The slight gamma turned out to be from color management, but what I am
    talking about appears to be slightly different from what is discussed in
    the 15-bit + 1, or 16->8-bit discussions. 16-bit greyscale is highly
    posterized. With color management turned off, the count starts:

    0 0 0 1 1 1 1 1 1 3 3 3 3 3 3 ...


    Where is 2? You can't be skipping numbers while others are being
    repeated multiple times; that makes no sense whatsoever.

    The sad fact of the matter is that not only is PS' "16-bit" RGB only
    15-bit, but its "16-bit" greyscale has even less effective bits. Even
    if you perform a bicubic upsampling, you can't get the missing values.
    --

    <>>< ><<> ><<> <>>< ><<> <>>< <>>< ><<>
    John P Sheehy <>
    ><<> <>>< <>>< ><<> <>>< ><<> ><<> <>><
    , Nov 17, 2004
    #14
  15. Guest

    In message <>,
    "Roger N. Clark (change username to rnclark)" <>
    wrote:

    >In my testing of photoshop on real images, I find the following
    >equation:
    >
    > PS = int(IP/2),


    Are you sure it isn't "PS = int((IP+1)/2)"?

    >where PS = the photoshop "16-bit" value and
    >IP = the 16-bit output from ImagesPlus.


    --

    <>>< ><<> ><<> <>>< ><<> <>>< <>>< ><<>
    John P Sheehy <>
    ><<> <>>< <>>< ><<> <>>< ><<> ><<> <>><
    , Nov 17, 2004
    #15
  16. wrote:

    > In message <419b5fc7$0$14941$4all.nl>,
    > "Bart van der Wolf" <> wrote:
    >
    >
    >>"Mike Engles" <> wrote in message
    >>news:...
    >>SNIP
    >>
    >>>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.

    >>
    >>You probably are referring to these:
    >>1. Chris Cox's 'explanation' of the internal format of 15bits+1:
    >><http://groups.google.nl/groups?selm=190520021813529214%ccox@minds
    >>pring.com&output=gplain>
    >>2. The way Photoshop converts (16-bits to 8-bits)
    >><http://groups.google.com/groups?selm=060620042031159126%ccox@mind
    >>spring.com&output=gplain>

    >
    >
    > The slight gamma turned out to be from color management, but what I am
    > talking about appears to be slightly different from what is discussed in
    > the 15-bit + 1, or 16->8-bit discussions. 16-bit greyscale is highly
    > posterized. With color management turned off, the count starts:
    >
    > 0 0 0 1 1 1 1 1 1 3 3 3 3 3 3 ...
    >
    >
    > Where is 2? You can't be skipping numbers while others are being
    > repeated multiple times; that makes no sense whatsoever.
    >
    > The sad fact of the matter is that not only is PS' "16-bit" RGB only
    > 15-bit, but its "16-bit" greyscale has even less effective bits. Even
    > if you perform a bicubic upsampling, you can't get the missing values.


    John:
    Can you send me your 256*256 raw file? I'll take a look at it
    with my tools, including some custom image processing
    unix programs and compare to photoshop and ImagesPlus.

    Roger
    Roger N. Clark (change username to rnclark), Nov 18, 2004
    #16
  17. Guest

    In message <>,
    (Toby Thain) wrote:

    > wrote in message news:<>...
    >> ...
    >> The sad fact of the matter is that not only is PS' "16-bit" RGB only
    >> 15-bit, but its "16-bit" greyscale has even less effective bits. Even
    >> if you perform a bicubic upsampling, you can't get the missing values.


    >That's kind of obvious once you accept that the internal
    >representation is only 15 bits.


    It's not obvious, though, when the missing values are 15-bit values.
    Rather than 32,769 values, there are only about 11,000 values.
    --

    <>>< ><<> ><<> <>>< ><<> <>>< <>>< ><<>
    John P Sheehy <>
    ><<> <>>< <>>< ><<> <>>< ><<> ><<> <>><
    , Nov 18, 2004
    #17
  18. writes:

    >It's not obvious, though, when the missing values are 15-bit values.
    >Rather than 32,769 values, there are only about 11,000 values.


    That is indeed very strange. I can't think of any reason the greyscale
    representation should be any different from one channel of an RGB image.

    Dave
    Dave Martindale, Nov 19, 2004
    #18
  19. Guest

    In message <cnjtnt$ll3$>,
    (Dave Martindale) wrote:

    > writes:


    >>It's not obvious, though, when the missing values are 15-bit values.
    >>Rather than 32,769 values, there are only about 11,000 values.


    >That is indeed very strange. I can't think of any reason the greyscale
    >representation should be any different from one channel of an RGB image.


    Me neither. Just one of a series of many disappointments with PS. This
    happens, I've found, with any conversion to greyscale in "16-bit" mode.
    The color management is different for color and greyscale, too, so if
    you switch back and forth there may be a continual loss of accuracy.

    Someone should tell adobe that we have fast machines now and can work
    with accurate data.
    --

    <>>< ><<> ><<> <>>< ><<> <>>< <>>< ><<>
    John P Sheehy <>
    ><<> <>>< <>>< ><<> <>>< ><<> ><<> <>><
    , Nov 19, 2004
    #19
  20. Guest

    In message <xovnd.646$>,
    "Harvey" <> wrote:

    >15bits gives you 5bits for R,G & B. There's no quality advantage between 15
    >vs. 16bits in terms of quality for RGB handling.


    We're talking "bits per color channel"; not "bits per pixel".

    In 16 bits per pixel, if the extra bit is used for green, it has a big
    image quality advantage. Green is the most significant channel for
    luminance.
    --

    <>>< ><<> ><<> <>>< ><<> <>>< <>>< ><<>
    John P Sheehy <>
    ><<> <>>< <>>< ><<> <>>< ><<> ><<> <>><
    , Nov 20, 2004
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Terry

    8 bit vs 16 bit to print labs

    Terry, Feb 14, 2006, in forum: 35mm Cameras
    Replies:
    4
    Views:
    345
    Alan Browne
    Feb 18, 2006
  2. Tavish Muldoon

    Converting 32 bit to 16 bit color?

    Tavish Muldoon, Sep 17, 2003, in forum: Amateur Video Production
    Replies:
    2
    Views:
    663
    Dan Maas
    Sep 17, 2003
  3. Jim Gunn
    Replies:
    3
    Views:
    412
    a-e-i-o-u-
    Oct 6, 2004
  4. Photoshop CS - 15-bit 16-bit mode.

    , May 16, 2004, in forum: Photoshop Tutorials
    Replies:
    32
    Views:
    3,444
    Toby Thain
    May 24, 2004
  5. Dudley Hanks

    Bit more DOF, bit more light, bit better?

    Dudley Hanks, Mar 26, 2009, in forum: Digital Cameras
    Replies:
    9
    Views:
    266
    Dudley Hanks
    Mar 29, 2009
Loading...

Share This Page