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.
Disabling WB and choosing an abstract profile provides a much more workable image. It is a slight shame to lose WB functionality, although there are other methods to achieve similar WB changes (albeit losing things like the WB picker).
In such case I agree. think we can consider it a bad linear DNG since looks like it’s forcing the use of the LinearizationTable for other purposes than the original ones (http://www.barrypearson.co.uk/articles/dng/specification.htm#linearizationtable).
It has 16 bit input channels mapped to 16 bit output channels. So the table is not used for converting from e.g. 8bit to 16bit linear but to apply a sort of gamma conversion.
For the DNG of this thread it’ll let users to at least see it correctly when using its provided matrix and let you play with the whitebalance without changing profiles and disable white balance.
Actually setting it to auto temp correlated or to daylight weren’t too bad…as long as it was not camera which seems to be the default…although turning it off looked the best to me for that image. maybe the same trick as mentioned above ie setting all the coefficients to 1 might also work and then you can tint and temperature from there…I haven’t tried further to know . In an case looks like you have some option now
Given the whitepoint in that file, I suspect if you set the color temp to 5000K, you’d wind up with multipliers of 1,1,1. I’m not at a location I can test this at the moment.
Normally a whitepoint of 5000k doesn’t result in such multipliers, but in this case, the DNG has had whitebalance prescaling done, but at least indicated so with a matrix that has an adjusted whitepoint.
The problem here is that adjusting WB for a dual-illuminant profile, or even providing your own camera profile for that matter, is no longer possible because ON1 mangled it into pseudo-sRGB with a D50 white point.
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.