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 22nd 04 04:02 AM

In message ,
Chris Cox wrote:

In article ,
wrote:


It is exactly what is happening here. I get 0, 1, 3, 4, 5, 8, etc. No
2, 6, 7, 11, etc, at all, no matter what is done to the data.


And, again, without your original data - I can't guess what could have
gone wrong.

I do know that for anyone else doing a similar experiment (inside and
outside Adobe), they get the full 32769 values.


I already told what the data was - a binary file with the 16-bit
unsigned values 0 through 65535. That's it:

00 00 01 00 02 00 03 00 .... fb ff fc ff fd ff fe ff ff ff

load as .raw, 256*256, 1 channel, 16-bit, IBM/PC, 0 header.

Lots of values posterized, beyond the 2-1 you'd expect from 16-15 bit.

Subsequently, I have tried greyscale with new file as well, and the same
thing happens. Lots of values don't exist, no matter how much you crush
the levels, blur, etc. They are simply impossible.

This happens on two completely independent PCs with CS installed, so it
can't be a binary corruption, unless something was corrupt off the CD.

Have you actually seen the values 2, 6, 7, or 11 in 16-bit greyscale
mode (w/16-bit checked in "Info") with color management disabled?
Recently?
--


John P Sheehy


[email protected] November 22nd 04 04:02 AM

In message ,
Chris Cox wrote:

In article ,
wrote:


It is exactly what is happening here. I get 0, 1, 3, 4, 5, 8, etc. No
2, 6, 7, 11, etc, at all, no matter what is done to the data.


And, again, without your original data - I can't guess what could have
gone wrong.

I do know that for anyone else doing a similar experiment (inside and
outside Adobe), they get the full 32769 values.


I already told what the data was - a binary file with the 16-bit
unsigned values 0 through 65535. That's it:

00 00 01 00 02 00 03 00 .... fb ff fc ff fd ff fe ff ff ff

load as .raw, 256*256, 1 channel, 16-bit, IBM/PC, 0 header.

Lots of values posterized, beyond the 2-1 you'd expect from 16-15 bit.

Subsequently, I have tried greyscale with new file as well, and the same
thing happens. Lots of values don't exist, no matter how much you crush
the levels, blur, etc. They are simply impossible.

This happens on two completely independent PCs with CS installed, so it
can't be a binary corruption, unless something was corrupt off the CD.

Have you actually seen the values 2, 6, 7, or 11 in 16-bit greyscale
mode (w/16-bit checked in "Info") with color management disabled?
Recently?
--


John P Sheehy


[email protected] November 22nd 04 04:03 AM

Kibo informs me that Chris Cox stated that:

In article ,
wrote:
It is exactly what is happening here. I get 0, 1, 3, 4, 5, 8, etc. No
2, 6, 7, 11, etc, at all, no matter what is done to the data.


And, again, without your original data - I can't guess what could have
gone wrong.

I do know that for anyone else doing a similar experiment (inside and
outside Adobe), they get the full 32769 values.


Yeah, that's what I would've expected. I find it impossible to believe
that PS could be getting it that badly wrong without it showing up in a
dozen different, really obvious ways.
And speaking of supplying original data, where the hell does Adobe keep
the PS raw file format doc's that used to be on the website? - I wanted
to try John's experiment for myself, but all I could find was the PS
SDK, for which Adobe wants money.

--
W
. | ,. w , "Some people are alive only because
\|/ \|/ it is illegal to kill them." Perna condita delenda est
---^----^---------------------------------------------------------------

[email protected] November 22nd 04 04:03 AM

Kibo informs me that Chris Cox stated that:

In article ,
wrote:
It is exactly what is happening here. I get 0, 1, 3, 4, 5, 8, etc. No
2, 6, 7, 11, etc, at all, no matter what is done to the data.


And, again, without your original data - I can't guess what could have
gone wrong.

I do know that for anyone else doing a similar experiment (inside and
outside Adobe), they get the full 32769 values.


Yeah, that's what I would've expected. I find it impossible to believe
that PS could be getting it that badly wrong without it showing up in a
dozen different, really obvious ways.
And speaking of supplying original data, where the hell does Adobe keep
the PS raw file format doc's that used to be on the website? - I wanted
to try John's experiment for myself, but all I could find was the PS
SDK, for which Adobe wants money.

--
W
. | ,. w , "Some people are alive only because
\|/ \|/ it is illegal to kill them." Perna condita delenda est
---^----^---------------------------------------------------------------

[email protected] November 22nd 04 04:05 AM

Kibo informs me that "Harvey" stated that:

"Toby Thain" wrote in message
. com...
wrote in message
Someone should tell adobe that we have fast machines now and can work
with accurate data.


I've tried. Their engineer insists that it's 30x faster to work with
15 bit quantities than 16 bit ones.


They're correct - it is.

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


You're thinking of the HiColour video modes. The 15 bits we've been
talking about in PS is 15 bits *per colour*, per pixel, ie; a total of
45 bits per pixel.

--
W
. | ,. w , "Some people are alive only because
\|/ \|/ it is illegal to kill them." Perna condita delenda est
---^----^---------------------------------------------------------------

[email protected] November 22nd 04 04:05 AM

Kibo informs me that "Harvey" stated that:

"Toby Thain" wrote in message
. com...
wrote in message
Someone should tell adobe that we have fast machines now and can work
with accurate data.


I've tried. Their engineer insists that it's 30x faster to work with
15 bit quantities than 16 bit ones.


They're correct - it is.

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


You're thinking of the HiColour video modes. The 15 bits we've been
talking about in PS is 15 bits *per colour*, per pixel, ie; a total of
45 bits per pixel.

--
W
. | ,. w , "Some people are alive only because
\|/ \|/ it is illegal to kill them." Perna condita delenda est
---^----^---------------------------------------------------------------

[email protected] November 22nd 04 04:11 AM

Kibo informs me that Ken Weitzel stated that:



Matt Austern wrote:

Chris Cox writes:


I've tried. Their engineer insists that it's 30x faster to work with
15 bit quantities than 16 bit ones.

Which is correct (for 0..32768 representation versus 0..65535
representation).



Perhaps this is offtopic, and perhaps you can't answer it without
revealing proprietary information, but can you explain why 15-bit
computation should be so much faster than 16-bit? (If there's a
publication somewhere you could point me to, that would be great.)
I've thought about this for a few minutes, I haven't been able to
think of an obvious reason, and now I'm curious.

Feel free to email me if you think this wouldn't be interesting to
anyone else.



Hi Matt...

Nor can I see even the slightest difference. None at all.

So - I suspect that we're looking at it from the wrong
end. Suspect it's the a/d converter that could be the
bottleneck?


Unluss I've totally misunderstood John's description, none of this data
has been anywhere near an A2D converter.

8 bits are common; 15 bit's are common. 18 bit
are available but seldom used. Never heard of 16.
Maybe that's it?


Nope. (BTW, 16 bits is standard for audio work, including CDs, & 12 bits
is standard for DSLRs.)

--
W
. | ,. w , "Some people are alive only because
\|/ \|/ it is illegal to kill them." Perna condita delenda est
---^----^---------------------------------------------------------------

[email protected] November 22nd 04 04:11 AM

Kibo informs me that Ken Weitzel stated that:



Matt Austern wrote:

Chris Cox writes:


I've tried. Their engineer insists that it's 30x faster to work with
15 bit quantities than 16 bit ones.

Which is correct (for 0..32768 representation versus 0..65535
representation).



Perhaps this is offtopic, and perhaps you can't answer it without
revealing proprietary information, but can you explain why 15-bit
computation should be so much faster than 16-bit? (If there's a
publication somewhere you could point me to, that would be great.)
I've thought about this for a few minutes, I haven't been able to
think of an obvious reason, and now I'm curious.

Feel free to email me if you think this wouldn't be interesting to
anyone else.



Hi Matt...

Nor can I see even the slightest difference. None at all.

So - I suspect that we're looking at it from the wrong
end. Suspect it's the a/d converter that could be the
bottleneck?


Unluss I've totally misunderstood John's description, none of this data
has been anywhere near an A2D converter.

8 bits are common; 15 bit's are common. 18 bit
are available but seldom used. Never heard of 16.
Maybe that's it?


Nope. (BTW, 16 bits is standard for audio work, including CDs, & 12 bits
is standard for DSLRs.)

--
W
. | ,. w , "Some people are alive only because
\|/ \|/ it is illegal to kill them." Perna condita delenda est
---^----^---------------------------------------------------------------

[email protected] November 22nd 04 04:18 AM

In message ,
wrote:

And speaking of supplying original data, where the hell does Adobe keep
the PS raw file format doc's that used to be on the website? - I wanted
to try John's experiment for myself, but all I could find was the PS
SDK, for which Adobe wants money.


You don't need to enter through .raw to see the problem; just open a new
2x1 pixel document in greyscale mode. Convert to 16-bit. Bicubic
resize the 2x1 pixel image to 500x1. Set "Info" to give 16-bit values.
Make sure the color sampling tool is set to single pixel. put the
pointer over the string of pixels. See if there are any gaps in the
numbers.
--


John P Sheehy


[email protected] November 22nd 04 04:18 AM

In message ,
wrote:

And speaking of supplying original data, where the hell does Adobe keep
the PS raw file format doc's that used to be on the website? - I wanted
to try John's experiment for myself, but all I could find was the PS
SDK, for which Adobe wants money.


You don't need to enter through .raw to see the problem; just open a new
2x1 pixel document in greyscale mode. Convert to 16-bit. Bicubic
resize the 2x1 pixel image to 500x1. Set "Info" to give 16-bit values.
Make sure the color sampling tool is set to single pixel. put the
pointer over the string of pixels. See if there are any gaps in the
numbers.
--


John P Sheehy



All times are GMT +1. The time now is 09:24 PM.

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