Re[2]: Understanding ProPhoto RGB - or not
Hello Rob, Tuesday, December 12, 2006, 2:36:36 PM, you wrote: DIS> It's true, the colour gamut of most camera sensors is far greater than DIS> sRGB or AdobeRGB and most aren't even fully contained within the DIS> ProPhoto RGB CS. The colours that the camera is capable of recording DIS> are clipped and compressed to fit into the Adobe RGB and sRGB colour DIS> spaces, the colours outside the selected colour space are lost at that DIS> point. DIS> -- DIS> Rob Studdert DIS> HURSTVILLE AUSTRALIA DIS> Tel +61-2-9554-4110 DIS> UTC(GMT) +10 Hours DIS> [EMAIL PROTECTED] DIS> http://home.swiftdsl.com.au/~distudio//publications/ DIS> Pentax user since 1986, PDMLer since 1998 OK so camera sensors are actually capable of producing colors outside of AdobeRGB. But when the cameras write the data in RAW files on the cards, all this gets clipped/compressed/transformed (insert correct term here) to AdobeRGB. Then what's the point in working in ProPhotoRGB? Can the raw converters by some magic undo the transformation to AdobeRGB made by the cameras? I'm really confused now. -- Attila -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net
Re[2]: Understanding ProPhoto RGB - or not
Hello Mark, Tuesday, December 12, 2006, 4:06:14 PM, you wrote: MR> The color space settings on your camera only affect JPEG capture. MR> Reichmann is talking about shooting RAW, in which case you're getting MR> the (hardware-dependent) color space of the camera's sensor (and you MR> select final color space during RAW conversion). Thanks Mark! I thought the color space setting affects both JPEG and RAW, my bad. Now the article makes sense. -- Attila -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net
Re[2]: Understanding ProPhoto RGB - or not
Hello Patrice, Wednesday, December 13, 2006, 12:23:41 AM, you wrote: PLG> I've imagined a lengthy, but very accurate metaphor for this: PLG> Imagine you have a field of land. It is your color space. It contains PLG> flowers and trees (each of them is a different color). You want to PLG> measure the positions of these flowers and trees in this field (each PLG> position corresponds to a given color). You can do so by dividing the PLG> field in equal portions, marked by poles. You can't position a tree in PLG> the field in a better precision than the distance between two poles. The PLG> problem is that you only have a limited number of poles. PLG> Now you are given the choice between a smaller field (sRGB color space) PLG> and a larger field (ProPhoto). The smaller field is contained in the PLG> larger one, so there are trees that are in the larger field, but not in PLG> the smaller field (these are very saturated colors.) You want the larger PLG> field to get an image correctly measured if important parts of this PLG> image (a lot of the trees) are only in the larger field. PLG> But this comes at a price. As you still have the same amount of poles PLG> whichever field you choose (say 256x256), if the larger field is chosen, PLG> more land needs to be covered, then the poles will be planted wider PLG> apart from each other. You can measure more land, but with less precision. PLG> If you chose to map the larger field, but all your trees are in the PLG> smaller anyway, all you get, regarding YOUR trees, is a coarser precision. Thanks Patrice, that was a very good metaphor. PLG> Therefore, for an image with important detail in saturated colors PLG> (flowers?), consider working with a wide color space. If you're pretty PLG> sure your image only contains colors with lower saturation (portrait?), PLG> prefer a narrower color space and you'll have a better rendition of most PLG> of your image. PLG> Or, use not 256 poles in each direction, but 65536 (16 bit instead of 8) PLG> throughout your workflow, and use wide color space until the very last PLG> point. So there is really no silver bullet, and I should consider choosing a color space based on what kind of image I'm working with, and what the final output will be, and working with ProPhotoRGB in 16 bit is just a safe bet. Then the final step will be to convert to sRGB before saving for web. Can there be a loss of image detail/color when I perform such a conversion? Let's say I have an image which fits perfectly into sRGB. A.) - I use ACR to open the image in Photoshop using ProphotoRGB. - Apply levels, curves, sharpening etc. - Convert to sRGB then save for web. B.) - I use ACR to ipen the image in Photoshop using sRGB. - Apply levels, curves, sharpening etc. - No need to convert, this is already sRGB so just save for web. Assuming that in both cases I work in 16 bits/channel mode will there be any differences between A.) and B.)? With other words, can colorspace conversions lead to a loss of information? It would seem that in B.) there is no color space conversion, it's sRGB all the way, but there is a catch: the article says that ProPhotoRGB is Camera Raw's native colour space. So if I get this right there will be a conversion in both cases. PLG> Just my 2 cents (a bit long, but these are Euro cents). Thank you Patrice, it is well worth it:) -- Attila -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net
Re: Re[2]: Understanding ProPhoto RGB - or not
Boros Attila wrote: >OK so camera sensors are actually capable of producing colors outside >of AdobeRGB. But when the cameras write the data in RAW files on the >cards, all this gets clipped/compressed/transformed (insert correct >term here) to AdobeRGB. No it doesn't. It doesn't get converted to *any* other colorspace until you do RAW conversion. -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net
Re: Re[2]: Understanding ProPhoto RGB - or not
>> OK so camera sensors are actually capable of producing colors outside >> of AdobeRGB. But when the cameras write the data in RAW files on the >> cards, all this gets clipped/compressed/transformed (insert correct >> term here) to AdobeRGB. > > No it doesn't. > It doesn't get converted to *any* other colorspace until you do RAW > conversion. > What about the K10D's 22-bit -> 1[246]-bit(?) lossy conversion to RAW? Somewhere in the signal chain the camera's processor decided to throw something away. -Cory -- * * Cory Papenfuss, Ph.D., PPSEL-IA * * Electrical Engineering* * Virginia Polytechnic Institute and State University * * -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net
Re: Re[2]: Understanding ProPhoto RGB - or not
Cory Papenfuss wrote: >>> OK so camera sensors are actually capable of producing colors outside >>> of AdobeRGB. But when the cameras write the data in RAW files on the >>> cards, all this gets clipped/compressed/transformed (insert correct >>> term here) to AdobeRGB. >> >> No it doesn't. >> It doesn't get converted to *any* other colorspace until you do RAW >> conversion. >> > What about the K10D's 22-bit -> 1[246]-bit(?) lossy conversion to >RAW? Somewhere in the signal chain the camera's processor decided to >throw something away. Changing sample size doesn't have to change color space. You can change a 16-bit Adobe RGB image to 8-bit and it'll still be in Adobe RGB. -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net
Re: Re[2]: Understanding ProPhoto RGB - or not
On Dec 12, 2006, at 8:52 AM, Cory Papenfuss wrote: >>> OK so camera sensors are actually capable of producing colors >>> outside >>> of AdobeRGB. But when the cameras write the data in RAW files on the >>> cards, all this gets clipped/compressed/transformed (insert correct >>> term here) to AdobeRGB. >> >> No it doesn't. >> It doesn't get converted to *any* other colorspace until you do RAW >> conversion. >> > What about the K10D's 22-bit -> 1[246]-bit(?) lossy conversion to > RAW? Somewhere in the signal chain the camera's processor decided to > throw something away. The 22bit quantization of the analog signal presents a more accurate reflection of photosite voltage levels. Subsampling that to 12 bit representation afterwards is always going to be a more accurate representation of the sensor capture than using smaller quantization space for the A->D conversion. All conversions have some loss associated. The goal is to minimize the losses. Godfrey -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net
Re: Re[2]: Understanding ProPhoto RGB - or not
On Dec 12, 2006, at 8:52 AM, Cory Papenfuss wrote: >>> OK so camera sensors are actually capable of producing colors >>> outside >>> of AdobeRGB. But when the cameras write the data in RAW files on the >>> cards, all this gets clipped/compressed/transformed (insert correct >>> term here) to AdobeRGB. >> >> No it doesn't. >> It doesn't get converted to *any* other colorspace until you do RAW >> conversion. >> > What about the K10D's 22-bit -> 1[246]-bit(?) lossy conversion to > RAW? Somewhere in the signal chain the camera's processor decided to > throw something away. The 22bit quantization of the analog signal presents a more accurate reflection of photosite voltage levels. Subsampling that to 12 bit representation afterwards is always going to be a more accurate representation of the sensor capture than using smaller quantization space for the A->D conversion. All conversions have some loss associated. The goal is to minimize the losses. Godfrey -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net
Re: Re[2]: Understanding ProPhoto RGB - or not
>>> No it doesn't. >>> It doesn't get converted to *any* other colorspace until you do RAW >>> conversion. >>> >> What about the K10D's 22-bit -> 1[246]-bit(?) lossy conversion to >> RAW? Somewhere in the signal chain the camera's processor decided to >> throw something away. > > Changing sample size doesn't have to change color space. You can change > a 16-bit Adobe RGB image to 8-bit and it'll still be in Adobe RGB. > Yeah, I'm aware of that. I guess I thought it was obvious that having a 22-bit A/D converter is only useful if it wasn't blindly truncated to 12-bits. The "non-blind" operation includes dynamic range choices on a per-channel basis. That *could* also include taking the colorspace into account. I'm not saying I know how it's done... just trying to provide food for thought. RAW isn't RAW anymore if the 22-bits have been truncated on a per-channel basis to 12... -Cory -- * * Cory Papenfuss, Ph.D., PPSEL-IA * * Electrical Engineering* * Virginia Polytechnic Institute and State University * * -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net
Re: Re[2]: Understanding ProPhoto RGB - or not
On Dec 12, 2006, at 12:06 PM, Cory Papenfuss wrote: > I'm not saying I know how it's done... just trying to provide food > for thought. RAW isn't RAW anymore if the 22-bits have been > truncated on > a per-channel basis to 12... RAW format has always been what was written from the sensor into a digital representation, a 2D array of photosite values along with metadata describing the camera state and organization of that array, no matter what transformations or A-D conversion methodology has been. G -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net
Re: Re[2]: Understanding ProPhoto RGB - or not
> On Dec 12, 2006, at 12:06 PM, Cory Papenfuss wrote: > >> I'm not saying I know how it's done... just trying to provide food >> for thought. RAW isn't RAW anymore if the 22-bits have been >> truncated on >> a per-channel basis to 12... > > RAW format has always been what was written from the sensor into a > digital representation, a 2D array of photosite values along with > metadata describing the camera state and organization of that array, > no matter what transformations or A-D conversion methodology has been. > Right. It isn't anymore unless the RAW file has 22-bits of data per photosite. If it's 22-bits truncated to the 12 most-significant bits, there's no reason for 22-bits to begin with. One would expect that the "most relevant" 12-bits of dynamic range would be chosen to truncate into the 12 for a RAW file. The "most relevant" is the part that could be new. With previous cameras with 12-bit A/D's, one could be reasonably certain that ALL data captured was recorded in the file. That is no longer the case. -Cory -- * * Cory Papenfuss, Ph.D., PPSEL-IA * * Electrical Engineering* * Virginia Polytechnic Institute and State University * * -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net
Re: Re[2]: Understanding ProPhoto RGB - or not
On Dec 12, 2006, at 1:20 PM, Cory Papenfuss wrote: >> RAW format has always been what was written from the sensor into a >> digital representation, a 2D array of photosite values along with >> metadata describing the camera state and organization of that array, >> no matter what transformations or A-D conversion methodology has >> been. >> > Right. It isn't anymore unless the RAW file has 22-bits of data > per photosite. > > If it's 22-bits truncated to the 12 most-significant bits, > there's no reason for 22-bits to begin with. One would expect that > the > "most relevant" 12-bits of dynamic range would be chosen to > truncate into > the 12 for a RAW file. The "most relevant" is the part that could > be new. > > With previous cameras with 12-bit A/D's, one could be reasonably > certain that ALL data captured was recorded in the file. That is no > longer the case. Thats not true. Nikon and Canon both do a lot of their own sensor to digital representation processing too, ya know? And their RAW data is just as much RAW as anyone else's. I don't know what quantization they use in their A-D converter; I suspect it's greater than 12 bits at least in the higher end cameras ... I suspect 14 or 16 bit, it would have to be if they're concerned with round-off error in modeling the voltages for a good 12 bit representation. Pentax has gone beyond that with a 22 bit A-D, which makes much more accurate 12 bit output. 22 bit quantization vs other cameras' 12, 14 or 16 bit quantization renders better modeling of the voltages regardless of whether the output digital representation is further reduced to 12 bit or not. I don't presume to know what Pentax did in tuning the A->D converter and subsequent 22->12 bit transformation, but whatever the body writes to the RAW format file as sensor date is, by definition, the camera's RAW format data. You can't get at or use anything more anyway so there's no point in debating it. Godfrey -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net
Re: Re[2]: Understanding ProPhoto RGB - or not
On 13/12/06, Boros Attila <[EMAIL PROTECTED]> wrote: > Hello Mark, > > Tuesday, December 12, 2006, 4:06:14 PM, you wrote: > > MR> The color space settings on your camera only affect JPEG capture. > MR> Reichmann is talking about shooting RAW, in which case you're getting > MR> the (hardware-dependent) color space of the camera's sensor (and you > MR> select final color space during RAW conversion). > Thanks Mark! I thought the color space setting affects both JPEG and > RAW, my bad. Now the article makes sense. Sorry I should have been specific. The point is that you can always convert to a smaller colourspace and retain the essence of the colour spread of the image but once the colour data I compressed/clipped it can't be recovered. The problem when working with wide colourspaces is that generally it's preferable to work at higher bit depth in order to prevent posterization. It's pretty much generally accepted that files should remain in 16 bits/colour depth when working in ProPhoto RGB. Commercial print services generally require sRGB souce however the occasional one will provide custom profiles, in most cases sRGB will be adequte. But often printer profiles for newer colour ink-jet printers are wider than sRGB or Adobe RGB so choosing either of these colourspaces as your source or workspace or finally converting to either during save may reduce the potential quality of your prints. -- Rob Studdert HURSTVILLE AUSTRALIA Tel +61-2-9554-4110 UTC(GMT) +10 Hours [EMAIL PROTECTED] http://home.swiftdsl.com.au/~distudio//publications/ Pentax user since 1986, PDMLer since 1998 -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net
Re: Re[2]: Understanding ProPhoto RGB - or not
> Thats not true. Nikon and Canon both do a lot of their own sensor to > digital representation processing too, ya know? And their RAW data is > just as much RAW as anyone else's. I don't know what quantization > they use in their A-D converter; I suspect it's greater than 12 bits > at least in the higher end cameras ... I suspect 14 or 16 bit, it > would have to be if they're concerned with round-off error in > modeling the voltages for a good 12 bit representation. Pentax has > gone beyond that with a 22 bit A-D, which makes much more accurate 12 > bit output. 22 bit quantization vs other cameras' 12, 14 or 16 bit > quantization renders better modeling of the voltages regardless of > whether the output digital representation is further reduced to 12 > bit or not. > Umm... sorry. I'll have to throw the "bullshit flag" on that play. If one measures and analog voltage at 22-bits, does nothing to it, and then throws away the least-significant 10 bits to produce 12-bits, the results are absolutely identical to another who quantizes at 12-bits to begin with. Only if "mid-processing" (i.e. processing between the data measurement and RAW file writing) is done is there a difference. That "mid-processing" is precisely the unknown that I'm talking about, but one would assume that some was done. Most likely the reason for using 22-bits was so that variable-gain analog amplifiers and fixed-full-scale-voltage A/D's were NOT used. For ISO 100, choose bits 10-22. For ISO 200 choose bits 9-21. ISO 400 choose 8-20, etc, etc. Now, for example, if one were to apply a cloudy WB vs. a tungsten WB, the red channel gain would likely be at least a bit (i.e. f-stop) or two different. It makes sense to chose a different "dynamic range" for each channel based on things like WB (and by association colorspace). > I don't presume to know what Pentax did in tuning the A->D converter > and subsequent 22->12 bit transformation, but whatever the body > writes to the RAW format file as sensor date is, by definition, the > camera's RAW format data. > Yes, but no longer presumed to be an unaltered digitized version of exactly what the sensor sees. > You can't get at or use anything more anyway so there's no point in > debating it. > If you get the white-balance wrong, you only get 10 or 11 (linear) bits of the red channel in the example I proposed above. That does make a difference. For the most part, this is speculation since nobody but the image-processing software guys at Pentax know for sure. I'm just saying that not only is what I'm suggesting possible, it's rather *likely* given that they're trying to exploit the additional data available. -Cory -- * * Cory Papenfuss, Ph.D., PPSEL-IA * * Electrical Engineering* * Virginia Polytechnic Institute and State University * * -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net
Re: Re[2]: Understanding ProPhoto RGB - or not
On Dec 12, 2006, at 5:54 PM, Cory Papenfuss wrote: > Umm... sorry. I'll have to throw the "bullshit flag" on that > play. If one measures and analog voltage at 22-bits, does nothing > to it, > and then throws away the least-significant 10 bits to produce 12- > bits, the > results are absolutely identical to another who quantizes at 12- > bits to > begin with. Only if "mid-processing" (i.e. processing between the > data > measurement and RAW file writing) is done is there a difference. That > "mid-processing" is precisely the unknown that I'm talking about, > but one > would assume that some was done. I didn't say no processing was done. You did. It was stated in one of the interviews with the engineers that Ken translated that they took opportunities to do signal processing due to the 22bit A-D that were not otherwise feasible. >> I don't presume to know what Pentax did in tuning the A->D converter >> and subsequent 22->12 bit transformation, but whatever the body >> writes to the RAW format file as sensor date is, by definition, the >> camera's RAW format data. >> > Yes, but no longer presumed to be an unaltered digitized version > of exactly what the sensor sees. It never has been. Transformations occur between photosite and digital representation in all cases that I'm aware of ... that's what all the custom signal processing chips in these cameras are all about, in part at least. > >> You can't get at or use anything more anyway so there's no point in >> debating it. >> > If you get the white-balance wrong, you only get 10 or 11 (linear) > bits of the red channel in the example I proposed above. That does > make a > difference. > > For the most part, this is speculation since nobody but the > image-processing software guys at Pentax know for sure. I'm just > saying > that not only is what I'm suggesting possible, it's rather *likely* > given > that they're trying to exploit the additional data available. But as I said above, the whole concern is nonsensical and pure speculation because you only get the RAW data the camera writes anyway. And the little working with the K10D that I have done so far indicates pretty clearly that it has exceptionally good image quality, even compared with the *ist DS which also has very very good image quality. The K10D has "better" 12 bit RAW data, in other words. I think that it is in part due to the 22bit A-D and whatever data massaging they do in that space, at least in part. If you want to continue to speculate for no particular reason, well, be my guest. Godfrey -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net
Re: Re[2]: Understanding ProPhoto RGB - or not
On 13/12/06, Cory Papenfuss <[EMAIL PROTECTED]> wrote: > Umm... sorry. I'll have to throw the "bullshit flag" on that > play. If one measures and analog voltage at 22-bits, does nothing to it, > and then throws away the least-significant 10 bits to produce 12-bits, the > results are absolutely identical to another who quantizes at 12-bits to > begin with. Only if "mid-processing" (i.e. processing between the data > measurement and RAW file writing) is done is there a difference. That > "mid-processing" is precisely the unknown that I'm talking about, but one > would assume that some was done. Other arguments I've heard raised were that even if the last 8 bits of the 22bit ADC were recording purely noise the remaining bits would record more linear steps given that the ADCs imprecision lies mainly in the low bit range. > Most likely the reason for using 22-bits was so that variable-gain > analog amplifiers and fixed-full-scale-voltage A/D's were NOT used. For > ISO 100, choose bits 10-22. For ISO 200 choose bits 9-21. ISO 400 choose > 8-20, etc, etc. > > Now, for example, if one were to apply a cloudy WB vs. a tungsten > WB, the red channel gain would likely be at least a bit (i.e. f-stop) or > two different. It makes sense to chose a different "dynamic range" for > each channel based on things like WB (and by association colorspace). If Pentax are using the Nucore NDX-2240 AFE on the front end of their PRIME Image Processor (which hasn't been denied and was rumored to be confirmed) the it provides what they deem as a "color sensitive PGA" prior to the input to the 22 bit ADC. You can read up more here: http://www.nucoretech.com/nu3/images/80_downloads/pres_technology.ppt.us.pdf -- Rob Studdert HURSTVILLE AUSTRALIA Tel +61-2-9554-4110 UTC(GMT) +10 Hours [EMAIL PROTECTED] http://home.swiftdsl.com.au/~distudio//publications/ Pentax user since 1986, PDMLer since 1998 -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net
Re: Re[2]: Understanding ProPhoto RGB - or not
On Tue, Dec 12, 2006 at 08:54:25PM -0500, Cory Papenfuss wrote: > > Most likely the reason for using 22-bits was so that variable-gain > analog amplifiers and fixed-full-scale-voltage A/D's were NOT used. For > ISO 100, choose bits 10-22. For ISO 200 choose bits 9-21. ISO 400 choose > 8-20, etc, etc. But 22 bits is enough to measure 4 million discrete signal levels. That's far more than is needed - even the most optimistic estimates of the full well capacity of the sensor don't go beyond 100,000 or so electrons. You need 17 bits to count that high. Add one or two guard bits to take care of round-off errors in the calculations, and you'd still be OK with 19. In fact if you're going to end up with a 12-bit RAW output file I'd bet nobody would see the difference between the 22-bit PRIME processor of the K10D and a 16-bit processing engine. At best, this is for design compatibility with future systems (such as the 645D, or maybe a K1D) that will use the 16-bit output version of the processing chip; alternatively, it's just meaningless marketing. -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net
RE: Re[2]: Understanding ProPhoto RGB - or not
I bet the 22 bit deal is so they dont get the degenerative interpolation errors with the various digital signal processes that they would have gotten if they stayed at 16 bit or lower max. jco -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Francis Sent: Tuesday, December 12, 2006 9:40 PM To: Pentax-Discuss Mail List Subject: Re: Re[2]: Understanding ProPhoto RGB - or not On Tue, Dec 12, 2006 at 08:54:25PM -0500, Cory Papenfuss wrote: > > Most likely the reason for using 22-bits was so that variable-gain > analog amplifiers and fixed-full-scale-voltage A/D's were NOT used. For > ISO 100, choose bits 10-22. For ISO 200 choose bits 9-21. ISO 400 choose > 8-20, etc, etc. But 22 bits is enough to measure 4 million discrete signal levels. That's far more than is needed - even the most optimistic estimates of the full well capacity of the sensor don't go beyond 100,000 or so electrons. You need 17 bits to count that high. Add one or two guard bits to take care of round-off errors in the calculations, and you'd still be OK with 19. In fact if you're going to end up with a 12-bit RAW output file I'd bet nobody would see the difference between the 22-bit PRIME processor of the K10D and a 16-bit processing engine. At best, this is for design compatibility with future systems (such as the 645D, or maybe a K1D) that will use the 16-bit output version of the processing chip; alternatively, it's just meaningless marketing. -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net
Re: Re[2]: Understanding ProPhoto RGB - or not
On 13/12/06, Cory Papenfuss <[EMAIL PROTECTED]> wrote: > Now, for example, if one were to apply a cloudy WB vs. a tungsten > WB, the red channel gain would likely be at least a bit (i.e. f-stop) or > two different. It makes sense to chose a different "dynamic range" for > each channel based on things like WB (and by association colorspace). Just being pedantic but you allude in the above paragraph that Colorspace is dependent on "dynamic range" however it's not, inappropriate choice of WB may cause some colours to clip in certain circumstances but it doesn't alter the sensors colour response. Just consider the scenario of a sensor which has acute sensitivity to near UV and near visible IR but very poor green response. It could feed into a 4 bit ADC but would still require a very wide colorspace to adequately describe/contain it's colour response. -- Rob Studdert HURSTVILLE AUSTRALIA Tel +61-2-9554-4110 UTC(GMT) +10 Hours [EMAIL PROTECTED] http://home.swiftdsl.com.au/~distudio//publications/ Pentax user since 1986, PDMLer since 1998 -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net
Re: Re[2]: Understanding ProPhoto RGB - or not
> I didn't say no processing was done. You did. It was stated in one of > the interviews with the engineers that Ken translated that they took > opportunities to do signal processing due to the 22bit A-D that were > not otherwise feasible. > ... *before*. The common thought previously was that RAW provided unaltered A/D data of the sensor. That may or may not have been true, but at least it *could* have been. Now with truncation necessary, it *cannot* be true that a RAW file contains unaltered digitzed sensor data. >> Yes, but no longer presumed to be an unaltered digitized version >> of exactly what the sensor sees. > > It never has been. Transformations occur between photosite and > digital representation in all cases that I'm aware of ... that's what > all the custom signal processing chips in these cameras are all > about, in part at least. I'm curious as to what these transformations are. The only ones I can think of off the top of my head are dark-frame subtraction noise reduction and possibly hot/dead pixel removal. >> For the most part, this is speculation since nobody but the >> image-processing software guys at Pentax know for sure. I'm just >> saying >> that not only is what I'm suggesting possible, it's rather *likely* >> given >> that they're trying to exploit the additional data available. > > > But as I said above, the whole concern is nonsensical and pure > speculation because you only get the RAW data the camera writes > anyway. And the little working with the K10D that I have done so far > indicates pretty clearly that it has exceptionally good image > quality, even compared with the *ist DS which also has very very good > image quality. The K10D has "better" 12 bit RAW data, in other words. > I think that it is in part due to the 22bit A-D and whatever data > massaging they do in that space, at least in part. > That's the point though... even as it is, there are some user-adjustments that likely may affect the RAW file. Setting a different colorspace (sRGB vs. AdobeRGB), or setting a different white-balance will affect the conversion of 22-bit RAW to 12-bit RAW. That flies in the face of the idea that one can, "shoot in RAW and not worry about WB and other color settings." > If you want to continue to speculate for no particular reason, well, > be my guest. > It's not pure speculation. When I first got my -DS, I dove into the color management and white balance stuff. One of the things I did was add a white-balance (warming) filter on the lens and shoot a very cool color temp shot (overcast, evening approaching, etc). Bottom line was that after adjusting the WB in the RAW conversion between the filtered and unfiltered version, there was less noise in the channels that were captured approximating 5500K color temp. Bottom line: It was better to filter out (via the lens filter) the light that would blow out a single channel (like blue on an overcast day or red for a sunset) and then increase the exposure to bring *all* the levels up. Quantifiably less noise in the lower-level channels by doing that. Sometimes being an engineer is a curse... :) -Cory -- * * Cory Papenfuss, Ph.D., PPSEL-IA * * Electrical Engineering* * Virginia Polytechnic Institute and State University * * -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net
Re: Re[2]: Understanding ProPhoto RGB - or not
> If Pentax are using the Nucore NDX-2240 AFE on the front end of their > PRIME Image Processor (which hasn't been denied and was rumored to be > confirmed) the it provides what they deem as a "color sensitive PGA" > prior to the input to the 22 bit ADC. You can read up more here: > > http://www.nucoretech.com/nu3/images/80_downloads/pres_technology.ppt.us.pdf > Pretty impressive stuff going on in there. For the most part, seems to confirm my suspicions that some of the user-settings will likely affect the output RAW file. -Cory -- * * Cory Papenfuss, Ph.D., PPSEL-IA * * Electrical Engineering* * Virginia Polytechnic Institute and State University * * -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net
Re: Re[2]: Understanding ProPhoto RGB - or not
On 14/12/06, Cory Papenfuss <[EMAIL PROTECTED]> wrote: > That flies in the face > of the idea that one can, "shoot in RAW and not worry about WB and other > color settings." The idea that RAW data is unaltered by WB settings etc isn't a rule it was just a convention that was taken for granted when systems weren't as highly developed. The fact is that given the option I would rather that a little pre-precessing of the Bayer information is undertaken if it ultimately provides improved final image quality. -- Rob Studdert HURSTVILLE AUSTRALIA Tel +61-2-9554-4110 UTC(GMT) +10 Hours [EMAIL PROTECTED] http://home.swiftdsl.com.au/~distudio//publications/ Pentax user since 1986, PDMLer since 1998 -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net
Re: Re[2]: Understanding ProPhoto RGB - or not
> On 13/12/06, Cory Papenfuss <[EMAIL PROTECTED]> wrote: >> Now, for example, if one were to apply a cloudy WB vs. a tungsten >> WB, the red channel gain would likely be at least a bit (i.e. f-stop) or >> two different. It makes sense to chose a different "dynamic range" for >> each channel based on things like WB (and by association colorspace). > > Just being pedantic but you allude in the above paragraph that > Colorspace is dependent on "dynamic range" however it's not, > inappropriate choice of WB may cause some colours to clip in certain > circumstances but it doesn't alter the sensors colour response. Just > consider the scenario of a sensor which has acute sensitivity to near > UV and near visible IR but very poor green response. It could feed > into a 4 bit ADC but would still require a very wide colorspace to > adequately describe/contain it's colour response. > Isn't this whole discussion pedantic? :) What I *meant* to say was the the per-channel transfer function from input to output is a function of WB and colorspace. Once the output has to be truncated to 12-bits, those parameters now affect the output dynamic range. -Cory -- * * Cory Papenfuss, Ph.D., PPSEL-IA * * Electrical Engineering* * Virginia Polytechnic Institute and State University * * -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net
Re: Re[2]: Understanding ProPhoto RGB - or not
On 14/12/06, Cory Papenfuss <[EMAIL PROTECTED]> wrote: > Isn't this whole discussion pedantic? :) Quite. > What I *meant* to say was the the per-channel transfer function > from input to output is a function of WB and colorspace. Once the output > has to be truncated to 12-bits, those parameters now affect the output > dynamic range. However if the linear data has been subjected to some non-linear compression (as per modification of the gamma transfer curve around the noise floor and slightly before saturation) then the 12bits could potentially represent the equivalent of 16 bits of linear data :-) -- Rob Studdert HURSTVILLE AUSTRALIA Tel +61-2-9554-4110 UTC(GMT) +10 Hours [EMAIL PROTECTED] http://home.swiftdsl.com.au/~distudio//publications/ Pentax user since 1986, PDMLer since 1998 -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net
Re: Re[2]: Understanding ProPhoto RGB - or not
> Bottom line: It was better to filter out (via the lens filter) > the light that would blow out a single channel (like blue on an > overcast day or red for a sunset) and then increase the exposure to > bring *all* the levels up. Quantifiably less noise in the lower- > level channels by doing that. I knew I'd find a use for all those filters I thought would be obsolete -:) John The information transmitted is intended only for the person to whom it is addressed and may contain confidential and/or privileged material. If you have received an email in error please notify Carmel College on [EMAIL PROTECTED] then delete all copies of it from your systems. Although Carmel College scans incoming and outgoing emails and email attachments for viruses we cannot guarantee a communication to be free of all viruses nor accept any responsibility for viruses. Although Carmel College monitors incoming and outgoing emails for inappropriate content, the college cannot be held responsible for the views or expressions of the author. The views expressed may not necessarily be those of Carmel College and Carmel College cannot be held responsible for any loss or injury resulting from the contents of a message. -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net
Re: Re[2]: Understanding ProPhoto RGB - or not
>> What I *meant* to say was the the per-channel transfer function >> from input to output is a function of WB and colorspace. Once the output >> has to be truncated to 12-bits, those parameters now affect the output >> dynamic range. > > However if the linear data has been subjected to some non-linear > compression (as per modification of the gamma transfer curve around > the noise floor and slightly before saturation) then the 12bits could > potentially represent the equivalent of 16 bits of linear data :-) > ... which would be rather nice. Much better to disperse quantization throughout the (logarithmically-perceived) dynamic range. -Cory -- * * Cory Papenfuss, Ph.D., PPSEL-IA * * Electrical Engineering* * Virginia Polytechnic Institute and State University * * -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net
Re: Re[2]: Understanding ProPhoto RGB - or not
I did the same thing, Cory, and found no practical difference in the results. I've not suffered from excessive noise in any event ... G On Dec 13, 2006, at 5:28 AM, Cory Papenfuss wrote: > It's not pure speculation. When I first got my -DS, I dove into > the color management and white balance stuff. One of the things I > did was > add a white-balance (warming) filter on the lens and shoot a very cool > color temp shot (overcast, evening approaching, etc). Bottom line was > that after adjusting the WB in the RAW conversion between the > filtered and > unfiltered version, there was less noise in the channels that were > captured approximating 5500K color temp. > > Bottom line: It was better to filter out (via the lens filter) > the light that would blow out a single channel (like blue on an > overcast > day or red for a sunset) and then increase the exposure to bring > *all* the > levels up. Quantifiably less noise in the lower-level channels by > doing > that. > > Sometimes being an engineer is a curse... :) -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net
Re: Re[2]: Understanding ProPhoto RGB - or not
> I did the same thing, Cory, and found no practical difference in the > results. > > I've not suffered from excessive noise in any event ... I didn't say practical... I said quantifiable. Revert to previous post about this being a pedantic discussion... :) -- * * Cory Papenfuss, Ph.D., PPSEL-IA * * Electrical Engineering* * Virginia Polytechnic Institute and State University * * -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net
Re: Re[2]: Understanding ProPhoto RGB - or not
On Wed, Dec 13, 2006 at 08:28:30AM -0500, Cory Papenfuss wrote: > > ... *before*. The common thought previously was that RAW provided > unaltered A/D data of the sensor. That may or may not have been true, but > at least it *could* have been. Now with truncation necessary, it *cannot* > be true that a RAW file contains unaltered digitzed sensor data. You seem to believe that putting a 22-bit digital signal processor in the data path somehow affects the need for truncation of the data from the sensor. That isn't true. Either the sensor+ADC combination is capable of delivering more than 12 bits of signal (in which case truncation will be necessary somewhere), or it isn't. -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net
Re: Re[2]: Understanding ProPhoto RGB - or not
>> ... *before*. The common thought previously was that RAW provided >> unaltered A/D data of the sensor. That may or may not have been true, but >> at least it *could* have been. Now with truncation necessary, it *cannot* >> be true that a RAW file contains unaltered digitzed sensor data. > > You seem to believe that putting a 22-bit digital signal processor in the > data path somehow affects the need for truncation of the data from the > sensor. That isn't true. Either the sensor+ADC combination is capable > of delivering more than 12 bits of signal (in which case truncation will > be necessary somewhere), or it isn't. > Of course it doesn't. What it *does* allow for is a different gain for the three different channels for wider dynamic range. That "gain" is a function of settings like colorspace and white balance. -Cory -- * * Cory Papenfuss, Ph.D., PPSEL-IA * * Electrical Engineering* * Virginia Polytechnic Institute and State University * * -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net
Re: Re[2]: Understanding ProPhoto RGB - or not
On Dec 13, 2006, at 9:59 AM, Cory Papenfuss wrote: >>> ... *before*. The common thought previously was that RAW provided >>> unaltered A/D data of the sensor. That may or may not have been >>> true, but >>> at least it *could* have been. Now with truncation necessary, it >>> *cannot* >>> be true that a RAW file contains unaltered digitzed sensor data. >> >> You seem to believe that putting a 22-bit digital signal processor >> in the >> data path somehow affects the need for truncation of the data from >> the >> sensor. That isn't true. Either the sensor+ADC combination is >> capable >> of delivering more than 12 bits of signal (in which case >> truncation will >> be necessary somewhere), or it isn't. >> > Of course it doesn't. What it *does* allow for is a different > gain for the three different channels for wider dynamic range. That > "gain" is a function of settings like colorspace and white balance. Or it might not be anything user adjustable at all. You're making assumptions here. Godfrey -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net
Re: Re[2]: Understanding ProPhoto RGB - or not
>> Of course it doesn't. What it *does* allow for is a different >> gain for the three different channels for wider dynamic range. That >> "gain" is a function of settings like colorspace and white balance. > > Or it might not be anything user adjustable at all. You're making > assumptions here. > So adjusting white balance and camera colorspace isn't user-adjustable anymore? Hrm... -Cory -- * * Cory Papenfuss, Ph.D., PPSEL-IA * * Electrical Engineering* * Virginia Polytechnic Institute and State University * * -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net
Re: Re[2]: Understanding ProPhoto RGB - or not
On Dec 13, 2006, at 12:14 PM, Cory Papenfuss wrote: >>> Of course it doesn't. What it *does* allow for is a different >>> gain for the three different channels for wider dynamic range. That >>> "gain" is a function of settings like colorspace and white balance. >> >> Or it might not be anything user adjustable at all. You're making >> assumptions here. >> > So adjusting white balance and camera colorspace isn't > user-adjustable anymore? Hrm... That's not what I said. The adjustments and tuning provided by the 22bit A-D could be fixed and not affected by user selection of color space or adjustments to white balance, and therefore independent of what gets written in a RAW file. It will take testing to determine exactly what does happen to the RAW file with these adjustments, if anything. And to determine whether it is of practical significance to a photographer or to image quality, not just a "quantifiable" change. The K10D is, after all, supposed to be a camera ... not an exercise in Digital Systems Engineering 101. Godfrey -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net
Re: Re[2]: Understanding ProPhoto RGB - or not
On 12/14/06, Godfrey DiGiorgi <[EMAIL PROTECTED]> wrote: > The K10D is, after all, supposed to be a camera ... not an exercise > in Digital Systems Engineering 101. Mark! Dave -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net
Re: Re[2]: Understanding ProPhoto RGB - or not
> That's not what I said. > > The adjustments and tuning provided by the 22bit A-D could be fixed > and not affected by user selection of color space or adjustments to > white balance, and therefore independent of what gets written in a > RAW file. It will take testing to determine exactly what does happen > to the RAW file with these adjustments, if anything. And to determine > whether it is of practical significance to a photographer or to image > quality, not just a "quantifiable" change. > Yes, it was an inflamatory comment... :) It's pure speculation, but certainly is as plausible as not that WB adjusts the written RAW data. Wasn't there a link to a post here a couple days ago saying the same thing? > The K10D is, after all, supposed to be a camera ... not an exercise > in Digital Systems Engineering 101. > So I should stop using my -DS as a colorimeter to calibrate my CRT monitor? -Cory -- * * Cory Papenfuss, Ph.D., PPSEL-IA * * Electrical Engineering* * Virginia Polytechnic Institute and State University * * -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net
Re: Re[2]: Understanding ProPhoto RGB - or not
On Dec 13, 2006, at 3:26 PM, Cory Papenfuss wrote: > Yes, it was an inflamatory comment... :) It's pure speculation, > but certainly is as plausible as not that WB adjusts the written > RAW data. > Wasn't there a link to a post here a couple days ago saying the same > thing? Some people claim that it does, and perhaps there is a measurable change in RAW values. Significant or practically useful? No. >> The K10D is, after all, supposed to be a camera ... not an exercise >> in Digital Systems Engineering 101. > > So I should stop using my -DS as a colorimeter to calibrate my CRT > monitor? That's up to you. Apples mixed with concrete is not ordinarily considered an after dinner drink either ... G -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net
Re: Re[2]: Understanding ProPhoto RGB - or not
> Some people claim that it does, and perhaps there is a measurable > change in RAW values. Significant or practically useful? No. > Maybe... for some things. For most things, no. >> So I should stop using my -DS as a colorimeter to calibrate my CRT >> monitor? > > That's up to you. Apples mixed with concrete is not ordinarily > considered an after dinner drink either ... > You haven't tried my homebrew beer, either... :-D -Cory -- * * Cory Papenfuss, Ph.D., PPSEL-IA * * Electrical Engineering* * Virginia Polytechnic Institute and State University * * -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net
Re: Re[2]: Understanding ProPhoto RGB - or not
On 14/12/06, Boros Attila <[EMAIL PROTECTED]> wrote: > So there is really no silver bullet, and I should consider choosing a > color space based on what kind of image I'm working with, and what the > final output will be, and working with ProPhotoRGB in 16 bit is just a > safe bet. Then the final step will be to convert to sRGB before saving > for web. Can there be a loss of image detail/color when I perform such > a conversion? This is what I've chosen to do (and so it seems a lot of other colour management aware photographers), if you start with too much you can always scale down but you can never get data back that's lost. The way the detail is transformed depends on the rendering intent applied during the CS conversion process, see my previous reply for a good reference. > Let's say I have an image which fits perfectly into sRGB. > > A.) > - I use ACR to open the image in Photoshop using ProphotoRGB. > - Apply levels, curves, sharpening etc. > - Convert to sRGB then save for web. > > B.) > - I use ACR to ipen the image in Photoshop using sRGB. > - Apply levels, curves, sharpening etc. > - No need to convert, this is already sRGB so just save for web. > > Assuming that in both cases I work in 16 bits/channel mode will there > be any differences between A.) and B.)? With other words, can > colorspace conversions lead to a loss of information? It would seem > that in B.) there is no color space conversion, it's sRGB all the way, > but there is a catch: the article says that ProPhotoRGB is Camera > Raw's native colour space. So if I get this right there will be a > conversion in both cases. ACR offers a choice of several colourspaces the widest of which is ProPhoto RGB and if the device profiles that I've seen for most of the current DSLRs are at all accurate even that doesn't quite accommodate all the colour gamut that these cameras are capable of recording. Colourspace conversion can alter data detrimentally, you have to be aware of the limitations of each colourspace and also how the rendering intent that's chosen will attempt to clip or compress the data that lies outside the new gamut plus there are other factors such as black point compensation. The bottom line is pretty simple though, if you can afford the file space to save 16 bit files and if your machine doesn't grind to a halt when editing 16 bit files you may as well convert and edit in the widest colourspace available. Then you can always convert to sRGB or any other smaller gamut CS for web or print, also reduce the bit depth after CS conversion not before. The following article is probably the best of read on colour managed workflows: COLOUR MANAGEMENT WORKSHOP NOTES 2005 Copyright Les Walkling 2005 Version 2005:6 http://media-arts.rmit.edu.au/Les_Walkling/Colour_Management_Notes.pdf#search=%22Epson%207600%22 -- Rob Studdert HURSTVILLE AUSTRALIA Tel +61-2-9554-4110 UTC(GMT) +10 Hours [EMAIL PROTECTED] http://home.swiftdsl.com.au/~distudio//publications/ Pentax user since 1986, PDMLer since 1998 -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net
