Luminous Landscape Forum
Raw & Post Processing, Printing => Digital Image Processing => Topic started by: Peter_DL on March 20, 2008, 02:13:07 pm
-
IF of interest and maybe for discussion.
I’ve placed this as an ACR feature request:
http://www.adobeforums.com/webx?14@@.3bb6a85c.3bbc8060/357 (http://www.adobeforums.com/webx?14@@.3bb6a85c.3bbc8060/357)
>>
The merits of Raw are well documented and have been broadly discussed. Compared to JPGs from in-camera conversion, Raw data can easily bear up to approx. 1-stop more of dynamic range. Raw processing allows to recover these highlights e.g. via the Exposure slider in ACR. Also, Raw features a better correction and ex post adjustment of White-balance via Temperature and Tint controls.
Further, Raw data can be processed and released into a large gamut such as ProPhoto RGB (pRGB), thus preserving a major part of scene-referred color saturation. Many of such saturated colors are already within the reach of today’s printer; others may require particular attention to avoid posterization.
Image details and sharpening are another aspect. In-camera sharpening is not known to be particularly advanced and therefore prone to amplify noise or to cause artifacts if overdone.
Now referring to JPGs from in-camera conversion, and in consideration of all limitations including tiny sRGB gamut, we have to admit that their “look” can be surprisingly good if not even preferred. Speaking for myself only and some experience with Canon gear, impression is that image rendition and color appearance with JPGs have much improved in the course of technological progress. Same may apply to other brands.
Many user seem to feel the same and often enough a generic Raw converter such as DPP is preferred to access said “look”, even at the cost of workflow speed and convenience vs ACR. It’s sometimes claimed that any of such “look” can be mimicked in ACR, however, I’d like to disagree with this. Even simple in-camera settings such as Contrast or Saturation are apparently following complex and different definitions than commonly known, and also single hues are shifted away from colorimetric accuracy to whatever camera engineers have identified as “pleasing”.
Further, it can be assumed that in-camera conversions feature a perceptual gamut compression, so there’s less channel clipping with saturated colors compared to a straight Raw -> pRGB –(RelCol)–> sRGB pathway.
Coming to the point:
Many of today’s cameras allow to capture Raw + JPG simultaneously.
ACR since version 4.x (iirc) allows to process Raw or JPG.
Wouldn’t it be possible to combine and blend both images at the level of linear-gamma ProPhoto RGB (1.0 pRGB) which ACR was reported to use as an intermediate working space ?
All controls which are applied before or during the conversion Raw -> 1.0 pRGB would still act on this transform only. While the JPG is converted to same 1.0 pRGB at 16 bpc, all controls which are applied after arrival in 1.0 pRGB would act on a blend of both images. This is of course just meant as rough description, hoping that Adobe engineers would get the gist while being much more familiar with ACR mechanics.
Basically I’ve tried what I suggest by doing such blends in Photoshop, then going back to ACR again. Results seem to confirm the idea and intention in principle i.e. to enhance JPGs by insertion of Raw data information, or the other way round, to enhance the ACR processing chain by inserting a touch of “JPG look” as conceived by camera manufacturers.
Finally it should be mentioned that the idea is not really new (see Link and White Paper), but maybe today’s RAW + JPEG combo could offer an up to date implementation with ACR.
http://www.kodak.com/global/en/professiona...erit/erit.jhtml (http://www.kodak.com/global/en/professional/products/cameras/erit/erit.jhtml)
<<
Peter
--
-
While the idea has merit, I can see many problems to overcome, first most cameras have options for setting saturation etc, and conversion would have to take this into account. Another point is cameras vary, one eos 5d will probably be slightly different from the next and so on, all this has to be "designed in" so to speak.
Perhaps the biggest issue is how many people want their RAW to look like their jpeg, I for example ajust all my images before printing (jpeg or raw) so it makes little difference to me if they match. A lot of people only use raw or jpeg, not both anyway, so they probably wouldn't care if they match. Wayne
-
Basically I’ve tried what I suggest by doing such blends in Photoshop, then going back to ACR again. Results seem to confirm the idea and intention in principle i.e. to enhance JPGs by insertion of Raw data information, or the other way round, to enhance the ACR processing chain by inserting a touch of “JPG look” as conceived by camera manufacturers.
I don't understand the point. What should the JPEG image contribute to the result? Whatever that "JPEG look" is, it has been achieved from the same basis, namely from the raw data; the rest is adjustment parameters, which can be achieved by ACR adjustments. Such sets of adjustments can be saved and treated as for example Picture Styles, so that they can be easily applied to other images.
-
I don't understand the point. What should the JPEG image contribute to the result? Whatever that "JPEG look" is, it has been achieved from the same basis, namely from the raw data; the rest is adjustment parameters, which can be achieved by ACR adjustments. Such sets of adjustments can be saved and treated as for example Picture Styles, so that they can be easily applied to other images.
[a href=\"index.php?act=findpost&pid=183045\"][{POST_SNAPBACK}][/a]
In terms of in camera processing, the JPEGs are as you say, getting built from the same Raw data we have in ACR, but the processing is highly proprietary. This is one reason I don't see much use in Raw+JPEG because the two rarely match (or I have to jump though hoops to make the Raw match the JPEG). I find it easier to just render the Raw as I prefer and save out a JPEG. Very fast and efficient in Lightroom.
That said, there has been talk of having a default Raw rendering that could somehow automatically match (closely) the JPEG which I suspect would require we actually shoot said JPEG (not sure). That might be a useful capability, at least as a starting point in the Raw rendering.
-
That said, there has been talk of having a default Raw rendering that could somehow automatically match (closely) the JPEG
There is no "the" JPEG. My camera offers the selection of seven sharpness levels, nine contrast, nine saturation and nine tone variations. All these together constitute a picture style, and all are involved (with the white balance) in the in-camera conversion of the raw in JPEG.
Consequently, one would have to have 5100 images as basis (with the combinations of the the settings) to select from. It would be simpler to record raw + JPEG and use that JPEG as template - but then why recording the raw at all?
I don' see any sense in the original suggestion.
-
There is no "the" JPEG. My camera offers the selection of seven sharpness levels, nine contrast, nine saturation and nine tone variations. All these together constitute a picture style, and all are involved (with the white balance) in the in-camera conversion of the raw in JPEG.
Consequently, one would have to have 5100 images as basis (with the combinations of the the settings) to select from. It would be simpler to record raw + JPEG and use that JPEG as template - but then why recording the raw at all?
[a href=\"index.php?act=findpost&pid=183073\"][{POST_SNAPBACK}][/a]
A picture style is a preset. We have them in say LR or ACR. The idea here would be an auto preset built based upon the color appearance of the JPEG (or some way to shoot a JPEG target, build a preset automatically).
-
A picture style is a preset. We have them in say LR or ACR
Picture Style is a feature of Canon cameras, Nikons too have it under a different name. They are combinations of the settings sharpness, contrast,....
Users are regularly venting their dissatisfaction on the Adobe ACR forum about ACR not being able to automatically reproduce their in-camera settings, the best as complete picture styles. That is, what people miss (those, who regard raw as a last resort in case they blew the shot). It is a joke to believe that the way to achieve that is through reverse-engineering a JPEG image.
The idea here would be an auto preset built based upon the color appearance of the JPEG (or some way to shoot a JPEG target, build a preset automatically
The color is a different issue, but again, it is not the issue of reverse-engineering of a JPEG image. Btw, the new version of ACR (which has been aborted almost sooner than released) is supposed to have new camera profiles. I wonder if this helps on the omnipresent problem of ACR with color rendering.
The barrier of ACR is the DNG specification, preventing ACR from honouring in-camera settings. The new version is accompanied with a new DNG specification, containing at least 13 new tags. The documentation is not published yet. I wonder if Adobe had finally the courage to extent the specification with elements accomodating in-camera settings for governing the raw conversion.
-
I don't understand the point. What should the JPEG image contribute to the result? Whatever that "JPEG look" is, it has been achieved from the same basis, namely from the raw data; the rest is adjustment parameters, which can be achieved by ACR adjustments. Such sets of adjustments can be saved and treated as for example Picture Styles, so that they can be easily applied to other images.
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=183045\")
Picture Style is a feature of Canon cameras, Nikons too have it under a different name. They are combinations of the settings sharpness, contrast,....
Users are regularly venting their dissatisfaction on the Adobe ACR forum about ACR not being able to automatically reproduce their in-camera settings, the best as complete picture styles. That is, what people miss (those, who regard raw as a last resort in case they blew the shot). It is a joke to believe that the way to achieve that is through reverse-engineering a JPEG image.
The color is a different issue, but again, it is not the issue of reverse-engineering of a JPEG image. Btw, the new version of ACR (which has been aborted almost sooner than released) is supposed to have new camera profiles. I wonder if this helps on the omnipresent problem of ACR with color rendering.
The barrier of ACR is the DNG specification, preventing ACR from honouring in-camera settings. The new version is accompanied with a new DNG specification, containing at least 13 new tags. The documentation is not published yet. I wonder if Adobe had finally the courage to extent the specification with elements accomodating in-camera settings for governing the raw conversion.
[a href=\"index.php?act=findpost&pid=183122\"][{POST_SNAPBACK}][/a]
Panopeeper,
Your point that in-camera conversion also starts from the same basis, namely from the raw data, is well understood.
However, with the conversion it’s a matter of different math … and how to bring things together again:
In-camera conversions are, as Andrew says, highly proprietary. Even if all of your settings such as Contrast or Saturation would be communicated to ACR, the question is about the underlying definition:
Is in-camera Contrast the same as the respective slider in ACR? I doubt. As far as I can tell, Canon likes to mix it with something like Clarity. What is the definition i.e. the underlying color model for in-camera Saturation. With ACR it can be shown that the Saturation slider behaves like with the Hue/Sat.-tool but in HSL saturation blend mode and applied on a 1.0 pRGB basis. Now with in-camera Saturation … good luck with reverse-engineering. There are only quite few in-camera controls, however, these can be beasts if you want to dig down to their mechanics.
In addition, many in-camera moves and processing parameter might not be directly accessible. Have a look at this Canon brochure, page 44 (page 2 in the pdf; sorry it’s in German). The chart illustrates how single hues are shifted for a more “accurate” rendition of memory colors; e.g. the deep blue sky etc. A similar approach is described in Kodak patent US 679174. Finally, every picture style might have its own agenda and maybe rendering table to get this accomplished. That said, it’s even unclear (for me), if and to what extent such transforms could already be scene adaptive.
[a href=\"http://www.canon.de/Images/dsc_tcm83-282974.pdf]http://www.canon.de/Images/dsc_tcm83-282974.pdf[/url]
http://www.freepatentsonline.com/6791716.html (http://www.freepatentsonline.com/6791716.html)
Sure, you can resort to ACR’s Calibrate tab in order to obtain a somewhat similar “look”. Eric Chan has described such color matching approach. But with all due respect, tweaking the matrix primaries is a quite coarse method with regard to the intended purpose.
http://people.csail.mit.edu/ericchan/dp/acr-color-match/ (http://people.csail.mit.edu/ericchan/dp/acr-color-match/)
No, working with presets in ACR is certainly a good idea to create a specific look. However, to claim that this approach would be suited to copy the specific look of another converter such as in-camera conversion, which in all probability utilizes different math, is not realistic … imo.
This at least is my experience and was the starting point of the initial proposal.
Perhaps a kind of: don’t fight against or try to copy, just blend it in.
Peter
--
-
The problem of ACR (or any other RAW converter) not being able to match a known Picture Style (or whatever you call it) has nothing to do with limitations of the DNG specification.
Even if you know exactly what the in-camera parameters are (e.g., Picture Style = Faithful, Contrast -1, Saturation +1, Sharpening = -2), that by itself is relatively little information. There are an infinite # of ways to interpret that metadata, but only 1 of those ways will reproduce the vendor look. This is the vendors' secret sauce, and AFAIK they aren't divulging the recipes.
-
The lack of respective tags in the specification excludes the *communication* of such settings. It would be relatively easy to "map" the actions a given raw processor takes in response to such settings, though that would not be an absolute requirement.
I don't think Adobe or any other camera manufacture independent raw processor would try to imitate how all CNX or DPP or other "proprietory" raw processor is sharpening; that's quite nonsense. The point is, that users of a given raw processor are expecting, that their settings will be honoured. This does not need to be identical to DPP or CNX, and if a photographer uses consistently a given raw processor, than this is very normal: the camera setting should correspond to the actions of that raw processor.
This is what lots of photographers are missing in ACR, according to their complaints.
The *color reproduction* is a separate issue. Not only that mimicking another raw processor's color reproduction is more difficult than mimicking sharpness or contrast settings, but IMO mimicking an other reproduction is not the solution. One should be able to choose between many different reproductions.
The thread "ACR 4.4 and Clarity" picked up this subject, with Edmund complaining about the lack of interface for independent profiles. My opinion is, that that is the way to go, although I don't know, if the way Adobe selected is suitable for that. I mean I don't know, if the color conversion governed by matrix operations can fully utilize what a given sensor delivers. I wonder if there is a publically available analysis showing, how much of the gamut of the sensor can be transformed this way in CIE relating to a specific camera
-
The thread "ACR 4.4 and Clarity" picked up this subject, with Edmund complaining about the lack of interface for independent profiles. My opinion is, that that is the way to go, although I don't know, if the way Adobe selected is suitable for that. I mean I don't know, if the color conversion governed by matrix operations can fully utilize what a given sensor delivers. I wonder if there is a publically available analysis showing, how much of the gamut of the sensor can be transformed this way in CIE relating to a specific camera
[a href=\"index.php?act=findpost&pid=184180\"][{POST_SNAPBACK}][/a]
And as yet, no answer from Edmund (or you if you wish) about how this would ensure any desired color rendering nor if Edmund (or you) are unable to produce a desired color rendering without a custom ICC profile.
-
And as yet, no answer from Edmund (or you if you wish) about how this would ensure any desired color rendering nor if Edmund (or you) are unable to produce a desired color rendering without a custom ICC profile.
[a href=\"index.php?act=findpost&pid=184192\"][{POST_SNAPBACK}][/a]
I certainly can't state that this can be done, for I am not sure if the method chosen by Adobe is a viable one at all.
As to achieving the desired result without a custom profile: I am not complaining about the color rendition from my perspective, but I don't dismiss others' concerns with semantic arguments. The opening post of this thread by Peter too reflects the opinion, that the camera profiling capability of ACR is not the right way to solve the issues.
-
The opening post of this thread by Peter too reflects the opinion, that the camera profiling capability of ACR is not the right way to solve the issues.
[a href=\"index.php?act=findpost&pid=184205\"][{POST_SNAPBACK}][/a]
Solve what issues? All goes back to the original and simple question.
-
Solve what issues? All goes back to the original and simple question.
My answer was that the "expected" color reproduction can not always be achieved. I am not prepared to discuss about semantics. You may call it "desired color reproduction"; it is in fact whatever a user wants to achieve.
From the opening post:
Many user seem to feel the same and often enough a generic Raw converter such as DPP is preferred to access said “look”, even at the cost of workflow speed and convenience vs ACR. It’s sometimes claimed that any of such “look” can be mimicked in ACR, however, I’d like to disagree with this
I go a step further, for I don't want to restrict the achievable "looks" to those delivered by the native raw processor of a given camera.
-
My answer was that the "expected" color reproduction can not always be achieved.
Expected as a default or after using the various dials and sliders provided?
Looks are nothing more than a preset of rendering instructions. Every Raw converter I've ever seen can make looks (renderings). The question is, does the rendering provide the color appearance you want? If not is it close? If not is it a mile away and you can get to the look you want?
Getting something from the get go versus never being able to get what you want is a pretty significant difference.
-
The point is, that users of a given raw processor are expecting, that their settings will be honoured. This does not need to be identical to DPP or CNX, and if a photographer uses consistently a given raw processor, than this is very normal: the camera setting should correspond to the actions of that raw processor.
I am not sure what you mean here. When you say "their settings" do you mean things that go in the raw file's maker note such as "Picture Style" and "Contrast" and "Saturation" settings?
If so, if a user selects Picture Style = Standard for a Canon 5D on the camera (using the camera's menus) and another user selects Picture Style = Faithful on his, how should a non-Canon raw converter interpret raw files from these two different cameras? How should this "Picture Style" setting be honored?
Also, the camera vendors' image quality settings aren't standardized (how do Canon Picture Styles translate to Nikon Color Modes? they don't). Wouldn't it make more sense (and be easier) to just create a preferred style using the settings of the raw converter and save it as a preset for your camera? For example, if you prefer to have less contrast on your camera, couldn't you reduce the contrast in the raw converter and save that as the default for your camera?
-
The problem of ACR (or any other RAW converter) not being able to match a known Picture Style (or whatever you call it) has nothing to do with limitations of the DNG specification.
Even if you know exactly what the in-camera parameters are (e.g., Picture Style = Faithful, Contrast -1, Saturation +1, Sharpening = -2), that by itself is relatively little information. There are an infinite # of ways to interpret that metadata, but only 1 of those ways will reproduce the vendor look. This is the vendors' secret sauce, and AFAIK they aren't divulging the recipes. [{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=183986\")
Thanks for confirmation on this part.
... Wouldn't it make more sense (and be easier) to just create a preferred style using the settings of the raw converter and save it as a preset for your camera? For example, if you prefer to have less contrast on your camera, couldn't you reduce the contrast in the raw converter and save that as the default for your camera? [a href=\"index.php?act=findpost&pid=184281\"][{POST_SNAPBACK}][/a]
Contrast is certainly an interesting example, because: what’s the definition of “Contrast” ?
With ACR, the Contrast slider was reported to apply an S-curve around the midpoint set by Brightness (applied on 1.0 pRGB basis). Thinking about the slope of such curve, this inevitably makes Brightness part of the definition of Contrast and vice versa. Also, Blacks and Exposure could be moved inwards to increase Contrast like with the legacy definition of Contrast as with the Brightness/Contrast tool in earlier PS versions. Further, contrast can be altered via the Curve tab which might be based on a different color model and RGB separation, thus, introducing a different look. And finally we have [a href=\"http://luminous-landscape.com/forum/index.php?showtopic=24097]Clarity[/url] to facilitate a perceived contrast i.e. midtone contrast via a totally different approach.
So what’s Canon’s definition for Contrast: something different or maybe a bit of everything from above? Can’t answer; but a 1:1 match in ACR (if it makes sense at all to bother with such single parameter) might be quite hard to achieve.
Anyway, it seems we are going a bit in circles.
So will try to reconcile:
--
-
... to continue:
My answer was that the "expected" color reproduction can not always be achieved. I am not prepared to discuss about semantics. You may call it "desired color reproduction"; it is in fact whatever a user wants to achieve. From the opening post: Many user seem to feel the same and often enough a generic Raw converter such as DPP is preferred to access said “look”, even at the cost of workflow speed and convenience vs ACR. It’s sometimes claimed that any of such “look” can be mimicked in ACR, however, I’d like to disagree with this [{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=184214\")
Expected as a default or after using the various dials and sliders provided? [a href=\"index.php?act=findpost&pid=184216\"][{POST_SNAPBACK}][/a]
Following comment, btw by Jeff Schewe, is from in an [a href=\"http://luminous-landscape.com/forum/index.php?showtopic=17588&st=8]earlier discussion[/url]: “Camera Raw supports (I think) over 130 cameras at present (over 10 camera makers-and a few that are no longer supported by the companies)...DPP supports only their Canon cameras.
So, at "default" which do you suppose will have better defaults?”...
First question: what are the reasons why a generic Raw converter such as DPP is (accordingly) often perceived to offer a better “default“ - in some aspects at least? Is it just because DPP honors the in-camera settings, or, does Canon somehow know their cameras better than anyone else, or, did they invest more man-years in the development of their proprietary recipe for a pleasing rendition, maybe a color appearance model or whatever? Perhaps impossible to answer here, so let’s ignore the question for the moment.
Second question: can the DPP conversion be precisely copied by means of given ACR controls? I doubt. And we seem to agree on this. Maybe somewhat close with reference to single aspects such as Contrast due to the variety of options in ACR, but all in all and particularly when it comes to Color - I’m quite sure that some very color-range-selective shifts in ACR would be needed; in 3D so to speak.
Third question: can ACR achieve and equal or more pleasing reproduction by utilizing the various dials and sliders provided? Maybe - depending on image and user skills. So perhaps I should leave it to more dedicated people to answer this, however, the burden seems to be on the user to do all settings necessary to accomplish this. OK, some folks may call it fun. Anyway. Another problem is “visual adaptation”. Within the closed sphere of one Raw converter, I tend to like “everything” I do. But then, cross-comparison with the results from another sphere i.e. Raw converter (and including in-camera conversion) is not so clear across different aspects.
Fourth question (and perhaps the key one): would it be easier to start with the DPP default "look", or at least some aspects thereof, whether from DPP itself or from in-camera conversion, but then having all the Raw rendering controls offered with ACR? Clear YES from my side, even though it imposes a mechanistic contradiction which I wanted to address with initial proposal.
Or:
... there has been talk of having a default Raw rendering that could somehow automatically match (closely) the JPEG which I suspect would require we actually shoot said JPEG (not sure). That might be a useful capability, at least as a starting point in the Raw rendering. [a href=\"index.php?act=findpost&pid=183069\"][{POST_SNAPBACK}][/a]
Peter
--
-
Contrast is certainly an interesting example, because: what’s the definition of “Contrast” ?
[snip]
So what’s Canon’s definition for Contrast: something different or maybe a bit of everything from above? Can’t answer; but a 1:1 match in ACR (if it makes sense at all to bother with such single parameter) might be quite hard to achieve.
As you point out, there isn't a single definition of contrast. Intuitively all the reasonable definitions out there obey certain properties, such as that increasing "contrast" will make dark tones darker and light tones lighter. But there are an infinite number of ways to implement that.
Just to point out a common example, editing contrast in a photograph in a standard image editing application such as Photoshop usually means editing contrast in a gamma-encoded space (e.g., sRGB, Adobe RGB, or ProPhoto RGB). However, contrast editing in a raw converter may be implemented in a very different color space (with consequently different results). To add to the confusion, some raw converters allow editing contrast twice.
For example, in Canon's DPP you can apply a contrast curve which operates in camera coordinates (i.e., before colorimetric interpretation of those camera coordinates). That's in the RAW tab. You can then go to the RGB tab and also edit contrast, but this contrast curve is applied using whatever working space you have chosen (e.g., Adobe RGB or Wide Gamut RGB). And neither of these contrast curves have any direct correspondence to how Camera Raw's contrast curves work!
I am getting into technicalities here, but the main point is that a piece of camera metadata that says "Contrast +1" is meaningless in the same way that an 8-bit RGB value of (80, 100, 70) is meaningless. Without knowing the actual RGB color space (e.g., Adobe RGB), the latter gives us no colorimetric context. We can reasonably assume that (80, 100, 70) will likely be brighter than, say, (70, 90, 60), of course, in the same way that we can assume that Contrast +1 implies more contrast than Contrast -1.
-
First question: what are the reasons why a generic Raw converter such as DPP is (accordingly) often perceived to offer a better “default“ - in some aspects at least? Is it just because DPP honors the in-camera settings, or, does Canon somehow know their cameras better than anyone else, or, did they invest more man-years in the development of their proprietary recipe for a pleasing rendition, maybe a color appearance model or whatever? Perhaps impossible to answer here, so let’s ignore the question for the moment.
I don't think this is impossible to answer. As you are aware, there are many aspects of raw conversion image quality. One of them that is often discussed between ACR and Canon's DPP is color, and it is often suggested that Canon -- being the maker of the sensors of their DSLRs and of their cameras -- ought to have more info than anybody else on the spectral response of their color filters, the behaviors of their chips, etc. and therefore be able to produce more accurate color than anybody else.
Ironically, it's fairly easy to convince oneself that their out-of-the-box color isn't any more accurate than, say, Camera Raw's color. (It is actually less accurate from a colorimetric standpoint.) But some prefer DPP's default color because it has more pop and appears more 'pleasing' to the eye. My experience has been that most users do not want accurate color, despite making that claim. In fact, Canon's Picture Styles (with the exception of Faithful) do various color distortions which are clearly carefully designed to produce pleasing color, rather than accurate color (from a colorimetric standpoint).
Second question: can the DPP conversion be precisely copied by means of given ACR controls? I doubt. And we seem to agree on this.
Not in general. In some cases it can be done on an image-by-image basis, but it is not possible to create a single preset that will, say, mimic the "Portrait" Picture Style across all images.
Maybe somewhat close with reference to single aspects such as Contrast due to the variety of options in ACR
The tone curve is pretty easy to match. Color is a different story.
, but all in all and particularly when it comes to Color - I’m quite sure that some very color-range-selective shifts in ACR would be needed; in 3D so to speak.
Agreed.
Third question: can ACR achieve and equal or more pleasing reproduction by utilizing the various dials and sliders provided?
I certainly believe this to be the case.
However, there's certainly an argument in favor of getting better starting points to help users improve their workflow. .
Fourth question (and perhaps the key one): would it be easier to start with the DPP default "look", or at least some aspects thereof, whether from DPP itself or from in-camera conversion, but then having all the Raw rendering controls offered with ACR? Clear YES from my side, even though it imposes a mechanistic contradiction which I wanted to address with initial proposal.
I don't know about 'easier'. I guess it would depend on how easy that 'look' information is to access. The problem if you just treat DPP as a black box and grab the final image as a starting point is that, well, you're no longer starting from a raw file! You're editing beginning with an output-referred image in which case some of the raw benefits would be lost.
-
Many thanks for explanations and for your comments.
Largely agreed and/or accepted so that it would be redundant to quote everything.
... However, there's certainly an argument in favor of getting better starting points to help users improve their workflow. .
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=184611\")
Yep.
I don't know about 'easier'. I guess it would depend on how easy that 'look' information is to access. The problem if you just treat DPP as a black box and grab the final image as a starting point is that, well, you're no longer starting from a raw file! You're editing beginning with an output-referred image in which case some of the raw benefits would be lost.
[a href=\"index.php?act=findpost&pid=184611\"][{POST_SNAPBACK}][/a]
Without intending to insist, the initial idea was as follows:
Referring to Camera Raw and the processing stage of linear-gamma ProPhotoRGB (1.0 pRGB) which ACR was reported to use as an intermediate working space, there should be access to scene-referred image data, freshly derived from “native” Raw by basic operations such as demosaicing and conversion to this 1.0 pRGB. It is after Scene Reconstruction and before Creative Processing, to lend these terms from Simon Tindemans’ essay [a href=\"http://21stcenturyshoebox.com/essays/scenereferredworkflow.html]here[/url].
Blending of such a scene-referred image (in 1.0 pRGB) with an already processed “JPEG” from one single shot (and brought into same 1.0 pRGB and at high bit depth) could be seen as a creative tool and part of Creative Processing on the way to an output-referred i.e. preferred rendition. Nothing mandatory just an option.
There are for sure pros and cons with this approach. FWIW, the main advantage I see is to let the specific “look” e.g. from a Canon Picture Style shine through, without a variety of adjustments needed - at least for a start. And while keeping key Raw advantages such as highlight details. The term “shine through” could refer to a normal RGB blend at reduced but tunable Opacity, or, maybe there are better ways e.g. via HSL blend modes.
Another possible advantage concerns very saturated colors. While the pRGB pathway is certainly suited to preserve a major part of scene-referred color saturation, many of them still can not be printed, so that the user often has to go through a second round of editing in order to get such oog colors towards or inside the designated output gamut while keeping the appearance as far as possible. Purists will of course appreciate the flexibility with this approach, but it might not be everyone’s case.
Whereas camera manufacturers’ seem to have their own proprietary ways to compress saturated colors into tiny sRGB while preserving “vividness” and image details, again, as far as possible. At least, for me their recipe doesn’t look like a straight RelCol pathway which tends to produce more channel clipping and posterization.
By means of said Raw + JPG blend in 1.0 pRGB as described above, absolute color saturation would be “buffered”, so that the de facto gamut as occupied by the image can already be closer to the designated output gamut (in an global sense).
To raise a last aspect; aside from suggested “Raw + JPEG” amalgamation, requested capability to blend images in ACR at the level of 1.0 pRGB could also be particularly useful e.g. for HDR imaging from “Raw + Raw” by doing it “properly” in a linear-gamma space and before Creative Processing.
Makes sense, or perhaps not enough?
Let’s see …
Peter
--
-
Referring to Camera Raw and the processing stage of linear-gamma ProPhotoRGB (1.0 pRGB) which ACR was reported to use as an intermediate working space, there should be access to scene-referred image data, freshly derived from “native” Raw by basic operations such as demosaicing and conversion to this 1.0 pRGB. It is after Scene Reconstruction and before Creative Processing, to lend these terms from Simon Tindemans’ essay here (http://21stcenturyshoebox.com/essays/scenereferredworkflow.html).
I'm not positive, I'd love to hear from Schewe or Thomas Knoll/Mark Hamburg if indeed these setting really are providing scene referred rendering. I once asked Mark and the answer wasn't all that clear:
At what point things shift from scene referred to output referred is more or
less in the eye of the beholder. After all, if you set everything flat all
the way through, then there isn't really a transition point.
I can see the need for some, few users who might want scene referred data out of a converter. I'm not sure where they will now end up with output referred (Photoshop one presumes) or why they would do the toning there instead of LR/ACR. I don't find the toolset there "better", its certainly slower going. And its not anywhere as non destructive unless you go way out of your way with lots of adjustment layers. Seems like an interesting exercise but not something I'd do other than just an exercise.
-
I'm not positive, I'd love to hear from Schewe or Thomas Knoll/Mark Hamburg if indeed these setting really are providing scene referred rendering. I once asked Mark and the answer wasn't all that clear: At what point things shift from scene referred to output referred is more or less in the eye of the beholder. After all, if you set everything flat all the way through, then there isn't really a transition point. [a href=\"index.php?act=findpost&pid=184750\"][{POST_SNAPBACK}][/a]
Andrew, - you and Mark Hamburg are of course right: there’s no clear distinction. As I understand, white balance would be a good example for such a “hybrid” between accurate scene-referred and pleasing. However, there’s perhaps an easy way to make a clear distinction, arguable though:
All ACR controls which are applied before or during the conversion Raw -> 1.0 pRGB would count for “Scene Reconstruction” to achieve still somewhat scene-referred image data. All ACR controls which are applied after arrival in 1.0 pRGB would count for “Creative Processing” to be applied on such scene-referred image data.
I can see the need for some, few users who might want scene referred data out of a converter. I'm not sure where they will now end up with output referred (Photoshop one presumes) or why they would do the toning there instead of LR/ACR. I don't find the toolset there "better", its certainly slower going. And its not anywhere as non destructive unless you go way out of your way with lots of adjustment layers. Seems like an interesting exercise but not something I'd do other than just an exercise.
[a href=\"index.php?act=findpost&pid=184750\"][{POST_SNAPBACK}][/a]
My initial post was/is meant as an ACR feature request, and (as a non-native speaker) I would have hoped that at least the mechanistic description was sufficiently clear, however, I’m sorry for any possible confusion from terminology.
The extraction of such "scene-referred image data" (see I'm putting it in quotation marks now) from ACR was of course an helpful exercise to simulate the feature request. It was not a blind flight.
Peter
--
-
I'm not positive, I'd love to hear from Schewe or Thomas Knoll/Mark Hamburg if indeed these setting really are providing scene referred rendering. I once asked Mark and the answer wasn't all that clear:
You can effectively get linear output from ACR by setting Brightness = 0, Contrast = 0, Blacks to zero, and set the Point Curve to Linear. Of course make sure there aren't any other settings applied such as sharpening, noise reduction, parametric curves, HSL tuning, etc.
If you save the output as ProPhoto, the numerical values will of course be gamma-encoded using ProPhoto's gamma of 1.8. So take the resulting numbers (e.g., using a color picker in PS) and compute x ^ 1.8 to return them to ProPhoto linear, and there you have it.
There is not a way from ACR to disable the camera profiles. (Obviously in normal use you'd never want to disable them!) What you can accomplish using the steps described above is get the demosaiced data that is white-balanced and converted to ProPhoto linear, nothing else. (That's not strictly true, but it's mostly true.)
Anyone wishing to learn more about the process is welcome to examine the DNG spec (and for software developers, examine the DNG SDK). As I recall, dng_validate in the DNG SDK can dump the raw data in various stages, including before the camera profile is applied.
-
I would add that IMO the most significant edit that distinguishes between scene-referred and output-referred data is the tone curve. Without the tone curve we are seeing linear data which mirrors the sensor's response (in terms of relative energy, not color), which is not at all how human vision works.
Color geeks are aware that L* in CIE L*a*b* is more perceptually uniform and know that relationship between L* and Y (in XYZ) is highly non-linear.
-
You can effectively get linear output from ACR by setting Brightness = 0, Contrast = 0, Blacks to zero, and set the Point Curve to Linear. Of course make sure there aren't any other settings applied such as sharpening, noise reduction, parametric curves, HSL tuning, etc.
OK assuming we agree this is scene referred, why? What do you do with it now? And why not use the controls to get output referred?
There is not a way from ACR to disable the camera profiles
Since the two profiles are used to set a white balance, it seems here alone we're getting some kind of output referred alteration if that's the correct term to use. IOW, even using the defaults, isn't some WB handling happening by virtue of these two profiles you can't 'turn off'?
-
OK assuming we agree this is scene referred, why? What do you do with it now? And why not use the controls to get output referred?
Oh, I'm not suggesting that this linear output I described earlier is useful for anything. I was just describing the steps required to produce that output, if for some reason somebody wanted to see it (e.g., out of curiosity).
Certainly to get a pleasing visual result you would want to use controls typically found in RAW converters (such as the tone curve).
Since the two profiles are used to set a white balance, it seems here alone we're getting some kind of output referred alteration if that's the correct term to use. IOW, even using the defaults, isn't some WB handling happening by virtue of these two profiles you can't 'turn off'?
[a href=\"index.php?act=findpost&pid=184799\"][{POST_SNAPBACK}][/a]
Yes, but I would argue it's still scene-referred colorimetry because each RGB coordinate still has a linear relationship to the non-white-balanced camera coordinates. In other words, the interpolated camera -> XYZ matrix is providing a scene-referred colorimetric interpretation of what those captured camera RGB values mean.
If we were to examine the data before the cam -> XYZ matrices are applied, then we'd certainly be seeing the data in a more "raw" state (less processed) but it wouldn't be very meaningful because there wouldn't be any colorimetry involved. Sort of like examining a printer profile target which is just untagged RGB.
-
Oh, I'm not suggesting that this linear output I described earlier is useful for anything. I was just describing the steps required to produce that output, if for some reason somebody wanted to see it (e.g., out of curiosity).
Certainly to get a pleasing visual result you would want to use controls typically found in RAW converters (such as the tone curve).
Yes, but I would argue it's still scene-referred colorimetry because each RGB coordinate still has a linear relationship to the non-white-balanced camera coordinates. In other words, the interpolated camera -> XYZ matrix is providing a scene-referred colorimetric interpretation of what those captured camera RGB values mean.
OK, all sounds good, thanks. There was a link to an article discussing some "benefits" of setting ACR/LR for scene referred output but the arguments for doing so seemed less than useful to me. I was wondering if I was missing something.
-
No, I think we're on the same page.
Following the "produce linear output" steps I described above is a nice exercise for the reader in understanding why scene-referred rendering looks nasty and unattractive. It also shows how critical the tone curve is to crafting the image so that its values have relationships that are more in line with how our visual system works.
I am puzzled by why some users would think that getting linear output from ACR or any raw converter would be a better starting point for further edits. That's totally bizarre to me. The only reason I can see for that is if (1) you're doing scientific work and need the linear output for some purpose or (2) you're not happy with the raw converter's built-in set of editing tools.
But for example, if you get linear output out of ACR and bring it into PS, then yes you can implement your own white balance by using, say, the Curves tool to set different clipping points for each of the R, G, and B values. But there's no technical advantage of doing so compared to doing it in the raw converter in the first place (and arguably a disadvantage since placing curve points inside PS is not as precise as using the click-WB tool inside ACR).
Similarly, one can "turn off" the tone curve in ACR and bring the linear output into PS and apply the tone curve instead in PS. But again there's not a technical advantage of doing this. It just takes more work! The only reason I could see for doing this is if you're not happy with ACR's tone curve controls. Given that ACR's tone curve implementation takes some steps to minimize hue shifts compared to PS's RGB curves tool (by default), I would say that for the vast majority of cases it's preferable to shape the tones in ACR ...
Eric