A Photography forum. PhotoBanter.com

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » PhotoBanter.com forum » Digital Photography » Digital Photography
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

"16-bit" mode.



 
 
Thread Tools Display Modes
  #1  
Old November 16th 04, 05:28 AM
external usenet poster
 
Posts: n/a
Default "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

  #4  
Old November 16th 04, 10:43 PM
external usenet poster
 
Posts: n/a
Default

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

  #5  
Old November 17th 04, 01:58 AM
external usenet poster
 
Posts: n/a
Default

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
---^----^---------------------------------------------------------------
  #7  
Old November 18th 04, 12:07 AM
external usenet poster
 
Posts: n/a
Default

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

  #10  
Old November 18th 04, 12:07 AM
external usenet poster
 
Posts: n/a
Default

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

 




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

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Sony Cybershot P100 VX '640x480' movie mode is fake Mark Elkington Digital Photography 17 November 2nd 04 02:24 AM
What's the D300's "Close-up mode" for? Darryl Digital Photography 10 September 23rd 04 05:11 PM
Q-Confused about which picture record mode to use in a digital camera. Mr. Rather B. Beachen Digital Photography 1 July 13th 04 01:50 AM
What image quality mode to use? Mr. Rather B. Beachen Digital Photography 2 July 13th 04 01:21 AM
wireless 550EX in manual mode with 420EX danny Other Photographic Equipment 1 February 15th 04 04:35 PM


All times are GMT +1. The time now is 11:14 AM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 PhotoBanter.com.
The comments are property of their posters.