I’m working on a project that involves creating .DNG files. I’m trying to figure out how to put the right tags into the .DNG so that when viewers open it, a 1.0 gamma curve is applied. Currently, viewers seem to auto-apply a 2.4 gamma curve. I’ve found that using RawTherapee I can change the “Working Profile” setting to “sRGB” which unlocks the “Gamma” control, letting me change it from 2.4 to 1.0. Is there anything I can put into the EXIF data to do this automatically?
Welcome @searlie
I assume, as you speak of viewesr and not of raw decoders, that your .DNG file contains a non raw file with data linearly encoded with sRGB primaries. There is no ICC profile embedded.
If it is true, then in rawtherapee:
use in “color management/input profile” “no profile” thus, no input profile is applied to data
use as working profile sRGB with TRC=no. As it is a linear working space, it will be ok
don’t forget your display profile if it is profiled
If happy, save your settings in a pp3. and apply this pp3 to all your images within the RT file browser.
An other solution would be to embed (with exiftool for instance) a linear sRGB ICC profile in your images. I am not really able to help here.
If you include an ICC profile, all color managed viewers should be able to correctly display your data. With no ICC, they assume that the data are coded in SRGB with gamma=2.2.
If you need more help from more knowledgeable people, an exemple DNG would be helpful.
I have the Adobe DNG codec installed on my Win10 machine; this has allowed my DNGs to be viewable in built-in photo utilities (could be a separate issue, as I’ve read elsewhere that Win10 should natively display DNGs). Here’s how the DNG is displayed in Windows Photo Viewer:
Your DNG pixels values are linear (ie they are proportional to the light received, more or less).
DNG viewers assume the data is linear.
If your monitor is non-linear, eg sRGB, a viewer will apply the appropriate transfer curve to display the image. If you don’t want that, you have to tell the viewer software not to do it.
A possibility would be to apply the inverse transfer curve to your DNG data. If the viewer applies a power(1/2.4) curve, then you would hack your DNG pixels with a power(2.4) curve.
Err, no. That will mess up all the colours as all the coefficients stored inside the DNG have been painstakingly calibrated for the linear raw data it carries.
As you pointed out correctly though, it’s not the purpose of the DNG to specify and worry about any output device and/or intent, so this must be done through the client app presets.
True, thanks, I had forgotten that. It’s still possible, in theory, I think. Do the fowards transformations from the coeffs, do the inverse transfer curve, then reverse the transformations from the coeffs. Basically, do whatever is needed to the raw data so that when it is processed all the way to output-referred, it is actualy linear.
Possible, but not sensible.
Embedding a sRGB profile in the PNG might prevent viewers from assuming the PNG data is linear, so that might work as well. But also not sensible.
@searlie I am curious to what your workflow is. You get DNG’s from your camera, I assume? You want to process them in RawTherapee (for some reason) and then export them as a filmstrip (to TIFF or PNG?) and them import them in Resolve? And you want to make sure that the thing you output from RT is imported properly in Resolve?
For that last thing: make sure you have selected the proper color space and gamma for your input clip in your media pool:
@Thanatomanic Yes, I get DNGs from the camera. It’s a video camera so it’s a DNG sequence and the workflow is moreso to go into an editor like Resolve or SCRATCH. The video camera is ‘unique’ and not like a typical video/cine camera, more like a scientific camera, and it’s advantageous to be able to apply advanced curves in Resolve starting from the basic linear data rather than after a 2.4 gamma has been baked in from the start.
I’ve just been experimenting with photo viewers as well and RawTherapee, being more advanced, has shown it’s possible to disable the application of gamma correction on displaying the images, whereas basic viewers I can’t really do this.
So, i’m stuck trying to find out what flags I could be changing in the DNG files to tell these various programs to “show it in linear” without requiring extra steps.
I can get to the point i want in Resolve with the steps shown above, i just dont want to have to do that each time a clip is imported.
So the DNGs you get out of your camera are linear. Why not simply set the clip’s color space in Resolve to Linear then? If necessary, use a colour node with the Color Space Transform option to change the gamma or primaries. The workflow of Resolve is non-destructive, so you shouldn’t loose color information in that way.
Unless you have a specific reason to use RawTherapee… I wouldn’t jump through those hoops.
That’s what I’ve figured I need to do so far, but just hoped there might be something else I could be putting into the DNG flags to prevent requiring that step. Ideally, other DNG decoders would key off the same tags (ie. RT). So, if anyone knows if such a capability exists, I’d be happy to hear it.
It wouldn’t help as far as I know. Resolve has very limited (or any) methods to determine what kind of data and encoding the clips in the media pool hold. The default is to interpret the clips in the same way as whatever color space and gamma you set your timeline to. If that doesn’t match, you need to set it yourself, which only takes a second or two.
I’m not professional colorist though, and I don’t know if anyone here has more experience. But maybe you should add “Resolve” as a tag to your first post?
Hi Searlie,
Are you sure that you have linear values stored in your file ? … I guess no …(if) so you have to describe the linearization process …
There is a related tag in DNG exif … see page 26
LinearizationTableTa g
50712 (C618.H)
Type SHORT
Count N
Va l u e See below
Default Identity table (0, 1, 2, 3, etc.)
Usage Raw IFD
Description,
LinearizationTable describes a lookup table that maps stored values into linear values. This tag is typically used to increase compression ratios by storing the raw data in a non-linear, more visually uniform space with fewer total encoding levels.If SamplesPerPixel is not equal to one, this single table applies to all the samples for each pixel.See Chapter 5, “Mapping Raw Values to Linear Reference Values” on page 77 for details of the processing model.
The data in the DNG is indeed linear - it’s the values captured from an image sensor without compensation.
I’ve been researching the LinearizationTable tag but found it used more for compression (16bit linear, log-encoded to 12-bit values to reduce size of .DNG file) than for what I’ve been looking to do, but I will look at it again.
If linear values from an image sensor are what’s stored in the DNG…is there any reason to use the linearizationtable tag? To me it seems only for the case of describing “how to linearize” the data in the file, from some log-encoded format, into linear. For me, starting with linear info, shouldn’t I leave this tag out?
Thank you, I did try this, though it hasn’t shown any different results.
I tried creating a linear tone curve via “exiftool -ProfileToneCurve=“0 0 1 1” -0 withtonecurve.dng original.dng” which created ‘withtonecurve.dng’ that had the ProfileToneCurve tag applied. I can’t verify what’s in the tag as it says “Binary Data 7 bytes, use -b option to extract”. Nevertheless, opening the new file in RT or any other viewers appears the same as before.
I think 0,0,1,1 would simply be a ‘linear’, or identity curve, and would do nothing. Here’s a 2.2 gamma curve; you’ll have to divide each value by 255 to put it in the range 0.0-1.0
Agree, no need to use the Linarization table if your data are linear
… but … I have to comment that your file contains 8bit data and this is far from optimal … I’d call this (8bit linear) dangerous for posterization (at the dark tones especially).
BTW your test shot looks like the data are not linear (very small difference between the darkest vs the brightest patch) … may be it looks so due to:
excessive glare from the side extra bright surface at the right side of the frame …
inproper defining of Black_Level (do you have any black frames ?)
non linear encoding (which would be optimal … ie compressing 10-12bit linear sensor data to 8bit_non_linear)