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
  #15  
Old November 17th 04, 12:58 AM
[email protected]
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
---^----^---------------------------------------------------------------
  #16  
Old November 17th 04, 12:58 AM
[email protected]
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
---^----^---------------------------------------------------------------
 




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 01: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 03:35 PM


All times are GMT +1. The time now is 03:38 PM.


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