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. |
|
|
Thread Tools | Display Modes |
#101
|
|||
|
|||
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 |
#102
|
|||
|
|||
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 |
#103
|
|||
|
|||
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 ---^----^--------------------------------------------------------------- |
#104
|
|||
|
|||
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 ---^----^--------------------------------------------------------------- |
#105
|
|||
|
|||
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 ---^----^--------------------------------------------------------------- |
#106
|
|||
|
|||
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 ---^----^--------------------------------------------------------------- |
#107
|
|||
|
|||
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 ---^----^--------------------------------------------------------------- |
#108
|
|||
|
|||
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 ---^----^--------------------------------------------------------------- |
#109
|
|||
|
|||
|
#110
|
|||
|
|||
|
Thread Tools | |
Display Modes | |
|
|
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 |