PhotoBanter.com

PhotoBanter.com (http://www.photobanter.com/index.php)
-   Digital Photography (http://www.photobanter.com/forumdisplay.php?f=5)
-   -   "16-bit" mode. (http://www.photobanter.com/showthread.php?t=19356)

[email protected] November 16th 04 05:28 AM

"16-bit" mode.
 
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


Ken Weitzel November 16th 04 06:03 AM



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 November 16th 04 06:03 AM



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 November 16th 04 06:03 AM



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


[email protected] November 16th 04 08:29 PM

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

[email protected] November 16th 04 08:29 PM

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

[email protected] November 16th 04 10:43 PM

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


[email protected] November 16th 04 10:43 PM

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


[email protected] November 16th 04 10:52 PM

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


[email protected] November 16th 04 10:52 PM

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



All times are GMT +1. The time now is 08:00 PM.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
PhotoBanter.com