Since I was digging in RT dcraw.cc code for another RT pull request I tried to take a look at this.
The image is a linear dng with 16bit rgb (65536). The dcraw.cc linear_table function limits the parsing to 4096 values. So the linearization isn’t done for values greater than 4096 and you get exploded highlights.
I Don’t know if it’s a typo (just a missing ending 0 since the array is already defined to contain 65536 entries) but I extended the limit to 0x10000 instead of 0x1000 and I get a better image.
It’s just more exposed and more reddish, I think it’s related to the strange single ColorMatrix1 (probably on1 v2 is doing some more adjustments or there’s something else missing in RT).
Many thanks for looking at this and producing a fix so quickly. I have to say I am impressed with RT as a piece of software, but also the helpful community around it
Regarding the more reddish on1 v2 image looks like a different default white balance. If I use the same white balance of the on1 v1 image (and increare the v1 exposure) they looks the same (with more sharpening introduced in the dng by on1 v2). I’ll take a look also at this.
I don’t think you can connect RT and ON1 in a particularly seamless way. You can invoke ON1 as an external editor in RT. If you do this RT converts the file to TIFF and then passes this to ON1. ON1 can work on this TIFF file and save it (as TIFF or DNG). However, it doesn’t automatically pass control back to RT. You then have 2 files available in RT - the original raw and the denoised TIFF. I think there is better integration with Lightroom or Capture1 through plugins. The ON1 documentation doesn’t specifically mention RT, but does say that if using Lightroom without the plugin and instead use ‘Edit In’ the process appears similar to that described above with RT.
The ON1 documentation also describes an automated way of passing images between Photoshop and NoNoise, but also recommends that for optimum results you invoke NoNoise in standalone mode and work on the Raw file, saving as DNG, before opening this file in Photoshop.
In general, ON1 recommend you denoise Raw files rather than TIFF ones for best results.
It’s not quite sRGB, but it’s pretty close other than the whitepoint being way off from sRGB
So the v2 outputs are a quite restricted gamut. Since it’s using the LinearizationTable it has no way to represent out-of-gamut colors with negative numbers.
That’s pretty close. Rec709 and this DNG (Edit: Previously said rec2020 which was REALLY WRONG - what a typo!) have nearly the same primaries. I’m guessing that under the hood the DNG linearizationTable is still used despite declaring it “linear”, unless that LinearizationTable is, itself, linear, in which case my thoughts are “WTF?”
The closest match to the primaries appears to be NTSC, but again - not quite, and it has a whitepoint of D50.
I would consider this a significant regression in behavior for the “new” ON1 behavior - it’s now gamut restricted to approximately the sRGB gamut. Not sure if ON1 has any options to disable this undesirable behavior.
I wonder if the result would be any different if the file was opened in ON1 and not using one of their profiles…they have a linear option which is what I use to avoid their color profiles??
I would think this would be the best way to do it anyway if you are passing along to RT for further editing??
I did some experimenting as I have ON1…so if you load your image in RT and turn off the WB module and set the abstract profile to linear…you will get a nice looking image…this is easy to implement and no patch need be used…at least for now
It should be a linear DNG (the linearization table, as the defined in the DNG spec, is used to make the data linear as the base data has been “reduced” to improve file size compression) so there should be no notion of color space but the use of color matrix(es) as input color profile.
The strange thing is that it provides only ColorMatrix1 with an unknown CalibrationIlluminant and there’s no AsShotNeutral tag so RT can’t know the camera suggested white balance.
Instead the on1 v1 version has the two typical ColorMatrix1/2 tags, standard CalibrationIlluminant1/2 and AsShotNeutral tag.
I think that RT should be made able to handle it without any user workaround and the linear_table patch is a step in that direction.
Now I’m not sure how to detect the camera white balance as looks like it isn’t provided by any known standard tag (I’m not sure how other closed source softwares handle this kind of dng).
From what I saw the WB is somehow messed up for sure…in both DT and RT the best result was to turn it off… So maybe in RT as this is your tool… Turn it off, add the linear abstract profile and then you have a pretty good start. Now maybe you can use the vectorscope and if you need to tweak wb do it with curves???
It looks like ON1 is nuking any white balance metadata - and in fact is also performing white balance internally, since the white point of the colorspace defined by ColorMatrix1 is consistent with D50 - which no real camera has as the camera-native whitepoint. Is there a setting in the ON1 version that generates these “new” DNGs to perform white balance?
They’ve basically done white balance prescaling and some sort of gamut transform into what is an approximation of sRGB with an altered whitepoint. (Normal sRGB has a D65 whitepoint, this has a D50 whitepoint and slightly altered primaries too.)
Looks the same to me. So this isn’t the “original” (after demosaic+denoise+sharpen) linear data anymore. i.e. If you try to use an adobe DCP camera profile for the camera everything is messed up.
I’m also curious if this is the default behavior, or the user just generated a dng of an already worked file. The on1 v1 behavior look like a standard demosaic+denoise+sharpen like other softwares like DxoPureRaw do and I think that this should also be a default available also for v2.
Based on the discussion, I suspect someone at ON1 messed up. sRGB is also a spaghetti western to mix a few puns. No two sRGB profiles are the same. Best to avoid them in intermediary files. Thus,
RT maybe shouldn’t be made to do anything to cater to this special breed of DNG.
In the meantime, @priort says he has ON1. Perhaps he could tell us more about it and the types of DNGs it could produce. Perhaps @JamesMorgan could find a way to make them play nice.
PS - another option is to reach out to ON1. I don’t know how open they would be about their software…
I can’t see any way to tweak things in ON1 but I think it would be a bug…
I am not at the pc with that on it now but I guess I could export a DNG with and without NoNoise to see if that is handled the same or they are different…
For now using the abstract profile in RT seems to do the trick…set it to linear and turn off WB and you get a pretty good image…
I have to admit that I’m not that technical and some of the discussions around color matrices and linear profiles are beyond my knowledge. I can’t see any way in NoNoise to control the format of the DNG files produced. The behaviour seen is the same for all raw files that I process in the new version of NoNoise.
For info, I have updated my original support request with ON1 to point them at this discussion and have asked them to review the content to determine whether any changes to NoNoise DNGs formats are merited.
Technically, it isn’t sRGB since it’s not calling sRGB out by reference - but sRGB is one of the close(r) matches available. Primaries are closer to NTSC (!!!), but no “semi-standard” colorspace with similar primaries has a D50 whitepoint. You can, in theory, choose any arbitrary colorspace you want for a DNG, just like you can assign an arbitrary colorspace to a JPEG or TIFF file using an ICC profile. That said, the colorspace described by that matrix is quite unusual. It’s at least not as weird as the Xphase X2/S2 pipeline… JPEGs are baked in white balance (common for JPEG, but not common for it to be hardcoded in the camera) and very unusual primaries (I can’t see any engineering justification for them), and their DNGs also bake in white balance (bad!)
In general, if saving a DNG, exporting it in such a constrained gamut with the anticipation of further processing is a bad idea. Similarly, “baking in” white balance is a bad idea.
I should have scare-quoted everything. My point is there is a lot of confusion in this area (partly because the ICC folks didn’t define sRGB profiles that well in the first place). This is compounded when we are dealing with container type files, e.g., DNG or ACES.
My point is there is a lot of confusion in this area (partly because the ICC folks didn’t define sRGB profiles that well in the first place). This is compounded when we are dealing with container type files, e.g., DNG or ACES.