Luminous Landscape Forum
Raw & Post Processing, Printing => Colour Management => Topic started by: samueljohnchia on February 20, 2013, 11:20:35 am
-
This is a continuation of the discussion from Hening's Shooting Color Targets thread (http://www.luminous-landscape.com/forum/index.php?topic=75161.msg602573), as it digressed into different approaches to camera profiling. I would first like to say that I don't think that there is anything out rightly wrong with DNG/ICC profiles or one method of working compared with another. Each will have its own limitations, and it would be unfair to demand performance outside these limitations. It is surprising that until now nobody has done any comparative testing on various approaches to camera profiling and subsequent raw processing for color.
It would probably be necessary to unravel how DNG/ICC profiles are made, and how raw converters utilize these profiles and make the necessary decisions to transform or extrapolate color. Some portion of that would likely be propriety and would require reverse engineering or inside knowledge, for us to be able to comment better on each approach without being uncertain about where any fault may lie.
I shall begin a list of interesting areas for potential testing:
DNG Profiles
ColorChecker + Adobe DNG Profile Editor
ColorChecker + X-rite ColorChecker Passport Software
QPcard 203 + QPcalibration
(Datacolor's solution is absolute bosh, let's avoid that please.)
ICC Profiles
ColorChecker + ArgyllCMS
ColorChecker SG + ArgyllCMS
QPcard 203 + ArgyllCMS
QPcard 203 + QPcalibration (with additional ICC plugin)
Raw Convertors
Irident Developer
Raw Therapee
Possibly just ACR/Lightroom to compare DNG profiles and "neutral state" rendering of the 800 pound gorilla
Capture One? Lots of folks claim that they get "better color"
Let's add to this list, and also discuss how we are going to design the testing for all of it.
-
Adobe does not make its own camera profiles using those targets and Adobe PE... "Cura te ipsum" (c)
-
Adobe does not make its own camera profiles using those targets and Adobe PE... "Cura te ipsum" (c)
Could you enlighten us on how Adobe makes their profiles?
-
Could you enlighten us on how Adobe makes their profiles?
Actually, Eric Chan and Thomas Knoll make the DNG profiles using some slightly more exotic hardware and software. Exactly how they do that and what they use has not been disclosed...you would have to ask them.
-
While it would be fascinating to hear how Adobe builds their profiles, for these tests it hardly matters since the rest of us can't do so. It is still interesting to compare a user created profile with the tools outlined here to the canned profiles.
(Datacolor's solution is absolute bosh, let's avoid that please.)
Indeed!
-
This is all very close to my work so I'll be following this thread. I profile for art reproduction. Even though I don't have the technical background to contribute at a high level I'll share my experiences of what has produced good results for me.
Adding a few items to the lists:
Raw converters
DXO Optics Pro. DXO can produce either linear or gamma corrected ("realistic color rendering") output files specifically intended for camera profiling. I've gotten very good results with profiles built from the linear output.
PhotoNinja. Has built in profiling for 'camera sensor' and 'light source'. Never tested it, know nothing about it.
ICC profiles:
HCT + ArgyllCMS
notes:
RAWTherapee does support both DNG and ICC profiles and has options to blend the two.
CoCa is a nice camera profiling GUI for ArgyllCMS. Lots of options, easy to use, can use wide variety of targets.
-
This is all very close to my work so I'll be following this thread. I profile for art reproduction. Even though I don't have the technical background to contribute at a high level I'll share my experiences of what has produced good results for me.
Thank you for your contribution Stephen. This is wonderful as you already have a setup for making reproductions and can therefore test for a studio environment, especially one that is setup for reproduction work (you must have been more critical about your lighting). I am a natural light photographer and own no studio lighting, so I can only test for daylight.
Do you happen to have a ColorChecker SG besides your HCT chart?
-
Happy to join in - helps me refine what I'm doing.
I don't have a Colorchecker SG, just the HCT 5x7 reflective, CC24 mini and a QP203. Wish I did have a CCSG as the scanner profile I've built from it (I rented one) is superb.
My lights are not wonderful, but they do the job. I've got two banks of three halogen spots that I move around on lightstands. Hoping to get some SoLux bulbs soon, but getting them here is expensive. I eliminate all other light in the room, however, and flat-field with Equalight before profiling.
-
Could you enlighten us on how Adobe makes their profiles?
http://en.wikipedia.org/wiki/Monochromator in 5nm/10nm increments across the spectrum
as for software they did not tell you, but if you research postings from Eric Chan (try http://forums.adobe.com/community/cameraraw ) you will see that he specifically referencing that Adobe PE can't build profiles that Adobe builds to bundle along w/ ACR/LR
and when somebody comes out swinging that he can do better for a regular light than standard profile I can suggest to leave in both profiles only matrices, remove LUTs (down w/ twists!), put linear tone curve (everything can be done w/ Sandy Mc dcptool and simple text editor) and think again which one is actually better... in most regular light cases you just need a proper WB instead of placebo in the form of $100 consumer level unmeasured target where in most cases you can't even illuminate it precisely in the field...
-
DXO Optics Pro. DXO can produce either linear or gamma corrected ("realistic color rendering") output files specifically intended for camera profiling.
"realistic color rendering"? You mean your linear gamma images look very dark and flat? That's because there is no correct profile assigned to that data. IOW, if you have a profile to define linear gamma data, it looks just like gamma corrected images.
-
and when somebody comes out swinging that he can do better for a regular light than standard profile I can suggest to leave in both profiles only matrices, remove LUTs (down w/ twists!), put linear tone curve (everything can be done w/ Sandy Mc dcptool and simple text editor) and think again which one is actually better... in most regular light cases you just need a proper WB instead of placebo in the form of $100 consumer level unmeasured target where in most cases you can't even illuminate it precisely in the field...
Unfortunately for me and my camera that I use that is not the case. Yes, I also tried untwisting profiles too. Andrew has also commented elsewhere in this forum that he has produced custom camera profiles that were better than the generic Adobe profiles.
Interestingly Ernst commented in my thread on QP that he would go with the camera manufacturer's "estimations of sensor responses". ColorPerfect is also based on a similar philosophy, in the sense that common folk like me cannot possibly render color better with these so-called profiling tools. ColorPerfect takes it further and claims that a gray balancing alone is sufficient - and avoids ICC and DNG profilles entirely, claiming they are a farce and destroy color integrity.
This is why we need testing. I want to see the proof in all this. Who is right? Is what I am seeing all an illusion?
-
Andrew has also commented elsewhere in this forum that he has produced custom camera profiles that were better than the generic Adobe profiles.
I'm not the only one. I've yet to see a custom DNG Profile that I didn't prefer over the generic profile. I don't think this has much to do with the different techniques we and Adobe use. IF, at least in my case, Canon's sensors were really consistent and behaved like the Canon sample Adobe used to build their profiles, their canned profile might very well be better than my DNG profile. I suspect it's why Adobe has provided us the tools to make our own DNG profiles.
You can have the most expensive Spectrophotometer, use the largest patch sample and best profile software to build a printer profile. If that ends up as a canned profile for another printer, it can work really well or less well then building a custom profile on your specific printer with a lesser quality Spectrophotometer or number of patches.
What Adobe uses to build canned DNG profiles would be interesting but not pertinent to his discussion which is looking at the differences in making custom profiles, DNG or ICC based.
-
Interesting to note, the dcp profiles by Adobe and the custom profile with the DNG PE - both have two camera and forward matrices. The matrix values are identical, at least for my camera model.
Adobe profile HueSatDelta LUT has 36 hueDivisions, 8 satDivisions and 16 valDivisions.
DNG PE custom profile has 90 hueDivisions, 25 satDivisions and 1 valDivisions.
Wondering what additional capability does more hueDivisions and satDivisions have, and what is lost with less valDivisions. Eric mentioned (http://forums.adobe.com/message/4706036#4706036)that the DNG PE cannot make lightness corrections at the moment.
-
Andrew has also commented elsewhere in this forum that he has produced custom camera profiles that were better than the generic Adobe profiles.
he then can illustrate w/ a set of dEs otherwise it is his taste and taste is subjective, that's it (= placebo)
-
Interesting to note, the dcp profiles by Adobe and the custom profile with the DNG PE - both have two camera and forward matrices. The matrix values are identical, at least for my camera model.
that is because you use Adobe PE to tune the base (standard profile), that's it... speaking about placebos.
-
he then can illustrate w/ a set of dEs otherwise it is his taste and taste is subjective, that's it (= placebo)
It's totally subjective! What dE values would I be comparing and how useful would the lower one be if I didn't like the color?
-
Adobe profile HueSatDelta LUT has 36 hueDivisions, 8 satDivisions and 16 valDivisions.
DNG PE custom profile has 90 hueDivisions, 25 satDivisions and 1 valDivisions.
they call it 2.5D vs 3D profiles
-
It's totally subjective!
that is exactly the point - you can't argue w/ anything subjective... as soon as it is a matter of taste please by all means consider your profile better.
-
he then can illustrate w/ a set of dEs otherwise it is his taste and taste is subjective, that's it (= placebo)
I am sure he can. But a couple of color patches ain't going to cut it for you and maybe me and others too. What about difficult to reproduce colors? I'm not sure if we can spectral measure scene colors for our testing too.
A short take by Eric on optimizing the color rending of profiles: http://www.luminous-landscape.com/forum/index.php?topic=59688.msg482292#msg482292 (http://www.luminous-landscape.com/forum/index.php?topic=59688.msg482292#msg482292)
-
that is exactly the point - you can't argue w/ anything subjective... as soon as it is a matter of taste please by all means consider your profile better.
Yes, as we find in a huge part of photography and image creation. I don't think the audience here has much interest in scientific capture of data, they (and I) want to make pleasing images. IF we gather a group to test a single raw converter that can utilize a DNG and ICC camera profile, their preferences will be subjective. Unless one or the other process produces what the image creator feels is an awful image (which I have seen with ICC camera profiles). Splitting hairs with dE values don’t belong here.
-
how useful would the lower one be if I didn't like the color?
not useful indeed... that is the point - for as long as the words "I built a better profile" means "I built some profile that I subjectively like more than Adobe's" there is nothing to argue about... I am not arguing about tastes, but I suspect that OP has something else in mind and if so - let him come up w/ the procedure to test that will yield some dEs vs something instead of tastes and opinions
-
I am sure he can
he just wrote that it was subjective, sorry
-
Wondering what additional capability does more hueDivisions and satDivisions have, and what is lost with less valDivisions. Eric mentioned (http://forums.adobe.com/message/4706036#4706036)that the DNG PE cannot make lightness corrections at the moment.
the best capability is actually the ability of ACR/LR to work with just matrix profiles... + linear tone curve +baseline exposure = 0... and I trust Adobe to come w/ good matrices... the rest I can do to my taste (using WB target if necessary) w/o shooting any color targets (only may be as an exercise sometimes for a very very odd light... but I had recently for a colored w/ magenta gel light and even there I ended up, thanks to Eric C. for reminding about RTFM :) and how it is done for IR modified cameras, just adjusting WB range for a standard profile /with LUTs removed/ using Adobe PE - ended w/ absolutely no need to use any color targets).
-
Look, I have no ulterior motive in all this. I am just another natural light photographer chasing elusive perfection. If we realize that in all this camera profiling is a complete farce, I will be happy to swallow that. Right now I am honestly a bit confused as to how we are going to approach this testing. While I would very much like to know how all this works under the hood (yeah right, as if anyone is going to tell), my eyes are telling me the opposite at the moment. And for florescent lights the Adobe Standard profile seriously sucks.
Andrew, I am sure that with reference values from various color targets, we can evaluate the accuracy of the profiles by comparing with rendered values of photographed targets? But scene colors that are not on a target are going to be harder :(
-
And for florescent lights the Adobe Standard profile seriously sucks.
How about a custom DNG profile, does it suck?
If no, that alone is telling in terms of the possible testing.
Now, if you had a converter that allowed DNG and ICC profiles, which would you find better (easier, faster)?
-
How about a custom DNG profile, does it suck?
I set up a simple scene of various red-orange objects at my computer desk. I made a custom DNG profile under the same illumination. The custom DNG profile was shockingly close to the real deal. It was a simple matter of adjusting the WB sliders by eye to get a close match.
The standard untwisted profile was very difficult to adjust to the real scene. I could not get a close match.
Now, if you had a converter that allowed DNG and ICC profiles, which would you find better (easier, faster)?
Good question. I will try to make an ICC profile with a CC and run in Raw Therapee. At present, with DNG profiles, RawTherapee does not seem to be able to utilise dual illuminant tables. I am also not sure of how it utilizes the huesatDelta tables. I say this because I can get RT to practically the exact same colors as ACR, except with a slight warm tint to the colors. Note that the neutrals are not warm tinted, only the colors.
-
This is another excellent post from Eric on optimizing color transforms in camera profiles: http://www.luminous-landscape.com/forum/index.php?topic=37682.msg326214#msg326214 (http://www.luminous-landscape.com/forum/index.php?topic=37682.msg326214#msg326214)
I am now highly doubtful of an approach to compare photographed chart colors to reference synthetic targets as a sole factor to evaluating camera profiles. This is very complicated color science here, and I don't understand it yet.
-
I'ld say if you want to test each profiling method for objective accuracy, pick colors that push the gamut capturing capability of the sensor itself as a way to rule this out when certain colors don't reproduce as intended.
Go to any office supply or Walmart and purchase this...
http://i.walmartimages.com/i/p/00/03/65/00/10/0003650010163_500X500.jpg
...take a shot of it and try to reproduce this vibrant aqua under any given light, using any profiling package or methodology even tweaking the color tables if necessary. If you don't get a spot on reproduction, use your profiling hardware to measure this aqua and plot its gamut. Compare this to DxO's gamut measurements of your camera model. If it shows it fits inside it then you have to question DxO's findings and methodology.
I have that Georgia Pacific package and I pretty much got the results shown in the link lighting it under fluorescent vs my camera's flash, applying a fluorescent DNG profile, dual & single table and Adobe Standard and couldn't get any closer. This is a VERY deep, rich and vibrant aqua. No where online can I find an accurate representation of this aqua.
I only have an sRGB-ish gamut display so those who have wide gamut may be able to reproduce this aqua and if not then you know that color's gamut is beyond any digital reproduction technology at this time and maybe even scientific instruments such as a spectro.
Here's my results...
-
Look, I have no ulterior motive in all this. I am just another natural light photographer chasing elusive perfection. If we realize that in all this camera profiling is a complete farce, I will be happy to swallow that. Right now I am honestly a bit confused as to how we are going to approach this testing.
but w/o an approach we shall not discuss... if it is a matter of your taste then there is nothing to discuss really... more over if you are a natural light photographer ask yourself hard - what do you not like in Adobe's profiles... matrices or LUTs really... you do not need any targets to get rid of LUTs or change them... why bother.
And for florescent lights the Adobe Standard profile seriously sucks.
you are a natural light photographer, are you not ?
Andrew, I am sure that with reference values from various color targets, we can evaluate the accuracy of the profiles by comparing with rendered values of photographed targets? But scene colors that are not on a target are going to be harder :(
suggestion was - build profile from one taget, measure the qualify from a different target - not the one that was used to build a profile !
-
suggestion was - build profile from one taget, measure the qualify from a different target - not the one that was used to build a profile !
It's a good suggestion and could be done or added to whatever testing process is worked out.
The initial idea I think was to see how ICC vs. DNG profiles work in terms of a single raw converter that can accept both. We don't have that option in Adobe raw converters. It is possible in Raw Developer and Brian the author give some tips on how to do this. One could shoot a scene raw then apply both types of profiles and post them side by side with the photographers personal preference. Then apply the same two profile types to other images and see how they do.
Someone could certainly capture say a Macbeth target, use both profiles, end up in say ProPhoto RGB and compare the reference (what those 24 patches should be) against the results and end up with a dE values. Then if camera metameric failure raises it's ugly head, we can ponder if using subjective subjects or as Tim illustrated, very difficult color originals is affected with one or both profile types equally.
-
> It is possible in Raw Developer and Brian the author give some tips on how to do this.
?? In your quote in the Shooting Color Targets thread, I think he said Iridient Developer did NOT support DNG profiles other than embedded in DNG image files. So how would you embed them unless in ANOTHER raw converter that supports this? Or do you have new information?
-
> It is possible in Raw Developer and Brian the author give some tips on how to do this.
?? In your quote in the Shooting Color Targets thread, I think he said Iridient Developer did NOT support DNG profiles other than embedded in DNG image files. So how would you embed them unless in ANOTHER raw converter that supports this? Or do you have new information?
Correct (about only supporting embedded DNG image files). It appeared however one could test those profiles unless I'm having a brain fart and missing something:
I'd like to see good peer review on this subject! I'd like testing to be well defined. I'd like to see a number of savvy users (not the DP review crowed) to give the two processes a try then report their findings. Can this be done in your product, ideally even in demo mode? If so, are there specific steps one should follow to build both sets of profiles and then use them?
Demo mode will watermark images with red text which could throw off profiling tools... However, given a custom ICC profile for an image you could load that in the demo just fine for viewing.
DNG currently can only be of the original color matrix type and must be embedded into a DNG image file. No support for loading of standalone DCP format color profiles at this time in Iridient Developer at this time. So you need to profile the DNG and then embed the custom profile back into the DNG file. Again could load custom DNG profile data out of a DNG file for viewing with the demo, but I do not support export of DNG files for profiling.
for Iridient Developer to output an image for profiling:
1) Disable all color management by checking the checkbox on the Out pane of the settings window.
2) White balance the reference image if necessary
3) Adjust camera tone curve either to accurate linear gray scale or gamma 2.2 or sRGB or I've even done some work with LAB grayscale too (close to gamma 2.4). Some tools will be picky about the tone curve and will expect image data in roughly 2.2 or 1.8 gamma. Some like ArgyllCMS will work with just about anything you toss at them.
4) Export as TIFF ideally 16 bits/channel (critical for linear data) if the profiling tool supports it.
After profiling the created profile will generally be tied to the camera tone curve used above. Uncheck the disable color management option and choose the ICC profile in the Input Profile popup menu after copying to one of system ICC profile folders (/Library/ColorSyc/Profiles/ etc). You can modify the camera tone curve, but you'll lose accuracy just like you do if you modified an RGB tone curve to a carefully calibrated image from a scanner.
Most of my default camera profiles where I am not be hyper sensitive to getting accurate color I'll actually just go and modify the camera tone curve to normalize exposure and smoothly roll off highlights, etc even though the ICC profile was created under the assumption of perfectly linear data. As long as the curve is largely linear especially through the critical mid tones I think this is OK...
Or just skip ID and find another product that does both. Or wait on Brian to maybe allow this functionality which *could* happen.
-
As far as I can gather, you must be referring to this passage:
>>"So you need to profile the DNG and then embed the custom profile back into the DNG file."
- this would have to be done in a converter other than ID, or is it me who is missing something?
then you could VIEW the result in ID:
>>Again could load custom DNG profile data out of a DNG file for viewing with the demo, but I do not support export of DNG files for profiling.
--
Raw Therapee has been reported to do both.
-
@ samueljohnchia, original post
> Let's add to this list
Have you dropped the no-profile approach by ColorPerfect that you mentioned yourself? I find it gives very convincing results on scanned 3f-files.
BTW it strikes me that the monitor profiling software ColorEyes seems to follow the same philosophy, it just deals with grayscale and red, green and blue.
-
So how would you embed them unless in ANOTHER raw converter that supports this? Or do you have new information?
you open the file in ACR w/ the necessary camera profile and save it as DNG (non linear) for example... the profile shall be embedded then
-
Yes of course! Thank you.
-
Raw Therapee has been reported to do both.
actually in addition to that we have quite active RT developers among forum members - at least two - Michael Ezra and Emil Martinec ... not sure if they worked on color profiles part there, but they might be able to comment.
-
Have you dropped the no-profile approach by ColorPerfect that you mentioned yourself? I find it gives very convincing results on scanned 3f-files.
BTW it strikes me that the monitor profiling software ColorEyes seems to follow the same philosophy, it just deals with grayscale and red, green and blue.
Hening, no I have not dropped ColorPerfect. I am trying to get up to speed with ColorPerfect, and have been corresponding with David to clarify certain image quality issues I noted. I have used it for digital raw images, not for scanner files. Generally speaking, it gives wonderful results at its default settings when compared to ACR's default settings. It also does not have a hidden baselineexposure offset and the color rendering is quite good considering that there is no typical "profile" of any sort, just balance for grays and let the colors fall where they may. However, I have gotten used to my custom camera profile and the way it renders color in ACR, and rightly I am biased. I tend to shy away from the default settings in ACR (too much contrast and saturation) and prefer to begin with a linear tonal representation of zeroed settings. I will comment more on ColorPerfect when I have a better grasp on how to use it and what it does. The current UI is so user-unfriendly that it is hindering my learning of its novel approach. I am also unsure if I would see improvement in the results if I custom gray calibrated my camera instead of using the generic calibration in ColorPerfect.
I appreciate the simplistic approach to all this. You always gain some and lose some in a profile. For display calibration, with low end displays, twisting it's native behaviour with a LUT profile may introduce artifacts, especially for low end displays. Question is, is a DNG or ICC camera profile ruining your "color integrity" - the main argument behind ColorPerfect's alternative approach?
you are a natural light photographer, are you not ?
I am open to learning about how camera profiles behave under different lighting situations. In an earlier post, I expressed interest in a copy studio setup with artificial lighting, despite my favor for natural light. In addition, I was interested to see if my new QPcard 203 really outperforms the CC under that illuminant, because that was what it is marketed to do. Untwisting the standard profile and comparing it alongside was a simple matter, and I was curious about how it performed. I think it would give us all a broader picture of what works when, if we look at a greater number of situations that just the ones we face.
Yes, I am also interested to learn how RT deals with DNG/ICC profiles, in particular the former and its dual matrices.
-
In an earlier post, I expressed interest in a copy studio setup with artificial lighting, despite my favor for natural light.
but then you do not need to intentionally use an artificial light w/ spectrum like sodium vapor or fluorescent light, do you ? why 'd you equip a studio w/ such light instead of a something w/ proper spectrum ? for some special effects ? but then you might be exactly looking for a bad color reproduction for that purpose ::)
-
It also does not have a hidden baselineexposure offset
you can manually set baseline exposure to zero in your .dcp profiles - so that is not a reason at all
-
but then you do not need to intentionally use an artificial light w/ spectrum like sodium vapor or fluorescent light, do you ? why 'd you equip a studio w/ such light instead of a something w/ proper spectrum ? for some special effects ? but then you might be exactly looking for a bad color reproduction for that purpose ::)
I think you have misread my intentions. I was specifically told when I wrote in to QPcard that I would see clear advantages when profiling for fluorescent light sources, and that I should try that, so I decided to include that with my initial testing for the QPcard vs CC (some additional comments in the other thread), and I just dropped a simple comment on fluorescent light performance that's all. Eric Chan also mentioned elsewhere that folks will probably be much happier with custom camera profiles for unique spiky light sources as the Adobe Standard profiles are really meant for tungsten-daylight images, that's part of the reason why the DNG PE was made available. I'm not surprised with the results that I got, except for the fact that I could come reasonably close to the real deal with camera profiling from such a limited set of color patches in a target, made from limited materials that Ernst pointed out in my other thread, is most probably because of sheer luck than any camera profiling wizardry has got to do with it.
If it pleases you I'm sure that we will not be bothering to further test profiles for fluorescent light sources in this thread. No need to get worked up over this small issue.
you can manually set baseline exposure to zero in your .dcp profiles - so that is not a reason at all
I must be mistaken. I know I can remove the Base Tone Curve for dcp profiles, not the BaselineExposure offset. Bjanes has documented that issue elsewhere on this forum. If you know how to offset that in the dcp profile manually, I'm all ears.
-
?? In your quote in the Shooting Color Targets thread, I think he said Iridient Developer did NOT support DNG profiles other than embedded in DNG image files. So how would you embed them unless in ANOTHER raw converter that supports this? Or do you have new information?
An update! From Brian:
The Iridient Developer 2.0.1 update is now available here and adds full support for DNG Camera Profiles from the very latest DNG v1.4 spec:
http://www.iridientdigital.com/products/rawdeveloper_download.html
A couple notes:
1) There is still the option to color render using the older (baseline, most camera makers still use the old spec too) DNG v1.1 color matrix rendering too, even when loaded from full DCP files.
2) If you load a DNG you will now have 3 Input Profile options available (at least).
a) ICC profile --> generally my default --> uses my default camera tone curve
b) DNG Matrix Color --> this is the old v1.1 DNG color spec. Lacks support for tone curves, color lookup tables, etc. --> uses my default camera tone curve
c) DNG Camera Profile --> this is the very latest v1.4 DNG color spec. --> by default uses either embedded tone curve or DNG SDK default (based on old ACR3 rendering style, I think Adobe 2010 process?) --> however optionally can disable use of DCP tone curve and use my camera tone curve.
2) Sometimes you'll see a fairly big difference between the DNG Matrix Color and the DNG Camera Profile, even with Adobe standard profiles and/or DNG image files that may only have support for the older DNG v1.1 specification. Why is this?
This is almost always largely due to differences in default tone curves. In the case of say a camera maker's DNG file that only specifies the original DNG v1.1 color information there will be no camera tone curve. So the DNG SDK v1.4 defaults to the old ACR3 style tone curve, obviously this may not match up exactly with the latest ACR7/LR4 style rendering. On the other hand (in theory) if the DNG Camera Profile includes a specific tone curve then both Adobe software and Iridient Developer will use the same DCP tone curve for rendering and the match should be quite good?
Haven't had a chance to mess around any with Color Checker Passport profiles and this latest release yet and I can't remember if they included their own tone curves or not? If they don't this could be an issue in color matching between Iridient Developer rendering and the latest Adobe software which I believe uses a newer default tone curve setup?? Anyway something to be aware of.
This is one of the continuing issues with the DNG color spec or for that matter RAW image color matching in general. If the most common option is to fall back to the Adobe default tone curve and Adobe doesn't publish their default tone curve spec then you'll get different results from different RAW processors. Same case with ICC profiles too, in order to use say Capture One ICC profiles with Iridient Developer you need to use the Capture One camera tone curves too to get a close match.
3) DNG Camera Profiles are much slower than other color rendering options. About 5x slower than my implementation of the original DNG v1.1 color spec! Adobe DNG SDK code is nice to look at, but extremely (often unusably!!) slow. I did some multi-threading and other quick and easy optimizations to the DNG SDK v1.4 giving about a 4-12x speedup, but it's still relatively slow compared to well optimized code that takes advantage of vector processing, etc.
That said "slow" on a mid-range to slow Mac when exporting a full size 16MP image is maybe about 0.5 sec versus something like 0.08 sec for my DNG matrix processing (written before DNG SDK even existed so all custom Iridient code) or ICC profiles which use Apple's ColorSync which is very well optimized for multi-core processing and vector support. With Adobe lens profiles my final implementation ended up being about 8-40x faster depending on processor than the DNG SDK code so if the DNG camera profiles are a popular option it will likely get much, much faster in the future as I move away from use of the DNG SDK for this color processing...
I also added an option in my Camera Curve pane to "Use Embedded Curve". If this option is disabled then the Iridient Developer or user specified tone curve will be used in place of the DCP tone curve (or lacking one the DNG SDK, ACR3 fall back default).
If you disable the "Use Embedded Curve" checkbox with the standard DNG Camera Profiles or v1.1 spec DNG images then the DNG Matrix Color and DNG Camera Profile color renderings should be virtually identical (and in many cases quite similar to my default ICC profile too...).
Anyway let me know what you think. Look forward to your feedback! Supports using embedded DNG image data or loading camera profile data from standalone profile files (DCP) or other DNG images.
Adobe's Camera Profiles as shipped with ACR or DNG Converter or LR are located here:
/Library/Application\ Support/Adobe/CameraRaw/CameraProfiles
Best regards,
Brian Griffith
Iridient Digital
-
> I must be mistaken. I know I can remove the Base Tone Curve for dcp profiles, not the BaselineExposure offset.
that is what I do (w/ all profiles, ACR7.x, to use w/ "Process 2012") for .xml dump from dcptool (and compile back to .dcp) :
<ToneCurve Size="2">
<Element v="0.000000" h="0.000000" N="0"/>
<Element v="1.000000" h="1.000000" N="1"/>
</ToneCurve>
<BaselineExposureOffset>0.000000</BaselineExposureOffset>
-
When opening a DNG with embedded and custom profile in ID, the preview looks very close but as expected, not identical to the same image in Lightroom. This leads me to believe that one can create custom DNG profiles and they work as expected in ID 2.0.1 as well as Adobe converters of course.
To select the DNG profile, use DNG file metadata in ID where you'd select an ICC profile.
-
digitaldog:
> An update! From Brian
Look what His Masters Voice can achieve! :-)
and thanks for the instruction.
-
> I must be mistaken. I know I can remove the Base Tone Curve for dcp profiles, not the BaselineExposure offset.
that is what I do (w/ all profiles, ACR7.x, to use w/ "Process 2012") for .xml dump from dcptool (and compile back to .dcp) :
<ToneCurve Size="2">
<Element v="0.000000" h="0.000000" N="0"/>
<Element v="1.000000" h="1.000000" N="1"/>
</ToneCurve>
<BaselineExposureOffset>0.000000</BaselineExposureOffset>
Thanks for letting me know about the dcptool, now I know all the answers of my questions regarding DNG PE ;D ;D
BTW, what is the meaning of this BaselineExposureOffset?
-
> I must be mistaken. I know I can remove the Base Tone Curve for dcp profiles, not the BaselineExposure offset.
that is what I do (w/ all profiles, ACR7.x, to use w/ "Process 2012") for .xml dump from dcptool (and compile back to .dcp) :
<ToneCurve Size="2">
<Element v="0.000000" h="0.000000" N="0"/>
<Element v="1.000000" h="1.000000" N="1"/>
</ToneCurve>
<BaselineExposureOffset>0.000000</BaselineExposureOffset>
Sorry, inserting the BaselineExposureOffset tag does not work for me. Only removing the tone curve does.
-
BTW, what is the meaning of this BaselineExposureOffset?
Take a look at this: http://www.luminous-landscape.com/forum/index.php?topic=30794.0 (http://www.luminous-landscape.com/forum/index.php?topic=30794.0)
-
When opening a DNG with embedded and custom profile in ID, the preview looks very close but as expected, not identical to the same image in Lightroom. This leads me to believe that one can create custom DNG profiles and they work as expected in ID 2.0.1 as well as Adobe converters of course.
To select the DNG profile, use DNG file metadata in ID where you'd select an ICC profile.
Awesome stuff! Thank you Andrew, for nudging Brian to support the latest 1.4v spec, and also thanks to Brian for implementing it so quickly. This is wonderful. My experience with Raw Therapee is also similar and we can add that to the list of raw converters that handle can DNG profiles outside of Adobe's.
Have you tried the generic ICC profiles against your custom DNG profiles yet?
-
Sorry, inserting the BaselineExposureOffset tag does not work for me.
may I ask you how did you test that ? for example decompile a profile, make baseline exposure = 3.0 (or something like this, to see for sure), compile it back (w/ different name of course), open your raw file and switch between those 2 profiles where only baseline exposure differs by 3 EV (or whatever you put there)... do you see no changes at all ? are you sure ?
-
may I ask you how did you test that ? for example decompile a profile, make baseline exposure = 3.0 (or something like this, to see for sure), compile it back (w/ different name of course), open your raw file and switch between those 2 profiles where only baseline exposure differs by 3 EV (or whatever you put there)... do you see no changes at all ? are you sure ?
Yes, I did that. I started with a custom profile built using the DNG PE. I created two versions, one with a <BaselineExposureOffset>0.000000</BaselineExposureOffset> tag and one with a <BaselineExposureOffset>3.000000</BaselineExposureOffset> tag. All three give me exactly the same result.
I tried it on a Adobe Standard profile for my camera and the same thing happened.
Of course eliminating the tone curve did give me a linear profile, but the BaselineExposureOffset didn't offset any exposure.
-
Yes, I did that. I started with a custom profile built using the DNG PE. I created two versions, one with a <BaselineExposureOffset>0.000000</BaselineExposureOffset> tag and one with a <BaselineExposureOffset>3.000000</BaselineExposureOffset> tag. All three give me exactly the same result.
it is very strange because in my case it does ( ACR 7.4 RC + Process 2012 ) ...
-
Have you tried the generic ICC profiles against your custom DNG profiles yet?
I have to look at a lot more images but so far, the differences seem rather subtle. Here's one example with the only differences being the profile and everything else ID Defaults. (do we like the blue patch?):
(http://www.digitaldog.net/files/DNGvsICC.jpg)
-
it is very strange because in my case it does ( ACR 7.4 RC + Process 2012 ) ...
Do you mind looking at my xml file? It is at this link (https://www.dropbox.com/s/ojp3iq9t09vz0z4/Canon%20EOS%205D%20Mark%20II%20Daylight%20Both%20Color%20Tables%20BEO.xml).
I added the baseline tag after the tone curve (which I left there to just test the effect of that tag). If I have formatted it wrongly please let me know.
-
I have to look at a lot more images but so far, the differences seem rather subtle. Here's one example with the only differences being the profile and everything else ID Defaults. (do we like the blue patch?):
The icc profile also has a slight green cast at this WB setting. May have to use a different WB for comparison. Hmm blue patch. I prefer the top image. Purple patch goes to the bottom image. But both are rather washed out!
-
The icc profile also has a slight green cast at this WB setting. May have to use a different WB for comparison. Hmm blue patch. I prefer the top image. Purple patch goes to the bottom image. But both are rather washed out!
I might but what I wanted to do was simply see the differences between the two profiles, nothing else. And that said, I too prefer the top image. The top has a tad more contrast too and I guess I could 'equalize' the two. But right off the bat, I like the custom DNG profile a bit better.
-
I might but what I wanted to do was simply see the differences between the two profiles, nothing else. And that said, I too prefer the top image. The top has a tad more contrast too and I guess I could 'equalize' the two. But right off the bat, I like the custom DNG profile a bit better.
I'm ok with re-white balancing, but I'm not sure about equalizing the contrast - depending on ID's implementation, it may introduce hue and saturation shifts and it will be difficult to tell if its the profile twisting the colors or the adjustment. Hence the earlier discovery to find linear renderings from ACR, ID and RT.
We need to look at custom ICC profiles too. I apologise for the delay in testing on my side. I've been rather swamped of late. I think I would have some time later this week to do the testing again.
-
Do you mind looking at my xml file? It is at this link (https://www.dropbox.com/s/ojp3iq9t09vz0z4/Canon%20EOS%205D%20Mark%20II%20Daylight%20Both%20Color%20Tables%20BEO.xml).
I added the baseline tag after the tone curve (which I left there to just test the effect of that tag). If I have formatted it wrongly please let me know.
you certainly do something wrong...
I took 5DmkII Adobe Standard profile, decompiled it, removed LUT (not that it matters, just I can't stand 'em)... baseline exposure tag was there w/ value = 0... I changed the name of profile to BE0, left tag @ 0, compiled to BE0.dcp, moved to the proper custom profiles location, then changed the name of profile to BE3, changed tag to 3, moved again to the proper custom profiles location... now when I open a raw from 5DmkII I can see two new profiles BE0 and BE3 and switching between them changes the exposure... so I 'd assume you did something wrong in your setup - are you sure you are even using the proper profiles with different baseline exposure tags in your setup ?
-
Here's another quickie. Canon 5D2, 2 Solux lamps run at 14 Volt, custom WB of the day.
All displayed in ID, working and output profile set to ProPhoto, rendering intent to rel.col. Otherwise ID defaults except the profiles:
1-ID default ICC
2-QP ICC
3-QP dcp
My view:
2 is visually closest to the physical chart in the pale yellow at bottom right (E7) and its neighbours, which are more reddish in particular in 3.
2 is also best in showing the slight differences in the reds (B2-4). None of them hits the purplish blue in B 4, but 1 is slightly closer than the others. 3 looks overall muddy, which is confirmed by the DigitalColorMeter: the white patch in A7 has gone from 214/211/208 in 1 and 2 to 195/192/189.
Good light - and true colors ;-)
-
you certainly do something wrong...
I took 5DmkII Adobe Standard profile, decompiled it, removed LUT (not that it matters, just I can't stand 'em)... baseline exposure tag was there w/ value = 0... I changed the name of profile to BE0, left tag @ 0, compiled to BE0.dcp, moved to the proper custom profiles location, then changed the name of profile to BE3, changed tag to 3, moved again to the proper custom profiles location... now when I open a raw from 5DmkII I can see two new profiles BE0 and BE3 and switching between them changes the exposure... so I 'd assume you did something wrong in your setup - are you sure you are even using the proper profiles with different baseline exposure tags in your setup ?
Ahh I missed the dcpTool december update to DNG v1.4 spec. My bad. Otherwise everything went as you said, as expected. I can also see the other tags ProfileLookTableEncoding and DefaultBlackRender now.
-
Here's another quickie. Canon 5D2, 2 Solux lamps run at 14 Volt, custom WB of the day.
All displayed in ID, working and output profile set to ProPhoto, rendering intent to rel.col. Otherwise ID defaults except the profiles
Hening, have you tried them in ID's linear mode - all sliders zeroed? These look too contrasty and are not close to the reference values. ID's default settings probably introduces hue and saturation shifts on top of tone shifts that is going to be evaluation tricky.
-
Andrew, I think you in particular might find this interesting. I read about your discussion here (http://www.luminous-landscape.com/forum/index.php?topic=69676.0) some time ago and I was interested too how different can two cameras be. Perhaps other folks may also be interested.
Here (https://www.dropbox.com/s/njkdeu4z3uchdjd/2samples_%205dmkII_cc_qp.zip) are four photos from 2 different 5D Mark IIs. I photographed both the ColorChecker and the QPcard. All of them were made in under daylight illumination. the ColorChecker was in direct sunshine, the QP was when the sun got obscured by cloud. Light was rather consistent when switching between cameras.
They are not identical but I am surprised by how close they are. Yes, they are only two units, and I won't mind getting my hands on a few hundred or more 5Ds.
-
Here are the same 3, everything linear. Obviously, the removal of the camera curve in ID has had no effect on the DNG. So this is not comparable. Also I think it is not a valid procedure just to remove a curve from a profile that is created to have one. At least this is as I understand Brian.
The images are too contrasty? You sound like you have measured them, but visually, I find them close to the target, displayed in the same Solux light to the same exposure value (8 1/3) at which they were shot. Whereas the linear images look muddy as exspected.
Anyway, this was just a quick aside for me. What I really am exploring right now is ColorPerfect, which I find theoretically most intriguing, and - so far - very convincing in a few non-calibrated roll film scans.
-
Light was rather consistent when switching between cameras.
and what was that supposed to prove or disprove ? I can understand when you illuminate sensors in 2 different cameras (the same model) the same way with monochromator in a controlled lab env... but "rather consistent" light outdoors ???
-
The images are too contrasty? You sound like you have measured them, but visually, I find them close to the target, displayed in the same Solux light to the same exposure value (8 1/3) at which they were shot. Whereas the linear images look muddy as exspected.
I should have mentioned to adjust the exposure slider to patch the white patch to it reference value.
Here's my shot of the QP with a custom dcp profile for it. All sliders in ACR zeroed, tone curve linear. Exposure slider adjusted to match the white patch to its reference value. White balanced from the second neutral patch from the left. I find it much closer to the reference values provided by Robin Myers.
Also I think it is not a valid procedure just to remove a curve from a profile that is created to have one. At least this is as I understand Brian.
Depends on what you are after, I guess. You can strip the curve from the DNG profile manually. Vladimirovich suggested doing so - I gather he prefers it that way.
-
and what was that supposed to prove or disprove ? I can understand when you illuminate sensors in 2 different cameras (the same model) the same way with monochromator in a controlled lab env... but "rather consistent" light outdoors ???
Nothing if you look at it that way. The sun basically didn't move much between shots that were some seconds apart, and no clouds came in to affect the light. I'm surprised that they are this similar, that's all. I was expecting to see much bigger differences since a number of variables were out of my control (actually I would rather it were significantly different, because it might further justify all this custom profiling work). If I may be so bold as to say from two 5D Mark IIs (the cameras were bought months apart) that the cameras are very consistent with they way they capture color, the Adobe generic profile should do a good job, and basically reduces the need for a custom camera profile, except for non-daylight/tungsten light. This could go some way to support your stand that the Standard profiles are enough, and I don't deny that.
-
So here the 2 ICC renderings are with exposure adjusted. I can not do to DNG profiles what Vladimirovich can, which implies compiling and decompiling.
My white balance is from an external card. Here are the Lab values for the white patch as the Mac DigitalColorChecker reads them on the screen:
ID: 94-2.137-3.176 QP: 94-1.707-3.340
and in Photoshop:
ID: 94-2-3 QP: 94-1-3
but the a and b values vary a good deal between 1 and 4
Reference: 94-0-2.8
What I wrote about linear vs gamma-encoded profiles was what I understood from Brian, which referred to the color management processing pipeline in ID. If the input profile is e.g. linear, the pipeline exspects linear data, and you can not just change that under ways. Conversion to a gamma encoded image is done on output. However, my understanding may be lacking. Also, that was about gamma encoding, not a linear adjustment of the white point.
-
Hi
I am in doubt about the purpose/state of this thread. Samuel, are you breeding on a common testing procedure ?
In the meantime, I have fiddlet a little with Iridient Digital and ColorPerfect, with the question: If I want to use CP, am I restricted to MakeTiff as the raw converter, or can I use e.g. Iridient?
Screen shots of the results in the zip.
My conclusion is yes I can use ID with my own linear profile. The canned profile of CP is good, as is my own, but not IDs default if linearised.
-
Hi
I am in doubt about the purpose/state of this thread. Samuel, are you breeding on a common testing procedure ?
In the meantime, I have fiddlet a little with Iridient Digital and ColorPerfect, with the question: If I want to use CP, am I restricted to MakeTiff as the raw converter, or can I use e.g. Iridient?
Screen shots of the results in the zip.
My conclusion is yes I can use ID with my own linear profile. The canned profile of CP is good, as is my own, but not IDs default if linearised.
Hi Hening, apologies for my cyber silence. I got swamped with work this week but I managed to put some time in here and there to look deeper into camera profiles.
Let me first address ColorPerfect. I am struggling with its UI. But I am seriously shocked by how accurately its renders colors at its default settings (with the correct WB and white point settings), even with photographs of color targets - with no internal profile to skew colors to a few reference values, leaving us to think what's happening then to the rest of the colors. This I think we both agree on. There are other issues I have with CP. One of them that stopped me from going further with CP is that I cannot set it to render a completely linear tone curve. By design, it applies an automatic black point (BP). Look at this example:
(http://dl.dropbox.com/u/15547362/CP_Black_Point_test.jpg)
I carefully set the White point correctly in both ACR and CP for this test, not so easy to do in CP! The entire image was remarkably similar tonally except in the shadows, and color rendering. The first image crop on the left is ACR's linear mode. The rightmost image is CP with its recommended BP setting, smartly calculated, may be unique to each image. The third image on the left is when I manually set its BP to zero. Second image from the left is ACR in linear mode, but with the Blacks slider at 5. Coincidentally, the default for Blacks in PV2010 is very similar to the minimum BP setting in CP. On checking with David, he informed me that I should never set the BP to less than 0.001, because of imperfections in image quality from sensors near the noise floor. With sensors performing as well as those on the latest Nikon, Sony and Pentax cameras, I'm not convinced that the BP clipping need be so high. Many photographers will disagree with me on this, and often they would want a strong black in their images and that's ok. For me I would rather decide whether to clip or not upon deciding my output medium, since printers are getting better and better at reproducing tones near black, and things get interesting there. Jon Cone has an interesting article on that. (http://www.piezography.com/PiezoPress/blog/piezography-life/dmax/)
You can certainly feed ID linear files into ColorPerfect, but David of course recommends MakeTiff. You must be able to get ID to output a linear gamma, unity white balance, non-profile tif to take advantage of Color Perfect's "color integrity", as it was designed.
Back to the profiles. Yes, your latest collection of CC photos all look quite similar, but with white point setting too high, I had to darken all the images to match the white patch reference value. That darkening may have skewed the colors a bit, since I had to work on a gamma corrected image, not a linear gamma version. Also, since this is a screenshot, your display profile may be doing unexpected things to the color.
I stress again that to properly make comparisons, we must first match the white patch to its reference value by setting the correct white point (figuring out which slider in different raw converters does this is not as hard as I thought initially), and set a custom white balance after applying the profile, using the second lightest neutral patch of the CC. It will be unique for every profile (even in the same raw converter) but it is necessary so that the neutral patches are that - neutral. Then let everything else fall where they may.
But here is a synthetic CC overlay of your 2C=ID,-Canon_lin,-WP-adj-in-ID file:
(http://dl.dropbox.com/u/15547362/2C%3DID%2C-Canon_lin%2C-WP-adj-in-ID.jpg)
Here is one of mine from ACR in "linear mode" and a custom profile from the DNG PE:
(http://dl.dropbox.com/u/15547362/ACRlinear_DNGPEcustomprofile.jpg)
Here is another from Raw Therapee in "linear mode" with a custom profile that I built in Argyll using the arguement "colprof -v -y -qh -am -nc -u" in command line:
(http://dl.dropbox.com/u/15547362/RT_Argyll_customICC.jpg)
I'm not convinced that RT can handle dual table DNG profiles. It messed up with the same DNG profile that I used in ACR. One can set the preferred profile to Daylight, Tunsten, fluorescent or flash, possibly indicating that it is only using one table at one time. Btw this setting does not affect ICC profiles. This one is the "daylight" option:
(http://dl.dropbox.com/u/15547362/RT_DNGPE_daylightoption.jpg)
This one is the "tungsten" option:
(http://dl.dropbox.com/u/15547362/RT_DNGPE_tungstenoption.jpg)
Caveat: These are all converted to sRGB for the web, and the cyan patch in row three is not correctly represented. Here is a tif file (https://dl.dropbox.com/s/0u0lew1n4uz57ni/dng_icc_acr_rt_comapred.tif?token_hash=AAGrB52tZLppxS0uCJoL4AcY2GvNEbM-W7tPUfd9kwFVwQ&dl=1) (10MB), with all the examples in labeled layers, ProPhoto RGB, 16 bits.
I don't have access to a mac at the moment, but I think ID will handle DNG profiles correctly. I must try it out later. I would only be able to run ID in demo mode and cannot make a custom ICC profile for it. Might need some help with that.
I am surprised by how well the ICC profile performed. The ICC profile that I created was a simple matrix profile, with the -u flag in Argyll to "avoid setting the white point to that of the profile chart (http://argyllcms.com/doc/Scenarios.html#PS4)". Additional information is here (http://www.argyllcms.com/doc/colprof.html#u). This, I am thinking, makes the ICC profile behave similarly to a DNG profile, assuming you strip the DNG profile of its LUT table. Not the tone curve, because the ICC profile will scale the patch values to the reference values in the matrix curves, effectively a "tone curve" as well.
I'm not sure what the DNG Profile Editor is using for its ColorChecker reference values, but I know for Argyll. It could be that that is causing the subtle differences we see here. Differing tradeoffs in designing the algorithms to map colors could also be another factor. Raw converter handling of camera profiles could also be involved. Many other factors that are not immediately obvious too.
Then there are many ways that one can mess up profile building doing the capture process (solarj is having this problem in another thread), and the profile building process. In the course of my testing, I discovered that the DNG PE is extremely sensitive to the placement of the four control points - slighly changing their positions will result in a visibly different profile. Sometimes hard to tell which is better, because some areas improve while others shift away from ideal. ICC profiling is too complicated to detail in this long post right now.
At this point I don't know if all this work is ever going to be justified. We still don't have luminosity based curve adjustments in the commonly used raw converters, including all the tone affecting sliders that affect a general image tone curve. I also disagree wholly with the results I am getting from ColorPerfect's "scientifically correct" method of saturating images, and I find Joseph Holmes's color variants to be far superior in many ways, not just the visible results. This all might work out in the end assuming that it works as it should, and the image processing pipeline does not introduce hue shifts at all, to invalidate the camera profile. Tough for the stars to align this way.
-
samueljohnchia, have you noticed that DNG PE never generate any matrix? It just took the matrix from the profile you selected when you start the chart wizard and generate a 90x25x1 LUT on top of it
-
samueljohnchia, have you noticed that DNG PE never generate any matrix? It just took the matrix from the profile you selected when you start the chart wizard and generate a 90x25x1 LUT on top of it
Yes, I am aware of that. The matrices cannot be edited in the DNG PE at the moment. I'm not sure about the consequences of such a design, and one is tied to the LUTs to enjoy the corrections by the profile. If your preference in to go with the X-rite solution, by all means go ahead.
-
Hi Samuel,
thank you for your extensive answer. There is no reason for apologies for your silence. You are under no obligation. I just wondered about the state of the project.
Let me know what I can do on the Mac. I in turn may need help with procedure and software handling to achieve what you want. I'll start trying to improve my profiles (Uff - I who thought I had a reasonable one!) using the new shots that just fill about 1/2 of the frame and see if that helps.
-
samueljohnchia, have you noticed that DNG PE never generate any matrix? It just took the matrix from the profile you selected when you start the chart wizard and generate a 90x25x1 LUT on top of it
Writing this in response to solarj. DNG profiles can contain the following tables, but not profile building/editing software fill all table values.
1. CameraMatrix1
2. CameraMatrix1
3. ForwardMatrix1
4. ForwardMatrix2
If the raw converter follows the DNG spec in the way it handles DNG profiles, it will use the ForwardMatrix table values instead of the CameraMatrix table values. If the Forwardmatrix is not included (table values =0) then a rather convoluted method is used to map colors.
The Adobe Standard profile in general contains information in all four tables. - this is by default the base profile used by the DNG PE, so your new custom profile will also inherit these matrices.
X-rite Passport contains only 1. for single illuminant profiles. For dual illuminant I'm assuming it contains 1. and 2. It does not include the ForwardMatrices. Too bad.
QPcard contains only 1. and 3.
I spent considerable time to eliminate all the LUTs in the profiles except for the matrices, so see which one looks best in comparison. I hope this information may be useful to others. Here is a ProPhoto 16 bit tif (https://dl.dropbox.com/s/tphczekwzzcnwbs/DNG_Matrices_compared.tif?token_hash=AAFtB-vF7rOjrMiSsj6h6wFC_9TMa-wPT9zOo6Cv1zhpQA&dl=1) with all the important versions on separate layers, overlayed with a reference CC target.
Additional info about the layers:
"Adobe Standard Matrices, DNGPE LUT"is Adobe Standard profile matrices with custom LUT from the DNG PE built with a photograph of my CC.
"X-rite Passport software matrices, DNGPE LUT" is the X-rite custom matrices with with custom LUT from the DNG PE built with a photograph of my CC
"Adobe Standard ColMmatrix1" is the Adobe Standard matrices stripped off all except for the D65 illuminant ColorMatrix table.
"Adobe Standard ColMatrix12 ForMatrix12" is all the Adobe Standard color matrices in play
"Xrite ColMatrix1" is the custom X-rite ColorMatrix generated when building my custom DNG profile
"QP ColMatrix1 ForMatrix1" is the QPcalibration generated matrices when building a custom DNG profile from a QPcard 203
Observations about the color matching. The "Adobe Standard ColMatrix1" is closer in the blues and purples, while the "Xrite ColMatrix1" is closer for the warm colors. The profiles which include the DNG PE custom LUTs are much closer. While the X-rite version lost out slightly in the red and light skin patch, it won visibly in the oranges in row two. The rest look more or less the same.
I'm not sure which I'd rather go with at the moment. If X-rite would also create the ForwardMatrices, I might be more inclined to use that as the base profile in the DNG PE.
-
Samuel, thank you for sharing the result of this extensive effort!
-
Samuel, thank you for sharing the result of this extensive effort!
Fixed - Link to wrong file.
You are welcome! If you need help to get the profile to map the target's colors closer to the reference values, I'll do my best.
I managed to "trick" Irident Developer into not putting the watermark (I ran the demo) right in the centre of the ColorChecker image by cropping it off-center. It worked!! I am glad that I got the CC to only fill about 1/4 of the frame. Otherwise I would have to restart from the beginning because all the custom profiles must be generated from the same image. That was many hours of work.
This is what we've all been waiting for. DNG vs ICC, across Adobe Camera Raw (DNG only), Raw Therapee and Irident Developer. Here is the tif file, ProPhoto RGB, 16 bits (https://dl.dropbox.com/s/w7mb7khmumuu116/dngvsicc_ACR_ID_RT%20copy.tif?token_hash=AAGLhWxk-gADk8P2iF4MHGp7LlE-NfA9U8c0tOtr_5MTqQ&dl=1).
Just for fun I also made RT process out a photo using the custom ICC profile from Raw Therapee. That is the "RT with ID custom ICC" layer. It is surprisingly close to the RT specific custom ICC profile, which is the "RT with custom ICC" layer. This is probably because of my ICC profile building choices that I explained earlier. Very interesting. Cross raw converter compatible ICC profile anyone?
ID does seem to work well with the latest DNG profiles. Compare layers "ID with same DNG profile as ACR" and "ACR DNGPE Adobe Standard base custom LUT". It was extremely difficult to get the exact exposure and white balance between the two raw converters to match, but I think I got it close enough, especially since the mac I borrowed was a laptop, and my work station is PC. I probably made about twenty subtle iterations for this match. I may be wrong but I think that the color readouts in ID are not the same as ACR/PS. Made matching the patches by the numbers a lot more difficult. There may also be slightly different methods in handling the color mapping that is resulting in slight differences in the color patches. Not as ideal as I would expect, and not much better than using ICC profiles for another raw converter either.
RT on the other hand is not handling DNG profiles properly. I'm not sure if it is also ignoring the LUTs in the profile, not enough time to test that. It may also be using 1 matrix table at a time.
I haven't had the time to process out a number of real world color images with ICC and DNG profiles to know which works better in practice.
Well, that's all for now, its past 2am here.
-
Wow!
Hope you had a good nights sleep by the time you read this...
Obviously you were tired... the TIF does not match your description.
Here is a screen shot of the layers:
Best regards - Hening
-
Thanks to the neatness of the layered doc, I was able to extract this into ColorThink Pro, take any of this as you wish <G>. I have the pixel files and color lists if anyone wants to play further in CTP.
(http://www.digitaldog.net/files/DNGvsICC.jpg)
ColorPatches vs. ACRwDNG_Custom:
--------------------------------------------------
dE Report
Number of Samples: 4320
Delta-E Formula dE2000
Overall - (4320 colors)
--------------------------------------------------
Average dE: 0.58
Max dE: 4.55
Min dE: 0.00
StdDev dE: 0.79
Best 90% - (3887 colors)
--------------------------------------------------
Average dE: 0.39
Max dE: 1.73
Min dE: 0.00
StdDev dE: 0.58
Worst 10% - (433 colors)
--------------------------------------------------
Average dE: 2.21
Max dE: 4.55
Min dE: 1.73
StdDev dE: 0.49
--------------------------------------------------
--------------------------------------------------
Color Patches vs. RtwArgyll_ICC:
--------------------------------------------------
dE Report
Number of Samples: 4320
Delta-E Formula dE2000
Overall - (4320 colors)
--------------------------------------------------
Average dE: 0.78
Max dE: 6.56
Min dE: 0.00
StdDev dE: 1.09
Best 90% - (3887 colors)
--------------------------------------------------
Average dE: 0.53
Max dE: 2.41
Min dE: 0.00
StdDev dE: 0.78
Worst 10% - (433 colors)
--------------------------------------------------
Average dE: 3.10
Max dE: 6.56
Min dE: 2.41
StdDev dE: 0.68
--------------------------------------------------
--------------------------------------------------
Color Patches vs. RtwDNG_Day:
--------------------------------------------------
dE Report
Number of Samples: 4320
Delta-E Formula dE2000
Overall - (4320 colors)
--------------------------------------------------
Average dE: 0.84
Max dE: 6.23
Min dE: 0.00
StdDev dE: 1.20
Best 90% - (3887 colors)
--------------------------------------------------
Average dE: 0.55
Max dE: 2.60
Min dE: 0.00
StdDev dE: 0.82
Worst 10% - (433 colors)
--------------------------------------------------
Average dE: 3.47
Max dE: 6.23
Min dE: 2.60
StdDev dE: 0.80
--------------------------------------------------
--------------------------------------------------
Color Patches vs. RtwDNG_Tung:
--------------------------------------------------
dE Report
Number of Samples: 4320
Delta-E Formula dE2000
Overall - (4320 colors)
--------------------------------------------------
Average dE: 0.84
Max dE: 6.23
Min dE: 0.00
StdDev dE: 1.20
Best 90% - (3887 colors)
--------------------------------------------------
Average dE: 0.55
Max dE: 2.60
Min dE: 0.00
StdDev dE: 0.82
Worst 10% - (433 colors)
--------------------------------------------------
Average dE: 3.47
Max dE: 6.23
Min dE: 2.60
StdDev dE: 0.80
--------------------------------------------------
--------------------------------------------------
Note: the Color Patches is synthetic (certainly very smooth), the other's are not so the numbers here could be quite different if more sampling or smoothing were done on the images. But I suspect if done correctly, we'd see the same differences with just lower values overall. Each color patch fed to CTP was 8x8.
-
One item that's interesting to view in CTP are the various color lists plotted 3D with vectors: the directions they follow differently compared to the Color Patches of which they are compared.
(http://www.digitaldog.net/files/Vectors.jpg)
-
Wow!
Hope you had a good nights sleep by the time you read this...
Obviously you were tired... the TIF does not match your description.
Here is a screen shot of the layers:
Best regards - Hening
Oops. Thanks Hening. I fixed the link now.
-
Thanks to the neatness of the layered doc, I was able to extract this into ColorThink Pro, take any of this as you wish <G>. I have the pixel files and color lists if anyone wants to play further in CTP.
...
Note: the Color Patches is synthetic (certainly very smooth), the other's are not so the numbers here could be quite different if more sampling or smoothing were done on the images. But I suspect if done correctly, we'd see the same differences with just lower values overall. Each color patch fed to CTP was 8x8.
Andrew, thank you very much for doing the comparisons in CTP. They are very helpful in visualizing the color differences. Could you pass me a copy of the pixel files and color lists? I'll send you a PM with my email.
Yeah, I could have done better to rotate the target to avoid glare from the sunlight. It would probably improve things a bit.
-
Writing this in response to solarj. DNG profiles can contain the following tables, but not profile building/editing software fill all table values.
1. CameraMatrix1
2. CameraMatrix1
3. ForwardMatrix1
4. ForwardMatrix2
If the raw converter follows the DNG spec in the way it handles DNG profiles, it will use the ForwardMatrix table values instead of the CameraMatrix table values. If the Forwardmatrix is not included (table values =0) then a rather convoluted method is used to map colors.
Some of my test result:
1. remove all the matrices --- dcp won't show up in the profile list
2. keep only CM1 --- dcp works
3. keep only FM1 --- dcp won't show up in the profile list
X-rite software generated profile contains CM1 and a LUT, by removing LUT and use ACR RGB primaries adjustment, I can achieve enough accuracy with a linear tone curve that you recommended, so currently I'm satisfied with this non-LUT approach for daylight shootings ranging from 5000K to 8000K
But I am still confused by a quesion: Do you need different matrices for different lighting? How is that calculated?
Take 3000K flourescent light for example, the light emission is very different than daylight. Under such a lighting, I can imagine that the color checker spectrum response will be very different, so standard D50 Lab value will not match. But since we do not have reference values for color checker under such a lighting, how could we calibrate it? Is there some hidden reference value inside profile making software when it make dual-illuminant profile? How could it tell it is a flourescent light or a incandescent light?
-
Andrew, thank you very much for doing the comparisons in CTP. They are very helpful in visualizing the color differences.
Should we make anything out of the dE values in terms of the lowest being a custom DNG profile?
2nd place appears to be a custom ICC profile? If so, can you comment on the ease of building both sets and if they are easily transportable to other raw converters that support them?
In the data I sent you, I did a version whereby I blurred the Macbeth's and the results are about the same in, obviously the dE values are different (less) but the order presented here is the same.
-
Is it OK to go on discussing ColorPerfect in this thread?
@ Samueljohnchia
> I also disagree wholly with the results I am getting from ColorPerfect's "scientifically correct" method of saturating images, and I find Joseph Holmes's color variants to be far superior in many ways, not just the visible results.
I don't understand what you mean by this. In my current workflow, I never touch the saturation sliders. Is there any need for it as long as you go for a "natural" saturation? How would you define a "natural" saturation after the color profile, white balance and tone values are in place?
In Davids texts, I could not find a place where he writes about saturation, so I assume, your objection is based on visual results rather than theoretical grounds.
@ solarj
> But I am still confused by a quesion: Do you need different matrices for different lighting? How is that calculated?
I think the ColorPerfect theory has an answer to this:
The camera is constant, it can be profiled in constant light with a gray scale alone. The illumination is changing from image to image - this is a job for the white balance, not the camera profile.
There is also another problem: Now you have profiled your camera, the image of the CC looks fine. But on a real world image, the next steps would be multiple (tone) edits done in ProPhoto or Lab. How accurate are colors after these edits? CP promises, via the "Alpha Feature", to restore "color integrity" after tone edits done in the carrier application (Photoshop or PhotoLine). I have not tested this yet though.
-
Some of my test result:
1. remove all the matrices --- dcp won't show up in the profile list
2. keep only CM1 --- dcp works
3. keep only FM1 --- dcp won't show up in the profile list
If you remove the CameraMatrix, it would no longer be a valid DCP profile...
But I am still confused by a quesion: Do you need different matrices for different lighting? How is that calculated?
Take 3000K flourescent light for example, the light emission is very different than daylight. Under such a lighting, I can imagine that the color checker spectrum response will be very different, so standard D50 Lab value will not match. But since we do not have reference values for color checker under such a lighting, how could we calibrate it? Is there some hidden reference value inside profile making software when it make dual-illuminant profile? How could it tell it is a flourescent light or a incandescent light?
The camera colors will be chromatically adapted to D50. The DNG PE and QPcalibration uses Bradford. I believe X-rite should too, but I have not been able to confirm. It "tells" by doing a white balance from the second lightest neutral patch and getting a CCT value. It will not know the lighting. If you choose "2850 K only" in the DNG PE, it will assume Std Illuminant A. If you choose "6500 K only", it will assume D65. The profile has the illuminant tags. QPcalibration uses only D50 should be tagged accordingly. I helped the engineer discover an illuminant tag error - it should be 23 (D50), not 21 (D65) in the profile. Not sure if they have updated QPcal yet.
The complex LUT's that you dislike will help deal with weird spectral behaviour that the matrices alone cannot tame on their own.
I also realised the wonderful advantages of the DNG PE using the same base matrices for all the profiles it produces, or "edits", if you prefer. It allows one to use the same white balance settings in ACR/Lightroom and switch between different profiles, and all the neutrals will remain neutral. A huge benefit! If the matrices were to change, then a great deal of conscious effort has to be made to ensure that a new proper WB is set, for every single profile change. This is a BIG issue. If unaware, a user might think that a particular profile has a color cast, when actually it is just a different CCT in the profile input reference.
-
Should we make anything out of the dE values in terms of the lowest being a custom DNG profile?
2nd place appears to be a custom ICC profile? If so, can you comment on the ease of building both sets and if they are easily transportable to other raw converters that support them?
In the data I sent you, I did a version whereby I blurred the Macbeth's and the results are about the same in, obviously the dE values are different (less) but the order presented here is the same.
Andrew, I'm not sure if I can adequately comment fairly on this matter.
The DNG profile that you ranked tops has not just the camera matrices but also a relatively high resolution LUT. The ICC profile is only a simple matrix profile, with a linear gamma tone curve. I would actually say that the ICC profile is better than a DNG profile with its LUT stripped off!
I'm not sure how a LUT ICC profile will behave. A few respected experts have warned to stay away from that if using a small patch target. It might be better, but it quite likely might be worse.
Creating a great ICC profile can be as easy as a DNG profile, if you have taken the time to set up your workflow with Argyll. I already posted the code that I used so anyone can just take it and punch it into a command line interface program, after downloading Argyll. You will also need another line of code to get Argyll to sample from the photo of the target and create a measurement file to build the profile from. The wonderful thing is that you can know what reference values Argyll uses, and modify that reference file to your own custom values. This is great if you have a good spectrophotometer and you use only one CC target for all your profiling. Otherwise averaged reference values like Danny Pascale's ones are fine. You can also create your own reference for a new target that Argyll does not have the reference file for. Unlimited control! If one is hindered by dealing with code, Raw Photo Processor has a GUI for camera profiling with Argyll. I haven't tested the consistency of Argyll's profile building process. The patch detection is automatic and so far my tests of other auto-detecting camera profiling software has shown it to be very consistent. That is, the profiles tend to end up almost exactly the same.
The DNG PE however, requires some manual user interaction by placing the control points on the corresponding color patches. It is very very sensitive. I have gotten errors like: "Non-neutral gray patches. The gray patch in row 4, column 3, has a significant color cast. Please re-shoot the chart carefully to avoid color casts and try again." Then a small shift of the control points and a perfect profile is produced, no errors. It is quite a weird one. It is always this particular gray patch that it thinks is different. Tried two different colorcheckers. Tried different kinds of lighting. When a non-neutral warning appears, always this patch is the problem. I've also gotten overexposure warnings when the actual values in the white patch are not clipped. Again slight tweak of the controls and perfect profile again.
One of the problems with ICC profiles in the beginning is that the white point of the profile would be too low, because the white patch in the target isn't exposed as pure white, and it shouldn't. Unnecessary loss of highlight headroom was one of Adobe's arguments for DNG profiles. No longer is that an issue with scaling the white point for an ICC profile. I've yet to test how well ID handles highlights with DNG vs ICC profiles, but I think it should be quite similar now.
I haven't seen a single illuminant DNG profile that can adequately map a CC's values when the CCT of the light, assuming it has smooth spectral transmission, is different by 3000k or more. That's why I made warm daylight profiles for sunrise and sunset. Regarding the ability of DNG profiles to be able to describe a wide variety of lighting, a dual illluminant profile has greater success, for the average untrained eye. If the temperature slider in ACR/Lightroom is set between 6500K and 2850K, as it often is required for pleasant rendering of white balance across a wide variety of scenes, the profile would be subtly wrong, because it must interpolate from both illuminant tables. A 5000K daylight shot of a CC ends up being slightly less accurate than a well made single illuminant profile. Likewise for a 3850K warm daylight CC photo.
I've had great success bringing over an ICC profile I made for ID into RT. It renders the CC values quite well - the evidence is in the second tif file I posted. Surprisingly, the DNG profile in RT was a disaster because I suspect that RT is not supporting the latest DNG spec properly. Nothing to do with the flexibility of the format here, or the fact that it was built from scene rendered data, not raw converted output data. Raw converter software engineers will have to keep up with the changing DNG specs.
-
The illumination is changing from image to image - this is a job for the white balance, not the camera profile.
Hening, white balance alone will not help in metamerism issues for illuminants with a spiky spectral output. The camera profile can have a role to play here. I do not yet have enough color science knowledge to understand or prove how a camera profile destroys "color integrity". I have seen evidence of bad color mapping, non-smooth profiles etc. I also have seen when camera profiles are fantastically wonderful for getting color relationships to where they should be.
Is it OK to go on discussing ColorPerfect in this thread?
@ Samueljohnchia
> I also disagree wholly with the results I am getting from ColorPerfect's "scientifically correct" method of saturating images, and I find Joseph Holmes's color variants to be far superior in many ways, not just the visible results.
I don't understand what you mean by this. In my current workflow, I never touch the saturation sliders. Is there any need for it as long as you go for a "natural" saturation? How would you define a "natural" saturation after the color profile, white balance and tone values are in place?
In Davids texts, I could not find a place where he writes about saturation, so I assume, your objection is based on visual results rather than theoretical grounds.
David's website is as convoluted as CP's UI. It is not surprising that you cannot find it. I spent considerable time reading his literature and getting lost in the site before this caught my attention. Here you go (http://www.c-f-systems.com/ColorPerfectHelp.html#saturation).
"This may be the first saturation adjustment to have a sound basis in physics and physiology and we believe the difference in purity of color will be obvious to most people."
I have no further comment except that I greatly dislike the way ColorPerfect saturates colors. Yellows are significantly saturated more than the other hues, the very same problem that the saturation slider in ACR/Lightroom or Photoshop has and I want to stay away from! Vibrancy has the exact problem with the opposite hue, blue. In contrast, Joe's color variants are simply brilliant. And most importantly, easily reversible. This is a major issue with ColorPerfect's workflow. This is personal preference, and since you don't touch that slider anyway, no problem!
I have the need to increase or decrease saturation quite often for my work. Increasing the gradient of the tone curve in ACR/LR by more than 1 results in a saturation increase. I might want to tune it down. I get robbed of saturation when I reduce the curve's gradient to less than one. Almost all the time you have both issues in a single curve, because steepening one end flattens another. Dealing with that is not so easy.
I don't know how I would define "natural saturation". Its like asking what is natural sharpness? We all will have a different tolerance for that. Show me two examples, I can pick one. Defining is just much harder. Editing to your mind's visualization in the end is far more important than attempting an exact match. I never expected or demanded exact color reproduction when I started making custom camera profiles. I wanted better relationship of colors to each other. I am convinced that I have that, more-or-less, with my carefully made profiles.
-
Creating a great ICC profile can be as easy as a DNG profile, if you have taken the time to set up your workflow with Argyll.
RawDigger 0.9.15 (RC1) can generate CGATS that you can feed to Argyll and it now can correct uneven target illumination
it is not yet public on rawdigger.com, but you can get it from the developer (code) blog (http://blog.lexa.ru/)
-
Hi
I asked Brian about the option 'Use embedded curves' in ID, and his answer evolved into a detailed article on the color processing pipeline in ID for ICC and DNG profiles respectively. He has authorized me to post it here. The zip is a digest of the e-mail exchange.
The item that caught my attention was that the zero point of the Shadow Fine Tune slider on the 'In' panel changes its meaning in case you use Adobe DNG Camera Profiles AND the embedded (or default Adobe DNG SDK) camera curve. In this case, you have to set the slider to +100 instead of 0 to get a linear curve.
Best regards - Hening.
-
He has authorized me to post it here. The zip is a digest of the e-mail exchange.
may be still post as a text to make it available for a search, even if that will 2-3 postings ? $0.02
-
I ask the moderators to hear their view.
-
I see no problem if the authors' permission was obtained.
-
but
"The message exceeds the maximum allowed length (20000 characters)."
-
but
"The message exceeds the maximum allowed length (20000 characters)."
that is why I suggested to split in 2-3 postings, based on the logical flow of the conversation there... not in one
-
Is it OK to go on discussing ColorPerfect in this thread?
Hening, I realised that I didn't explicitly say that I'm happy to discuss further about ColorPerfect in this thread. My statement that I have "no further comment" was not intended to shut off discussion, but rather because I didn't want to head into a massive war about which saturation tool is the best. We can certainly look further into CP and discuss about the way it preserves "color integrity"!
The item that caught my attention was that the zero point of the Shadow Fine Tune slider on the 'In' panel changes its meaning in case you use Adobe DNG Camera Profiles AND the embedded (or default Adobe DNG SDK) camera curve. In this case, you have to set the slider to +100 instead of 0 to get a linear curve.
Thank you for sharing this valuable information, and thanks to Brian who took the time and effort to craft his detailed reply. It certainly helps in the discovery of the behavior of sliders in these raw converters. With all due respect to Brian, his suggestions of how the shadows slider works do not agree with my usage. Leaving the shadows slider at 0, matches the Blacks slider of ACR/LR PV 2010 at 0. Not at +100.
I re-did some tests in ID again, with a custom white balance temperature of 5405, tint 13, (In Tab) TC Shadow - None, Highlight - None, and all other sliders zeroed and the Camera Curve linear (remove all points). I had Exposure set to +0.36 or -0.06, to get as close a match to the white patch's brightness as I could.
I tested my DNG profile with and without the embedded tone curve of the DNG profile, with Shadow Fine Tune at 0 and 100, and also one more where I tweaked the Camera Curve using an input of 199 to an output of 255, without the embeded tone curve. Take a look at the results and compare to the ACR version:
ACR Exp +0.06, all settings including blacks zeroed, tone curve linear
(http://dl.dropbox.com/u/15547362/acr_blackszero.jpg)
1. Exp +0.36, Shadow Fine Tune "0", Use Embedded Curve Unchecked
(http://dl.dropbox.com/u/15547362/WB-5405_13-Shadows-0-noembcurve-exp0.32.jpg)
2. Exp +0.36, Shadow Fine Tune "100", Use Embedded Curve Unchecked
(http://dl.dropbox.com/u/15547362/WB-5405_13-Shadows-100-noembcurve-exp0.32.jpg)
3. Exp -0.06, Shadow Fine Tune "0", Use Embedded Curve Checked
(http://dl.dropbox.com/u/15547362/WB-5405_13-Shadows-0-withembcurve-exp-0.06.jpg)
4. Exp -0.06, Shadow Fine Tune "100", Use Embedded Curve Checked
(http://dl.dropbox.com/u/15547362/WB-5405_13-Shadows-100-withembcurve-exp-0.06.jpg)
5. Exp 0, Shadow Fine Tune "0", Use Embedded Curve Unchecked, Camera Curve Input:199 Output: 255 This should be identical to 1.
(http://dl.dropbox.com/u/15547362/Shadows-0-noembcurve-exp0-camcurvein199out255.jpg)
My recommendations at this point would be to uncheck Use Camera Curve for DNG profiles, and to leave the Shadow Fine Tune slider at 0. Using exposure or the camera curve to set the white point for the target is essentially the same, except for when there is clipping, so we don't have to worry about that for color target photos - because you won't use one with clipped patches!
-
Here is a crop of a dark shadow region, showing the issue more clearly:
(http://dl.dropbox.com/u/15547362/acr_ID_shadowsettings.jpg)
-
Vladimirovich,
I feel that splitting the text on multiple posts would be circumnavigating a forum rule which I find well motivated. So I think I'll leave it with the zip. Thanks for your consideration of the searchability though.
Kind regards - Hening
-
RawDigger 0.9.15 (RC1) can generate CGATS that you can feed to Argyll and it now can correct uneven target illumination
it is not yet public on rawdigger.com, but you can get it from the developer (code) blog (http://blog.lexa.ru/)
You are jumping the gun a little here :) There is a couple of unfinished things in that code, no robust mean yet, and the operations for setting max and flat field normalization are better swapped.
-
This is why we need testing. I want to see the proof in all this. Who is right? Is what I am seeing all an illusion?
I've been trying to get Roger Cicala interested in quantitative measurements of sensor variability (as reflected in HSL adjustments for camera profiles from .dng's of test targets like the CCSG. He's the founder of LensRentals with 100's ... 1000's? ... of camera bodies ... writes blogs full of numbers and charts.
He seems interested to the extent of willing to work with someone with experience and expertise in this arcane specialty (which ain't me).
-
I've been trying to get Roger Cicala interested in quantitative measurements of sensor variability (as reflected in HSL adjustments for camera profiles from .dng's of test targets like the CCSG. He's the founder of LensRentals with 100's ... 1000's? ... of camera bodies ... writes blogs full of numbers and charts.
He seems interested to the extent of willing to work with someone with experience and expertise in this arcane specialty (which ain't me).
Allan, that's great. I've been closely following Roger and his lensrentals blog. Epic stuff. I would be interested to help, but I don't know any more about this stuff than the average guy. I don;t know how to read the source code for ArgyllCMS and tell you how Graeme Gill has chosen to build an input ICC profile for a given argument, and how or why other vendors do it differently and the potential issues of certain methods of dealing with the complex way color mapping is calculated. The Adobe method is secret, but X-rite and QPcard have found brilliant engineers to figure the math out.
Quantitative measurements of sensor variability is not hard with the right tools like a monochromator. This guy (http://photo.net/digital-darkroom-forum/00Y5JC#00Y5id) may have the expertise and tools to help.
I'm wondering what are we going to do then after proving that the spectral response of cameras do differ unit to unit.
-
Hening, what do you think of the results of my test with the various settings in Irident Developer? Have I misinterpreted Brian's comments on how settings work?
-
I'm wondering what are we going to do then after proving that the spectral response of cameras do differ unit to unit.
Several things come to mind ...
- Better info to judge whether camera profiles are worth doing for a particular model that was good vs average vs poor on sensor consistency. Is a "generic" likely to be "good enough"?
- If valid info came out that the top-of-the line NiCan D123 had a really consistent sensor, and the top CaNik 321D had a very inconsistent sensor, perhaps CaNik might "see the error of their ways" and respond to competitive pressure. Stranger things have happened.
- Like when concerns came out about iffy "follow focus" with an earlier Canon 1D#, they caught a lot of flak to improve. Or not?
- Or now that sensors from Sony are ahead in DSLR DR. Pressure on Canon (and I suppose Nikon also) to improve their sensors.
-
> Hening, what do you think of the results of my test with the various settings in Irident Developer? Have I misinterpreted Brian's comments on how settings work?
I have not thought, but tried to leave that to others who are more qualified :-) I have alerted Brian to your post, but he is about having a new baby (I hope this is not considered too indiscrete?) Tonight, I'll go through your settings again and compare them to the ID help text more closely than I have so far.
There have been a couple of new postings on the Shooting Color Targets thread which I feel belong more in THIS thread. Wonder if we should try to move them?
-
Well, my verbose interpretation of your findings would be:
1-Use of embedded DNG profile throws off colors, Embedded Curves checked or not
2-The Shadows Fine Tune Slider has no effect.
In your shots # 1...4, the 2 darkest patches have on my screen the same Lab readouts in the Mac DigitalColorMeter:
patch D5: 35,625/-0,266/-1,293 ; patch D6: 20,589/-1,027/-0,891
I'm afraid Brian has overlooked something, but he is on paternity leave the next 2 months or so, so we have to be patient...
-
Hi
I just got an e-mail from Brian with a long reply to the above comparison between ID and ACR/LR, and the go ahead to post it here. Like Vladimirovich, Brian prefers to have it posted directly, split up in several posts, and so be it. Below however a zip in addition for those who prefer that.
Kind regards - Hening.
From: Iridient Digital Tech Support <support@iridientdigital.com>
Date: 13. March 2013 20:37:03 GMT+01:00
[Comparing Iridient Developer and ACR/LR] part 1 of 3
I have no idea what Adobe really does in their software and how various versions of ACR/Lightroom may or may not match up with what they do in the DNG SDK. My quick tests with ACR version 6.7 and the Adobe 2010 process selected under the Camera Calibration tab seemed to show similar behavior with the DNG SDK and the "Blacks" slider adjustment found there, but I haven't done a real thorough investigation yet...
I read the notes on Shadows Fine Tune. Based on my quick tests this should be working as expected under the following circumstances.
1) When using "DNG Camera Profile..." options in Input Profile menu AND when the "Use embedded..." checkbox is checked on the Camera Curve pane the Shadows Fine Tune Slider will adjust the DNG SDKs exposure curves "shadows" variable which adjusts the contrast of the dark shadows region.
Where SFT = shadow fine tune control
Setting SFT to +100 in Iridient Developer will pass a value of 0 to the DNG SDK and lightens the dark shadows region compared to larger values.
Setting SFT to 0 in Iridient Developer will pass a value of 5 (the default used by DNG SDK v1.4 which also just happens to match up with the default "Blacks" slider available in ACR 6.7 when using the Adobe 2010 process under Camera Calibration pane. Not sure about other versions of ACR or Lightroom. Lightroom anyway seems to act differently when choosing the 2010 process and doesn't completely switch its controls at least not in my very brief investigation so far... the result here should be slightly darker shadows.
Setting SFT to -100 will pass a value of 20 and again this should go even darker with the shadow tones.
Old versions of ACR/Lightroom had a "Blacks" slider with a range of 0-100 and a default value of 5. This OLD control seems to act much like the "Shadows" variable available with the exposure curves in the DNG SDK v1.4. This is based on VERY quick visual tests of a couple images.
-
[Comparing Iridient Developer and ACR/LR] part 2 of 3
*** NOTE *** Lightroom 4 does not seem to behave like ACR in this regard, at least not ACR v6.7.
*** NOTE *** The latest Adobe "Blacks" slider seems to have zero (or little) relation to the "Blacks" slider in Lightroom 4 which now defaults to value of 0.
2) I have no idea what Adobe actually does in their software or how it may or may not match up with the DNG SDK's processing for the exposure curves and for that matter for DNG Camera Profiles in general. My guess is they behave somewhat similarly, but based on labeling of functions in the SDK , even very latest 1.4 release, some of the processing in DNG SDK would appear to be "out of date" with their most recent software and is labeled "ACR3". Sseems to act somewhat like old versions, my guess was the 2010 process, but this was just based on a couple quick tests with a couple images and the controls in ACR v6.7.
3) I believe (again based on just visual inspection of adjustments, no actual knowledge of their processing in ACR or Lightroom) that Adobe tends to use a curve function for their exposure adjustments. It may be possible to get a linear or close to linear "curve" with the right settings options, but this seems to have changed with various versions of ACR/Lightroom and I don't know what settings may or may not introduce non-linearities into the adjustment.
samueljohnchia was using Exposure adjustments in ACR/LR which could introduce non-linearities based on their use of curves for some of these adjustments and this could account for differences in the grayscale rendering.
In other words an Exposure adjustment of for example 0.66 in Iridient Developer may behave totally differently than an exposure adjustment of 0.66 in Adobe software.
4) If doing a comparison between programs, probably best to use DNG format files where black point, white point, baseline exposure, linearization curves and white balance are all documented and should match up between Iridient Developer and Adobe software.
With native camera manufacturer RAW formats could have some minor variations in default black/white/exposure levels that would throw off the default grayscale between programs...
-
[Comparing Iridient Developer and ACR/LR] part 3 of 3
NOTE however due to some differences with my handling of "baseline exposure", white point determination and black point determination and what Adobe ends up using for baseline exposure/white/black in their DNG conversions (and presumably in their software as well...) I have overrides for all of these values available in Iridient Developer. Using these overrides can allow for a better match between DNG conversions and use of camera manufacturer native RAW formats.
Adobe DNG conversion support for new cameras may come some time following new camera support being added to Iridient Developer. There is no way for me to accurately determine what Adobe may use for these values prior to them updating their DNG converter software so in some cases my defaults will not match up with theirs.
So if you are using DNG format to make comparisons between Iridient Developer and Adobe software AND you are using the DNG Camera Profile option AND using the DNG Camera Profiles embedded (or DNG SDK default) exposure/tone curve you also need to be sure that in Iridient Developer on the Camera Adv pane that the Baseline Exposure, Black Level and White Level are all set to "Default". This will use the values exactly as specified in the DNG file.
In most cases using the DNG file defaults is in fact the camera default, but not all....
5) When not using DNG Camera Profiles (using ICC profiles or DNG matrix color) or with the "Use embedded..." option unchecked in the Camera Curve pane then the Shadow Fine Tune adjustment should be set to 0 to give no change to shadow values as defined by the baseline exposure, white level, black level, camera tone curve and exposure adjustments in Iridient Developer.
Best regards,
Brian Griffith
Iridient Digital
-
[Comparing Iridient Developer and ACR/LR] part 2 of 3
I'm not sure of all the little details and ramifications but what I see is this: If I open a DNG with a custom DNG profile in LR 4 (yes, PV2012) and save everything, then open it in ID and set the profile for DNG Camera Profile (Use DNG Metadata), the differences in color and tone are rather subtle and I suspect to be expected. What am I missing?
-
Well, my verbose interpretation of your findings would be:
1-Use of embedded DNG profile throws off colors, Embedded Curves checked or not
2-The Shadows Fine Tune Slider has no effect.
In your shots # 1...4, the 2 darkest patches have on my screen the same Lab readouts in the Mac DigitalColorMeter:
patch D5: 35,625/-0,266/-1,293 ; patch D6: 20,589/-1,027/-0,891
Hening, what do you mean by the use of the embedded DNG profile throws off colors? As far as I know all camera profiles distort colors to a certain degree. Is that what you are referring to?
I disagree that the Shadows Fine Tune Slider has no effect. It does make a change in the shadow regions, both visibly and measurably with Photoshop's info readouts. I'm not sure why the Mac DigitalColorMeter is giving you the same readouts. There are definitely different in the gray patches you refer to.
I'll be looking closely at Brian's comments. Thanks for sharing the emails from Brian.
-
I'm not sure of all the little details and ramifications but what I see is this: If I open a DNG with a custom DNG profile in LR 4 (yes, PV2012) and save everything, then open it in ID and set the profile for DNG Camera Profile (Use DNG Metadata), the differences in color and tone are rather subtle and I suspect to be expected. What am I missing?
I'm not sure what you are missing Andrew, but then the subtlety between different raw converters handling of tone and color is not any less significant than the subtle differences between ICC and DNG profiles, which I may have put too fine a point on in previous posts. If there are differences, as per Brian's post, they should be minimized for comparisons. I'll need to look closer at ID again.
-
samueljohnchia was using Exposure adjustments in ACR/LR which could introduce non-linearities based on their use of curves for some of these adjustments and this could account for differences in the grayscale rendering.
I think that the exposure slider in ACR PV 2010/2003 is linear enough (http://translate.google.com/translate?u=http%3A%2F%2Fwww.guillermoluijk.com%2Farticle%2Facrps%2Findex.htm&langpair=es%7Cen&hl=EN&ie=UTF-8) for our comparison purposes. As long as there is no channel clipping.
-
Hi Samuel,
> what do you mean by the use of the embedded DNG profile throws off colors?
Your examples # 3 and 4 show a gross difference between actual and theoretical patch colors. These are the images with the embedded DNG curve checked.
> I disagree that the Shadows Fine Tune Slider has no effect. It does make a change in the shadow regions, both visibly and measurably with Photoshop's info readouts. I'm not sure why the Mac DigitalColorMeter is giving you the same readouts. There are definitely different in the gray patches you refer to.
Ooops! I measured the front (bottom-left) patches, thinking THESE were the actual patch colors! But I see now that they are the reference colors, since the rear (top-right) colors show in fact a difference. Sorry!
-
Well, my verbose interpretation of your findings would be:
1-Use of embedded DNG profile throws off colors, Embedded Curves checked or not
Your examples # 3 and 4 show a gross difference between actual and theoretical patch colors. These are the images with the embedded DNG curve checked.
Hi Hening, if I misunderstand you please correct me.
Examples #1, #2, #3,#4 and #5 all use the embedded DNG profile, the same one that I used for the ACR comparison.
Examples #3 and #4 has ID set to use the embedded tone curve in the DNG profile.
I think you did not mean that using the embedded DNG profile throws colors off, but checking the "Use embedded curve" checkbox under the Camera Curve tab in ID throws off the color patches. Patch luminosity seems to be affected to a greater degree than its hue and saturation.
Thanks for checking out the gray patches again!
-
> Examples #3 and #4 has ID set to use the embedded tone curve in the DNG profile.
> I think you did not mean that using the embedded DNG profile throws colors off, but checking the "Use embedded curve" checkbox under the Camera Curve tab in ID throws off the color patches.
It looks to me that I thought 'The profiles are in use only when checked'.
-
Hi
I am exploring ColorPerfect. Attached is a screen shot that shows the B1 orange field of the CC24, from left to right: 1-Bruce Lindblooms synthetic target for ProPhoto; 2-my shot of my CC24, processed with ColorPerfects MakeTiff as raw converter, displayed in Photoshop with the ColorPerfect plug-in; 3-the same shot, displayed in ACR CS5 with Adobe Standard camera profile, everything else zero. ProPhoto is the color space in ACR and PS.
The monitor is calibrated to 5800 Kelvin and L*.
As seen, 1 and 2 are relatively close to each other, ACR seems off - but it is the latter which is very close visually to the physical CC24 viewed under one of the same Solux lamps that was used for the shot, whereas the other 2 seem reddish.
What is going on?
Confused - Hening
-
Hi
I am exploring ColorPerfect. Attached is a screen shot that shows the B1 orange field of the CC24, from left to right: 1-Bruce Lindblooms synthetic target for ProPhoto; 2-my shot of my CC24, processed with ColorPerfects MakeTiff as raw converter, displayed in PhotoLine with the ColorPerfect plug-in; 3-the same shot, displayed in ACR CS5 with Adobe Standard camera profile, everything else zero. ProPhoto is the color space in ACR and PL.
The monitor is calibrated to 5800 Kelvin and L*.
As seen, 1 and 2 are relatively close to each other, ACR seems off - but it is the latter which is very close visually to the physical CC24 viewed under one of the same Solux lamps that was used for the shot, whereas the other 2 seem reddish.
What is going on?
Confused - Hening
My guess from photographing the same target with my 4700K Solux lamp and getting similar results is that you're seeing why the Solux wasn't designed as a photographic light but a print viewing light. I noticed my Pentax K100D kept getting an overall reddish amber bias which tended to saturate warm colors due to the halogen underpinnings of the Solux.
Combine that with DNG's color correction processes as being a bit on the light handed side adjusting for this red spectrum bias and the confusion should subside, hopefully. Just my observation, though. Sensors don't see the same way as our eyes on all colors some more than others.
I'm just so surprised how my old CC chart I've got next to my display still looks exactly as Lindbloom's synthetic patches you've posted even viewing under my daylight balanced T8 flotube desk lamp. It's uncanny.
And thanks for confirming your version of Adobe Standard behaves the same as mine for my Pentax which applies a consistent neutralization curve throughout the entire color table of an image which tends to lighten blues as evident in your CCchart rendering.
-
Hi Tim
thank you for your reply.
I'm afraid the Solux lamp is not the whole story: I failed to post that with the CC24 viewed in sunshine that patch looks largely the same (even though the direct side-by-side comparison was not possible; but the difference is so gross that I can remember it from my desktop to my porch).
It may look like the Adobe Standard profile is trying to anticipate a bleaching that will occur in print?
Maybe I should try to get me one of these uncanny T8 tubes? And use flash for shooting the target?
Also worth noting is that the difference is not present in the white/gray patches, neither visually nor by the numbers.
-
Hi Hening, I also have similar observations, although I think that the Adobe Standard profile renders the orange patch too greenish, and the ColorPerfect too reddish, in your example. I find Bruce's target to be quite close to viewing the actual CC in daylight.
Tim's comments are right on the ball regarding the lower saturation of most of the color patches with Adobe Standard. Adobe made some changes to the V2 profiles, one of which toned down the saturation of colors because users complained that the V1 profiles were too punchy. I'm not sure if the V4 profiles received any additional tweaks to the rendering of color. The neutral patches should all be nice and neutral if the WB is correctly set.
How do the other color patches compare?
-
Hi
Samuel, thank you, too, for your reply.
I have fiddlet a little more with this and have learned a thing or two.
1-The comparison to the physical chart is so inconsistent depending on viewing light that I dropped it. It was just the Adobe Profile that confused me.
2- I made a quick and dirty shot of the CC24 in daylight (16:15 h winter time, clear sunshine), with a custom white balance taken right before the shot, based on the second-whitest patch of the CC. When displayed on the monitor, WB as shot, the orange looked even more reddish than before. Then I had the bright idea of using only the blue-yellow balance of the as-shot-WB, and set the Tint to 0. And look! some difference! Thus inspired, I did the same to my Solux shot, and look, that improved, too, if not by that much.
What can I do to come even closer - flash?
Here is a comparison; left to right:
1-Synthetic, 2-Daylight Tint 0, 3-Solux Tint 0, 4-Solux Tint 0 5-Solux as shot.
In case you're interested to see the whole charts, here is a zip.
-
(even though the direct side-by-side comparison was not possible; but the difference is so gross that I can remember it from my desktop to my porch).
I'm not seeing such a "gross" difference between the first shot (exposed under the Solux) second from the Lindbloom's synth version.
In my case to check consistency I shot three (morning/noon/afternoon) 24 patch CCchart exposed under direct sunlight I used to build several DNG profiles processed with the DNG Profile Editor Wizard using ACR's default settings and (ACR 4.4) canned profile.
All three exhibited somewhat slightly different renderings in ACR under default settings. None were colorimetrically accurate according to the Lab numbers. I had to zero out contrast, black point, switch to Linear curve and adjust exposure to get the white patch to read 96L Lab readings to get near perfect Lab numbers on every patch.
Unfortunately the overall image looked like a machine took the shot because it was flat and dim looking, not the vibrant, crisp and full of life vision I saw under a sunny day. Also the noon shoot (brightest and most dull part of the day) made the second to the right white patch look sort of pinkish so when I clicked to establish R=G=B it suddenly made the overall image appear to look greenish yellow but got rid of the reddish saturated look of the gold patch I see in your shot while zeroing out all contrast inducing settings did most of the color correction.
Maybe I should try to get me one of these uncanny T8 tubes? And use flash for shooting the target?
That's a misunderstanding. I was making the point that the eyes are much more forgiving (adaptive) compared to how sensors record color under a wide range of neutral looking light sources. Sensors will pick up on odd spectra reflected off even the CC chart we don't even see.
Editing software was never designed to make photography an exacting color reproduction process though it is possible but requires work. The default settings along with ACR/LR's color engine were designed to somewhat emulate the behavior of film with regard to the relationship of contrast to saturation/hue changes, but in my experience it doesn't take a lot of work to get exacting numbers if that's the goal. It's just the overall look of the image will resemble what I've seen operating a graphics camera as a copy stand reproduction setup where the scene dynamic range has to match the output (i.e. reproduction of a painting viewed in a museum) which can be quite dim and flat by comparison to bright sunny day.
It may look like the Adobe Standard profile is trying to anticipate a bleaching that will occur in print?
I believe why that gold patch looks so yellow from applying the Adobe Standard profile may be due to hue twist that some have suspected and mentioned in the past. I get the same effect with a lot of sunset scene that push the saturation of golden colors caused by a custom DNG profile that tends to clip/flatten detail. I use it sometimes to bring out definition in upper mids to highlights shot under extreme lighting situations often delivering "desirable" results over accuracy. See the comparison below.
-
Hi
Samuel, thank you, too, for your reply.
I have fiddlet a little more with this and have learned a thing or two.
1-The comparison to the physical chart is so inconsistent depending on viewing light that I dropped it. It was just the Adobe Profile that confused me.
2- I made a quick and dirty shot of the CC24 in daylight (16:15 h winter time, clear sunshine), with a custom white balance taken right before the shot, based on the second-whitest patch of the CC. When displayed on the monitor, WB as shot, the orange looked even more reddish than before. Then I had the bright idea of using only the blue-yellow balance of the as-shot-WB, and set the Tint to 0. And look! some difference! Thus inspired, I did the same to my Solux shot, and look, that improved, too, if not by that much.
What can I do to come even closer - flash?
Here is a comparison; left to right:
1-Synthetic, 2-Daylight Tint 0, 3-Solux Tint 0, 4-Solux Tint 0 5-Solux as shot.
In case you're interested to see the whole charts, here is a zip.
I checked your "Solux As Shot" version agains the Lab numbers I have derived from actual measurements of real CCcharts and it shows you're WAY within specs. In fact you can be as far off as 5 numbers in any of L,a,b readings and still have it look accurate enough. In fact your blue patch is spot on, but your caucasian skin looks a bit on the pinkish side but still within "5" number specs with the Solux shot.
If you're seeing something that says differently then I suspect your calibration is way off. In fact I'ld like to know why your png screengrabs have "Display" as the name of the embedded profile when I open them in Photoshop CS3. Your custom display profile should be embedded or you should've converted to sRGB. Do you have a custom display profile?
What's up with that?
Here's my screengrab showing how close you are to the Lab numbers.
-
Here's a study you may find of interest on this subject:
"Space Of Spectral Sensitivity Function For Digital Color Cameras"... http://www.cis.rit.edu/~jxj1770/camSpec/
-
Hi Tim,
thank you so much for your extensive answer - I have something to study...
-
Hi Tim
> I'm not seeing such a "gross" difference between the first shot (exposed under the Solux) second from the Lindbloom's synth version.
No, the gross difference was between the screen image (non-Adobe) and the physical CC24.
> I had to zero out contrast, black point, switch to Linear curve and adjust exposure to get the white patch to read 96L Lab readings to get near perfect Lab numbers on every patch.
My ICC profile is linear in the first place.
> you're WAY within specs
That's good news, and I see the same as you do: see grab 1. So my custom display profile seems to do fine. (I did not check numbers myself, thinking that as long as I could see the difference with my bare eyes, it was to early to get into numbers)
> In fact I'ld like to know why your png screengrabs have "Display" as the name of the embedded profile when I open them in Photoshop CS3. Your custom display profile should be embedded or you should've converted to sRGB.
The png's were taken using the thumb button of my Logitech mouse. Converting to my custom monitor profile does not seem to improve color accuracy, see grab 2 - because the profile is applied 2 times on top of each other?
> Here's a study you may find of interest on this subject:
"Space Of Spectral Sensitivity Function For Digital Color Cameras"... http://www.cis.rit.edu/~jxj1770/camSpec/
> Thanks for that link! It looks interesting, but it's 03:45 (a.m.) in my part of the woods now, and study will have to wait a little.
Thanks again for your detailed posts! - Hening
-
Hi
Samuel, thank you, too, for your reply.
I have fiddlet a little more with this and have learned a thing or two.
1-The comparison to the physical chart is so inconsistent depending on viewing light that I dropped it. It was just the Adobe Profile that confused me.
2- I made a quick and dirty shot of the CC24 in daylight (16:15 h winter time, clear sunshine), with a custom white balance taken right before the shot, based on the second-whitest patch of the CC. When displayed on the monitor, WB as shot, the orange looked even more reddish than before. Then I had the bright idea of using only the blue-yellow balance of the as-shot-WB, and set the Tint to 0. And look! some difference! Thus inspired, I did the same to my Solux shot, and look, that improved, too, if not by that much.
What can I do to come even closer - flash?
Here is a comparison; left to right:
1-Synthetic, 2-Daylight Tint 0, 3-Solux Tint 0, 4-Solux Tint 0 5-Solux as shot.
In case you're interested to see the whole charts, here is a zip.
Hening, although zeroing the tint value has gotten you a closer match in the orange patch, your neutral patches are definitely not neutral anymore. "2-Daylight Tint 0" exhibits a very strange cyan tint in the white patch. A more optimal camera profile will help you get a good match of the color patches, while maintaining good neutrality in the neutral patches. I have demonstrated that this is possible with many of my earlier examples, both for DNG profiling as well as ICC profiling. I highly doubt that changing the light source is going to solve your issues. Lighting is not something we can always control, especially when photographing under natural/available light. We need to look at how the camera data is transformed also. Tim's link to that excellent article makes me hopeful that we will eventually have a better way to render color out of our cameras. Hopefully we all care enough to make it happen. Just look at how many folks were interested in this thread - not many by my reckoning. I think that many others are already happy with what they can achieve, or has developed some editing trick for a color handicap (I used to do that a lot), or are simply satisfied with what is possible with today's tools. Early on in the thread Stephen G said that he can already achieve good results with current tools already. There may not be enough market pressure to up the ante on good color mapping for average users. There are so many other issues that a photographer today has to grapple with.
-
> Converting to my custom monitor profile does not seem to improve color accuracy, see grab 2 - because the profile is applied 2 times on top of each other?
No! Because, it turns out, my custom profile was not in fact used by the monitor - the default profile was! Some software must have changed that under the table. OTOH, the profile seems quite good...but my own is a little better, the orange is visually closer to the synthetic target.
to samueljohnchia:
> Hening, although zeroing the tint value has gotten you a closer match in the orange patch, your neutral patches are definitely not neutral anymore. "2-Daylight Tint 0" exhibits a very strange cyan tint in the white patch. A more optimal camera profile will help you get a good match of the color patches, while maintaining good neutrality in the neutral patches.
Yes indeed to all of your post. -
And if Tim says that the orange is well within specs on the "Solux as shot", even my current camera profile doesn't seem too bad after all, because that one has near neutral grays all the way.
Maybe I'm ready to explore ColorPerfect now...David's theory may just be the turn of the century wrt color processing...
-
Hi Hening, I look forward to any new findings in your exploration of ColorPerfect. Feel free to add your discoveries to this thread. Unfortunately due to other work I cannot continue my investigation into this area at the moment. Additionally I have been turned off by several things that I have pointed out earlier. Iliah has also questioned David's statements in your other thread. Good luck!
P.S.
I have just received confirmation from Michael Ezra that Raw Therapee can work with dual table DNG camera profiles, but cannot interpolate between the two tables. It is as I suspected, resulting in the differences I reported earlier.
-
So here is my first step exploring ColorPerfect.
The ColorChecker was shot in Solux light with custom WB.
For ColorPerfect, the shot was processed with MakeTiff, opened in PhotoLine with ColorPerfect, Mode ColorPos, Perfect Raw checked. ProPhoto chosen as output space. The canned profile for the camera is automatically selected. There is no option for custom profiles at this time. The CC correction was left at the default..The color mode was left in RGB, because CP does not work with Lab (strangely, since the author states that Lab preserves what he calls Color Integrity).
In Iridient Developer, CA correction was enabled. Custom camera profile in, out and as working profile. The resulting TIF was opened in PhotoLine and converted to Lab.
In RawTherapee, CA correction was enabled. Custom camera profile in and out, ProPhoto as working profile (no choice of custom here). The Tif converted to Lab in PL.
For the screen shots, the monitor profile was: 5800K, WP 100 cd, BP 0.2 cd, gamma 1.8
Mesaurements: (with the DigitalColorMeter on my screen shots, RGB spreads disregarded/averaged)
Black patch: synth. 35, CP 34, ID 23, RT 26
White patch: synth. 238, CP 255, ID 236, RT 244
Middle Gray: synth. 101, CP 100, ID 93, RT 95
My view:
RT is somewhat pale overall. Both CP and RD seem close. CP seems "clearer", but in some cases (B1, B6, C5) clearer/brighter than the synth (!) - because it pushes the highlights? Because of this, I think my nod goes to ID.
This is my view with daylight in my room - I'll check tonight...
Next post: a real image.
-
2 oaks.
1- like above, except that the default CC correction resulted in an image with a gross blue-green cast, and was set to zero.
2- Since I still find the rendering too bluish, I tried to manually adjust the CC filter pack to visually match the ID rendering, more or less.
3-Iridient, like above. This is the closest match to my memory
4-RawTherapee, like above.
-
Thanks for sharing your results, Hening. Most of what you observe is similar to my own findings. I feel that CP tends to clip highlights a tad more with the "Black" adjustment (exposure, in the common tongue) at zero. It also has the tendency to render yellows brighter and more saturated, too much, IMO.
Do you find it more difficult to set the correct "white balance" in CP? I find it less intuitive than the conventional methods. And there is also one slider (green) that always resets to zero, with its offsets recalculated to visually equivalent red and blue offsets! Weird.
Hmm I'm surprised that your ID and RT results are this different with custom profiles. I think that they should be very close. Something could have gone wrong in the profiling process - perhaps the wrong settings in RT were used?
While the RT result looks worse in comparison, I also think that the ID results are a little unfair. The white point has been set too low, and correspondingly the black patch is too dark. The scale of 0-100 for Lab values are imprecise, so a two value difference (238 and 236) is represented with a greater difference in 8 bit notation, and even more in 16 bits. After correcting your ID screenshot for the white point, it seems to be the most accurate of the 3, colormetrically speaking. The darker patches are still a tad too dark - that may have something to do with the profile...one wouldn't want to loose precious shadow information/dynamic range to a profile with badly made curves at the shadow end! Your real world image of the tree shows the same shadow issue too. While we have wonderful shadow recovery tools to undo this effect, the adjustment curves may not be perfectly matched to perfectly eliminate the issue, or even worse, it might greater quantization errors than necessary.
I would suggest to stick in the ProPhoto RGB output space of the raw converters, and you might be interested in using Danny Pascale's averaged ProPhoto RGB target (http://www.babelcolor.com/main_level/ColorChecker.htm#ColorChecker_data) (slightly more representative than Bruce's statistically speaking, and also since Bruce was using GretagMacbeth's original values, which are different with the newly formulated versions of the CC). Assuming the color space conversions were in 16 bit precision or higher, converting to Lab for comparison is also ok. While I trust that you have an excellent display profile, that could also throw off, albeit slightly, the results that you posted here.
-
Hi Samuel
Thank you for your comments.
> perhaps the wrong settings in RT were used?
I think I used my camera profile as input profile. Below is a shot of the CC24 with a new RT profile, with No input profile selected, ProPhoto working and out. I looks indeed different - but by no means better! The first one looks like it could be cured by a little saturation boost, but this one... see below
> I also think that the ID results are a little unfair. The white point has been set too low, and correspondingly the black patch is too dark. The scale of 0-100 for Lab values are imprecise, so a two value difference (238 and 236) is represented with a greater difference in 8 bit notation, and even more in 16 bits.
Sorry I did not specify that: the figures I gave are 8-bit RGB, not L*. On my screen, the DigitalColorMeter readings of these 2 white patches are:
synth. (Lab): 239-238-234, ID: 236-237-234 - that's not much to be adjusted? I doubt that this little difference can account for the drop in the black patch from 35 to 23.
> I would suggest to stick in the ProPhoto RGB output space of the raw converters, and you might be interested in using Danny Pascale's averaged ProPhoto RGB target
Below are screen shots of
1-the Babel average 16 bit TIF in ProPhoto
2-the ID TIF, ProPhoto all the way
3-the RT TIF with new profile, in ProPhoto all the way
The CP image was in ProPhoto in the first place.
> display profile, that could also throw off, albeit slightly, the results that you posted here.
Of course. But the original TIFs would be 126 MB the piece, even as pngs they would still be 35 MB, whereas the screen shots are only 900 kB. And my focus was on the relative differences rather than absolute values. - The weak point of my current monitor profile are indeed the blacks, where the ColorNavigator profile has a ΔE of 4.0-3.3-1.7 for RGB 0-16-32, respectively. (average ΔE: 0.6).
Best regards - Hening.
-
Sorry I did not specify that: the figures I gave are 8-bit RGB, not L*.
Goodness, sorry! It was a foolish mistake on my part - obviously L* is usually represented on a scale of 0-100 and a value of 238 or 236 is immediately obvious that it is in standard 8 bit notation - and you did indicate so in your post!
On my screen, the DigitalColorMeter readings of these 2 white patches are:
synth. (Lab): 239-238-234, ID: 236-237-234 - that's not much to be adjusted? I doubt that this little difference can account for the drop in the black patch from 35 to 23.
I measured the readouts in Photoshop - you should get 242, 243, 237 in ProPhoto RGB from the Babelcolor average chart. So the ID values are too dark, and could be adjusted slightly brighter.
Interestingly, the new screenshot that you posted below shows no problems in the shadows - maybe something affecting the shadows/contrast in ID has been set back to zero but was not in your initial screenshot example? I think this is a far more pressing issue than any of the others, since you probably will stick to this workflow? One must be certain that the profile is not the cause of this issue...
I think I used my camera profile as input profile. Below is a shot of the CC24 with a new RT profile, with No input profile selected, ProPhoto working and out. I looks indeed different - but by no means better! The first one looks like it could be cured by a little saturation boost, but this one... see below
I was referring to the possibility that wrong settings were dialed into RT to produce a sub-optimal rendering of a CC image to be fed to the profiling software. Or perhaps the wrong settings were used to render the CC image with a custom camera profile? Yeah, the colors look pretty off. I presume that the "new" profile is "no input profile"? That would certainly result in a poor match to the synthetic CC. The custom profile route can give almost exactly the same look you get from ID, as long as you get the WB to match (and that requires different WB settings, a real pain) and also setting the white point correctly. Though if you aren't planning to switch to RT, this shouldn't bother you too much?
Below are screen shots of
1-the Babel average 16 bit TIF in ProPhoto
2-the ID TIF, ProPhoto all the way
3-the RT TIF with new profile, in ProPhoto all the way
The CP image was in ProPhoto in the first place.
> display profile, that could also throw off, albeit slightly, the results that you posted here.
Of course. But the original TIFs would be 126 MB the piece, even as pngs they would still be 35 MB, whereas the screen shots are only 900 kB. And my focus was on the relative differences rather than absolute values. - The weak point of my current monitor profile are indeed the blacks, where the ColorNavigator profile has a ΔE of 4.0-3.3-1.7 for RGB 0-16-32, respectively. (average ΔE: 0.6).
But at the end it is still a PNG screenshot that you provided, converted to your display profile, which is the (small) issue I raised. Saving out a downsampled PNG of the same pixel dimensions, but in ProPhoto RGB, instead of doing a screenshot is one possibility - I'm not requesting for those full size tiffs! :) No big deal though.
-
Hi Samuel
thank you for your detailed answer.
Yes the new input profile for RT was "no profile".
I have now prepared a new RT with custom camera profile input, and indeed, the look is very close to the others. To me, they look all great. CP may became even better if and when custom camera profiles will be supported. Or if I can use ID output with my custom proifle, but otherwise without CM (which should be possible).
I think will chose CP for now. One thing is the colors of a CC shot under controlled conditions, out of the box with no further edits; another question is what will happen to these colors when we apply curves. I remember discussions about hue shifts, I tried Tindemann's Tonability plug-in, but could not make it work. (Also, it's Windows...).
Of course, the differences may be small in real life, where tonal edits (mine) are usually moderate. But I prefer something that seems to be theoretically correct at the basis.
A problem will be to fit CP into a worflow with multiple stacking, since it requires completely unadultered raw files. This MAY become a show stoppper, at least in part. But that's another story.
Best regards - Hening.
Edit:
I see that the Babel is al off in the rendering here. I have seen the same with some images when opened in Preview. Opened in PhotoLine on my Mac it looks OK. ??
-
The problem with the Babel is solved: I had not assigned ProPhoto (PL does this automatically without dialog). Here is the profiled version. (I see no option to remove attachments).
Edit: no, it did not help. Then I don't know.
Edit: I'll try 'Convert' instead of 'Assign'
Edit: Nee, that didn't help either. Then I really don't know.
-
And here cometh what really sells me to CP: scanned roll film images as 3f files.
The film was Kodak Ektachrome Prof. Daylight 200 ISO 70 mm. The scans were done on an Imacon X5 by digitalcopy24.de.
The files are opened in PhotoLine without a profile. Assigning the scanner profile is no improvement, on the contrary.
1 and 3 are test charts shot in sunny mid-daylight, 4 and 5 is a scene in Swedish Lappland. For the latter, it is impossible (for me) to achieve anything trustworthy using color balance controls in PL.
CP pushes the highlights, but that could be handled.
Edit: Sorry, something has gone wrong with #1 and 3. I'll try to fix it and send them in a new post.
-
the message body requires text
-
And here is my best effort on this image, before sharpening. The exposure ('Black' in CP) adjusted to retrieve the highlights, the color balance adjusted guided by the original transparency. No tone curve.
For comparison: the default rendering in PhotoLine, with the scanner profile applied. (I was wrong, the scanner profile is not worse than the PL default, it is better, but no way near CP).
-
Related to this subject, on the Apple Colorsync list a discussion is going on after Ben Goren wrote an article on exposure, threadname:
"Primer on photographic exposure, etc."
Ben Goren's article:
http://trumpetpower.com/photos/Exposure
The thread is as interesting as the article.
--
Met vriendelijke groet, Ernst
http://www.pigment-print.com/spectralplots/spectrumviz_1.htm
December 2012, 500+ inkjet media white spectral plots.
-
Ben Goren's article:
Yeah, ya know, this guy is a jazz trumpeter with a lot of time on his hands (cause he doesn't blow his horn enough) and finds interesting ways of dissing Camera Raw...
Yeah I read it...kinda like Dan M. where first you need to make your image look like crap before magically fixing it in the end in Photoshop. (it's "magic").
One is better off learning the ins/outs of the hot new raw processor de jure (that you want to use) and actually set the optimal settings for your raw image...
Learn to make your images look the way you want them to look...regardless of what you have to do to get there! There is no magic bullet! There is skill and judgement involved...
-
Learn to make your images look the way you want them to look...regardless of what you have to do to get there! There is no magic bullet! There is skill and judgement involved...
It was not my intention to encourage further exercises into camera profiling but more to frighten the ones that would like to face that complexity. The linked thread adds to that. Within the limited scope of art reproduction it could work however and is more needed. I expressed my doubts on the general use in a similar thread before this one. So my thoughts are not that much different from yours but I expressed them otherwise :-)
--
Met vriendelijke groet, Ernst
http://www.pigment-print.com/spectralplots/spectrumviz_1.htm
December 2012, 500+ inkjet media white spectral plots.
-
There is no magic bullet!
but the sentiment of 99% of $99 (?) ColorChecker users is like - I can buy a cheap 24patch target, shoot it craplike in a daylight (sic), use PE (which Adobe itself is not using) and always get a "better" "color" right out of the box than when using Adobe's supplied profiles... just like that... placebo effect or snake oil...
-
Related to this subject, on the Apple Colorsync list a discussion is going on after Ben Goren wrote an article on exposure, threadname:
"Primer on photographic exposure, etc."
Ben Goren's article:
http://trumpetpower.com/photos/Exposure
The thread is as interesting as the article.
--
Hi Ernst,
thank you for this link, interesting reading indeed. Even though I don't quite understand: The first part sounds much like the ColorPerfect theory of just getting the grays right; but then he uses 600(+) color patches for a target.
Hening.
-
Hening,
There is even more added to the Colorsync thread like this link to a Wayne Bretl presentation file:
http://trumpetpower.com/files/trumpetpower.com/Wayne_Bretl_Theoretical_and_Practical_Limits_to_Wide_Color_Gamut.ppsx
I'm not even trying to understand all that, my intuition tells me that there is nothing to gain for me there. Swamp territory where scientists knit the loose ends with creativity and (I think) where artists shouldn't try to knit the grand unified theory of color management. My point of view that is older than this thread:
http://www.luminous-landscape.com/forum/index.php?topic=75235.15;wap2
--
Met vriendelijke groet, Ernst
http://www.pigment-print.com/spectralplots/spectrumviz_1.htm
December 2012, 500+ inkjet media white spectral plots.
-
Hi Ernst,
thanks for the new link as well, but I can not open it. - I have now subscribed to the ColorSync mailing list and will try to understand what little I can. I can not "knit the grand unified theory of color management", but I have to understand a little to be able to deconstruct the default renderings of various established implementations of color management. As a landscaper, I do not need the precision level required for art reproduction. But I want something that is BASICALLY accurate (natural) and not just pretty. And in all due modesty, I find that my efforts so far already give me images that are visibly closer to that goal than mentioned defaults.
Kind regards - Hening.
-
Thanks to everyone who has contributed to this thread and keeping the discussion alive and civil. I have learned a great deal along the way. I haven't found the time to read everything on the colorsync list and on the trumpetpower website but I will. I have briefly glanced through the powerpoint slides that Ernst has shared here and I now know that the on-landscape conclusions at the end of this post (http://www.luminous-landscape.com/forum/index.php?topic=75235.msg600456#msg600456) are misleading. I also learned that wider band pass filters contribute to an increase in color noise! Very interesting!
At this point I'm pretty convinced that getting accurate colorimetric color out of the camera by using photographs of color targets will never happen. It may be an improvement, as Hening and myself have found, by giving us a different (and to our minds, better) starting point. However, many tools in the raw converters that we use thereafter, throw wrenches into the mix of color, which distort, compress and expand color in other ways as we tweak our images to what we like. At the end of the day, it ain't as "accurate" as we had hoped it would be.
What is very interesting, to me at least, is the work by Jun Jiang, Dengyu Liu, Jinwei Gu and Sabine Süsstrunk that Tim has graciously shared earlier in this thread (http://www.luminous-landscape.com/forum/index.php?topic=75480.msg616867#msg616867). Their experiments show that it is possible to come very close to recovering the spectral sensitivities of camera sensors, and they show examples of image correction as well. Certainly it is entirely possible to achieve nearly the same visual results with good knowledge of the available tools, a good eye for color and good aesthetic judgement.
At this point I would not yet abandon camera profiling altogether. Again, as Hening and I have found, we like this new starting point for editing images. I have also noted that I needed less intervention into localized zones of color to fix any problematic hues. The LUT tables in DNG profiles do tweak color in a rather detailed manner, that sliders can't. Since DNG profiles made with the DNG PE still use the same camera matrices as the original Adobe Standard profiles, and they provide a different "flavor" by tweaking the LUT tables, and I have less issues with my custom versions, I'll stick with them for now until something better shows up. But I'll stop calling this process more "accurate".
-
samueljohnchia, I believe that exact matching of each color patch is possible, but first we must look at most fundamental elements in color information record and conversion, without blend in tone curve, LUT and such kind of after processing
In my understanding, if lighting is D65 and tone curve is linear, a calibrated camera color checker shot will always show the exactly number as reference value, if the sensor is enough good
Last time I discovered that DNGPE don't change the matrix, and I don't like LUT (it will make large area of gradualy changed color unnatural), if a good sensor act very close to human eye's cone spectral response, a single matrix should fix all the matching point on the gamut. In reality the sensor can not be perfect, so some kind of error has to be tolerated, but anyway without a LUT most of the transfer between colors will be gradual and natural
My past experience showed that if the sensor have a high quality, with a very good matrix, you can almost get all the color patches correct: Blue/Green/Red patch can be fixed 100% accurate, and the rest of them might have some error, and you adjust the matrix to reduce the error on other patches and increase the error on B/G/R patch until all of them fall into similar error level
I just picked up the CC24 and did some further testing. To my surprise, under a noon sunlight and 360 degree blue sky at northern europe (Standard definition of D65), the color temp indicated by camera shows 5800K, and the CC shot in ACR get a white balance of 5500K if I pick the second grey patch to do a white balance
So I get some difficulty: It seems that the daylight (sunlight + bluesky) is far from Illuminate D65, it is possible that D65 is a mixture of shadow (9000K) and direct sunlight (5000K), so I can not get a D65 lighting casted on the color checker. Maybe it is still May, I will try it in mid-summer to see if there are some difference, but since the sunlight is already very strong, I doubt even in June it will not be 6500K, maximum 5900K
-
I just did a test, I opened a raw file, applied two different camera profile (one is only matrix and another one is same matrix + HSD table) and save them as different dng file. Then I opened each of these dng files in xrite software and generated two dcp camera profile
The generated camera profiles have different matrix and HSD table
I then tried another test, applied same camera profile, but different tone curve in ACR and save as different DNG file, then open each of them and use xrite software to generate two dcp camera profile
This time the generated dcp camera profiles are identical
So it becomes a loop, with a camera profile in dng file at the first place, you won't be able to generate an accurate camera profile since the result is depend on the existing camera profile in dng file
And add to these confusing, I discovered that switching the camera profile will affect the "as shot" white balance reading, so I suppose that white balance data is also closely related to the matrix in camera profile, but how is that calculated?
I used to work with SIGMA X3F raw files, with that file, if white balance and matrix data are fixed, all the value will be fixed, crystal clear. It seems with ACR there are many layers of processing, this makes a reliable reproduce of a certain color very difficult ???
-
Well the discussions on that subject in other forums did not dampen down either, it may be interesting to see the latest entries in the Colorsync forum thread: Colorimetric Accuracy in the Field. Some would rather bury both ICC and RAW development CM together.
http://prod.lists.apple.com/archives/colorsync-users/2013/Jun/msg00067.html
--
Met vriendelijke groet, Ernst
http://www.pigment-print.com/spectralplots/spectrumviz_1.htm
December 2012, 500+ inkjet media white spectral plots.
-
Did anyone see this:?
http://chromasoft.blogspot.no/2009/02/visualizing-dng-camera-profiles-part-1.html
(http://3.bp.blogspot.com/_T48rP_mrFwY/SZwYlewjv-I/AAAAAAAAAL4/uj3PbP9d-bw/s1600-h/AllColors.jpg)
I think it might be interesting to visualize the Adobe default, manufacturer and my own profiles for my camera in this manner, tracing a few "colors". I suspect that the largest spread is going to be in the reds, meaning that they "disagree" on how red should be interpreted.
-h
-
Did anyone see this:?
http://chromasoft.blogspot.no/2009/02/visualizing-dng-camera-profiles-part-1.html
(http://3.bp.blogspot.com/_T48rP_mrFwY/SZwYlewjv-I/AAAAAAAAAL4/uj3PbP9d-bw/s1600-h/AllColors.jpg)
I think it might be interesting to visualize the Adobe default, manufacturer and my own profiles for my camera in this manner, tracing a few "colors". I suspect that the largest spread is going to be in the reds, meaning that they "disagree" on how red should be interpreted.
-h
Yes, read that some time ago, an interesting view, not scientific anyway
As my above post discovered, the dng camera profile itself is not the original data stored in RAW file, different camera manufacturer hide the most critical data like whitebalance gain and colorconversion matrix inside their proprietary RAW format, Adobe only get to access part of that data, so all the color matching at ACR level is dependant on the critical data inside the RAW file
This indicated that even if you can get very accurate color in one of the RAW file, it is not a guarantee that you will get same good color for another RAW file with the same camera profile, because some of the data (for example white balance gain) in RAW file changed between shooting. To have consistant result, you must be able to fix those critical data in camera raw file, and a typical practice is always shoot the photo with same custom white balance
-
Yes, read that some time ago, an interesting view, not scientific anyway
As my above post discovered, the dng camera profile itself is not the original data stored in RAW file, different camera manufacturer hide the most critical data like whitebalance gain and colorconversion matrix inside their proprietary RAW format, Adobe only get to access part of that data, so all the color matching at ACR level is dependant on the critical data inside the RAW file
This indicated that even if you can get very accurate color in one of the RAW file, it is not a guarantee that you will get same good color for another RAW file with the same camera profile, because some of the data (for example white balance gain) in RAW file changed between shooting. To have consistant result, you must be able to fix those critical data in camera raw file, and a typical practice is always shoot the photo with same custom white balance
Not sure that I quite follow.
I never touch the WB of my camera (default AWB), and I was under the impression that Lightroom did not read it either? I usually have to fiddle with WB in images that I care about.
I dont think that it is a goal for Lightroom to look exactly like Canons interpretation. I would rather that color response was equalized between Canon and Nikon image in my library to satisfy some "neutral" definition. After that, I'll be applying my own subjective editing.
-h
-
I found that people can still use dcraw to decode the raw files, I will give it a try. Now that many camera profiles have a large look up table to manually adjust the behavior of each individual color zone, all the color becomes artificial
-
Not sure that I quite follow.
I never touch the WB of my camera (default AWB), and I was under the impression that Lightroom did not read it either? I usually have to fiddle with WB in images that I care about.
I dont think that it is a goal for Lightroom to look exactly like Canons interpretation. I would rather that color response was equalized between Canon and Nikon image in my library to satisfy some "neutral" definition. After that, I'll be applying my own subjective editing.
-h
The strange thing is, even with AWB, the white balance value in ACR changes if you switch to another camera profile, and we all know that if white blance value changed, the color performance will also change. By definition, white balance is the gain for each RGB channel, should be constant for each individual RAW file
-
Only the "as shot" WB gain (scale factors) are a constant for a given image, as these were pre-determined by the camera and stored in the metadata. In practice users can (and will) change the WB setting (hence the scale factors) to whatever they want for a given image. DNG camera profiles will map the colors based on what this (possibly user-modified) WB setting is.
-
Only the "as shot" WB gain (scale factors) are a constant for a given image, as these were pre-determined by the camera and stored in the metadata. In practice users can (and will) change the WB setting (hence the scale factors) to whatever they want for a given image. DNG camera profiles will map the colors based on what this (possibly user-modified) WB setting is.
Even if you always select "as shot" WB, when you apply another camera profile (other than Adobe provided ones), that temperature and tint value still change, this is the most confusing part of ACR
I just ran dcraw for my nex-5r raw file
-----------------------------------------------------
D:\photo\5R\2013\06>dcraw -i -v DSC00425.ARW
Filename: DSC00425.ARW
Timestamp: Mon Jun 10 17:28:53 2013
Camera: SONY NEX-5R
ISO speed: 200
Shutter: 1/640.0 sec
Aperture: f/4.5
Focal length: 27.0 mm
Embedded ICC profile: no
Number of raw images: 1
Thumb size: 1616 x 1080
Full size: 4928 x 3276
Image size: 4928 x 3276
Output size: 4928 x 3276
Raw colors: 3
Filter pattern: RGGBRGGBRGGBRGGB
Daylight multipliers: 2.614211 0.926724 1.255255
Camera multipliers: 2984.000000 1024.000000 1472.000000 1024.000000
Since I always shoot with a fixed custom WB, the Camera multipliers never changes between different shots, but the read out on temperature and tint value in ACR still changes if I apply different camera profiles, so I guess the temperature and tint value is matrix dependant, not calculated from the original camera multipliers
-
That depends on how you've set the white balance settings.
What you're referring to is the As Shot white balance setting, which is the default. This simply uses the WB values as recorded originally by the camera and written into the raw file. WB in this case is recorded as a set of gain factors (or equivalently, "camera neutral" values). The translation between these neutral/gain values and white points (or temperature and tint slider values, which is what you see in the UI) is dependent on the camera profile (color matrix values). So when you switch between different camera profiles, the translation between the camera-recorded gain values and user-visible temperature/tint values can change, and this is expected behavior. When switching between Adobe-provided profiles (e.g., Adobe Standard and Camera Standard) for a given camera, you generally don't see these values change because we use the same ColorMatrix tags for all the profiles of a given camera model.
When you set a custom white balance setting (e.g., Daylight from the popup, or set your own temp/tint slider values) then ACR applies white balance using your chosen white point, not by using the camera-recorded neutral/gain values. Therefore the temp/tint slider values remain the same regardless of which camera profile you choose.