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 |
#121
|
|||
|
|||
On Sun, 21 Nov 2004 20:10:45 GMT, "Mike Russell"
Gama encoding compresses some data values, and there is no reason to do this to raw data from a spacecraft. And, there is no reason to do that to images from digital cameras either, just like Adobe shows to us, the ARC (like most of the other conversion sw too) perform all the processing in the linear domain. Why, for the same reason why linear processing os done in scientific imaging also, to avoid the Gamma Induced Errors. Timo Autiokari http://www.aim-dtp.net |
#122
|
|||
|
|||
wrote in message ... 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. Good to see somebody's awake..................... |
#123
|
|||
|
|||
wrote in message ... 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. Good to see somebody's awake..................... |
#124
|
|||
|
|||
wrote in message ... 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. Good to see somebody's awake..................... |
#125
|
|||
|
|||
Chris Cox wrote in message ...
In article , Dave Martindale wrote: (Toby Thain) writes: I've tried. Their engineer insists that it's 30x faster to work with 15 bit quantities than 16 bit ones. When your source data was probably from a 12-bit ADC, or maybe 14-bit, working with 15 significant bits may indeed be completely adequate. And there *are* advantages to using a representation that has some headroom for "whiter than white" without overflow, and where the representation for "1.0" is a power of 2. But the couple of most recent comments in this thread are about the fact that Photoshop's greyscale doesn't even seem to have 15 significant bits, unlike the RGB representation. The color mode doesn't matter - it's still 16 bit data (0..32768). It's deceptive to characterise that range of values as "16 bit" - it has only 15 bits of dynamic range. Chris |
#126
|
|||
|
|||
Chris Cox wrote in message ...
In article , Dave Martindale wrote: (Toby Thain) writes: I've tried. Their engineer insists that it's 30x faster to work with 15 bit quantities than 16 bit ones. When your source data was probably from a 12-bit ADC, or maybe 14-bit, working with 15 significant bits may indeed be completely adequate. And there *are* advantages to using a representation that has some headroom for "whiter than white" without overflow, and where the representation for "1.0" is a power of 2. But the couple of most recent comments in this thread are about the fact that Photoshop's greyscale doesn't even seem to have 15 significant bits, unlike the RGB representation. The color mode doesn't matter - it's still 16 bit data (0..32768). It's deceptive to characterise that range of values as "16 bit" - it has only 15 bits of dynamic range. Chris |
#127
|
|||
|
|||
In article ,
Toby Thain wrote: Chris Cox wrote in message .. . The color mode doesn't matter - it's still 16 bit data (0..32768). It's deceptive to characterise that range of values as "16 bit" - it has only 15 bits of dynamic range. YM precision. Dynamic range is independent of the number of bits used to represent an image. |
#128
|
|||
|
|||
In article ,
Toby Thain wrote: Chris Cox wrote in message .. . The color mode doesn't matter - it's still 16 bit data (0..32768). It's deceptive to characterise that range of values as "16 bit" - it has only 15 bits of dynamic range. YM precision. Dynamic range is independent of the number of bits used to represent an image. |
#129
|
|||
|
|||
Timo Autiokari writes:
Gama encoding compresses some data values, and there is no reason to do this to raw data from a spacecraft. And, there is no reason to do that to images from digital cameras either, just like Adobe shows to us, the ARC (like most of the other conversion sw too) perform all the processing in the linear domain. Why, for the same reason why linear processing os done in scientific imaging also, to avoid the Gamma Induced Errors. This is all fine if you can preserve the data at the width it was originally captured: at least 12 bits per sample in digital cameras, up to 16 bits for scientific cameras. But if you convert it to 8 bits per sample to save space, you *need* to apply non-linear tone compression to keep sufficient tonal resolution in the shadows. The encoding called "gamma correction" does this very well, even better than taking the logarithm of intensity. But Timo tells people to use 8-bit linear data, which badly quantizes the shadow detail, because he things linear is always better no matter how many bits are used. He's wrong. And it happens that 8 bit gamma-corrected samples are enough to capture the whole intensity range that we can view *in a single image* with few or no quantization artifacts. It is good enough for pictorial images you are going to print, or display on screen. That's why it's so popular - it works just fine for final output in pictorial photography. On the other hand, it's useful to preserve 16 bits of data forever for some applications with high dynamic range (e.g. X-ray images), and some even require floating point to represent. It's often useful to do intermediate computations with 16- or even 32-bit integer or floating point. Dave |
#130
|
|||
|
|||
Timo Autiokari writes:
Gama encoding compresses some data values, and there is no reason to do this to raw data from a spacecraft. And, there is no reason to do that to images from digital cameras either, just like Adobe shows to us, the ARC (like most of the other conversion sw too) perform all the processing in the linear domain. Why, for the same reason why linear processing os done in scientific imaging also, to avoid the Gamma Induced Errors. This is all fine if you can preserve the data at the width it was originally captured: at least 12 bits per sample in digital cameras, up to 16 bits for scientific cameras. But if you convert it to 8 bits per sample to save space, you *need* to apply non-linear tone compression to keep sufficient tonal resolution in the shadows. The encoding called "gamma correction" does this very well, even better than taking the logarithm of intensity. But Timo tells people to use 8-bit linear data, which badly quantizes the shadow detail, because he things linear is always better no matter how many bits are used. He's wrong. And it happens that 8 bit gamma-corrected samples are enough to capture the whole intensity range that we can view *in a single image* with few or no quantization artifacts. It is good enough for pictorial images you are going to print, or display on screen. That's why it's so popular - it works just fine for final output in pictorial photography. On the other hand, it's useful to preserve 16 bits of data forever for some applications with high dynamic range (e.g. X-ray images), and some even require floating point to represent. It's often useful to do intermediate computations with 16- or even 32-bit integer or floating point. Dave |
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 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 |