GNOME Bugzilla – Bug 751548
Support for Cineon and DPX file formats
Last modified: 2018-05-24 15:23:49 UTC
As future releases of GIMP will allow editing high bit depth images, support for Cineon and DPX files would be a very nice addition, especially for people who want to use GIMP in conjunction with a VFX workflow:
That sounds like a good addition. Let's hope somebody codes a plug-in for 2.10.
Looks like a plug-in was coded back in 2005:
Nice, this can definitely be used as a start, and the hard part (reading
and writing the file) seems nicely done (it all seems nicely done).
However, it needs some changes:
- formatting (in every line)
- port to GEGL (actually gives us 10 bit)
- port to GIO
- porting to non-deprecated APIs, the code is pretty antique
Maybe the author feels like updating it himself for inclusion, do you
mind asking him?
Had a conversation with Troy Sobotka about this plugin a while ago. He pointed out a few things:
- DPXs are display referred, and it is challenging to know what log curve is applied to them or other such color / colorimetry related things.
- It has a gamma slider. This might have to be a proper two-part such as many logs.
- What's the white point? Relative to what?
I also need to point out that Cinepaint folks patched this plugin to better support 64bit systems.
-unsigned long t = ntohl(cineon->lineBuffer[longIndex]);
+unsigned int t = ntohl(cineon->lineBuffer[longIndex]);
This might have to be taken into consideration.
Created attachment 317300 [details]
Cineon log to two types of "linear", plus sampling gray
Gerardo Estrada is a VFX person who has been testing high bit depth GIMP. I mentioned to him that there had been some posts to this bug report and he sent back some information. What follows is from Gerardo's email, with some portions (hopefully correctly) rephrased/rearranged:
With respect to Cineon files, there are two very different types of conversions that are called "linear": The attached jpeg shows:
1. A Cineon log file (top)
2. The Cineon file after being given a video-like tone curve using a Cineon Converter: "This is what they call "linear" after a log2lin conversion with a Cineon Converter. . . . In color-grading work however, what they call linear is not what we call linear, it's a "video-like" tone curve on typical print stock space."
3. The Cineon file after being converted to a real (radiometric) linear space, the result of applying a "fixed pure log formula with no reference black offset and standard white, so no parameters to adjust", that converts from the Cineon log file as input to radiometrically linear output. "The purpose of this fixed cineon formula in CG work is to get real linear data representations from log2lin conversions of DPX files, or set up correct contrast thresholds (lin2log) for adaptive sampling antialiasing when rendering CG images to logarithmic colorspaces."
The fixed formula only allows to convert between the Cineon log file and radiometrically linear. But with a Cineon Converter tool we can convert from log to "linear display" or "real (radiometric) linear". With such tool, the user has the possibility to adjust the following parameters with the following typical default values:
1. Black Point (typically 95 in 10-bit)
2. Internal Black Point (commonly 0.0 in fp values - some converters only provide the 10-bit black level and always assume 0 when mapping to the internal black point)
3. White Point (typically 685 in 10-bit)
4. Internal White Point (commonly 1.0 in fp values, 65535 in 16-bpc values and 255 in 8-bpc values - some converters only provide the 10-bit white level and always assume the maximum possible value when mapping to the internal white point)
5. Film Stock Gamma (typically 0.6 - some converters only provide the Conversion Gamma option and always assumes 0.6 for this parameter)
6. Conversion Gamma (typically 0.6 - some converters only provide the Film Stock Gamma option and always assumes 1.0 for this parameter)
7. Soft Clip or Highlight Rolloff
- Those are the standard values. Then, with the gamma slider [referred to in Comment 4], one can go with the standard values (0.6 for film gamma or 1.7 for display gamma). These are just gamma/pow values which don't conform to any actual color negative stock.
- Cineon converters perform no other type of color transformations or any other colorimetry related aspects. That's not covered in the original specs which ignored the fact that the emulsion layers in color negative have different gammas. The above parameters however can be applied over each R, G, B channel independently for further characterization, but it's main purpose is just to work as a single tone reproduction curve. Nothing more. Chromaticities can be changed by other color tools, but these aspects are out of the scope of the Cineon specs or a Cineon Converter tool. Colorimetric aspects (taken into account in DPX format header tags) are covered by LUTs and matrices transformations or color profiles in a motion picture production pipeline.
- Since the format pretends to store a typical color negative film, this encompasses a wide range of film densities and doesn't belong to any one specifically, so the Cineon specs are just describing a generic TRC with equal red, green, and blue color records throughout the whole tonal range from black to white. In this sense, the white point is relative to log exposure only, it doesn't conform to any color temperature or anything like that. In fact, there's no color negative film stock with exactly 0.6 gamma. This value is just a generic approximation for a wide range of film negative densities.
[Here are links to Kodak Cineon specs:
[Unfortunately for purposes of coding up a Cineon converter, the Cineon specs can't be followed "to the letter" because the "18%" reflectance gray card is actually 16% gray, as recognized even by Kodak:]
This is [from the specs]:
• The 90% reflectance white card should be recorded at a Cineon code value of 685
• The 18% reflectance grey card should be recorded at a Cineon code value of 470
• The 2% reflectance black card should be recorded at a Cineon code value of 180
• Dmin (the blackest black that should be recorded, ~1% black) is recorded at a Cineon code value of 95
Well, the thing is that in practice, nobody use it in that way. Specially the point related to the 18% grey card. What happens is that the original middle grey that Kodak used for the grey LAD patch was not 18% but 16%:
This is what they say about the Laboratory Aim Density of Color Negative Film:
Original scene had Munsell N 4.5 neutral having a reflectance of 16 percent."
Then, the reference grey is not 470 but the 445 specified in the attached Marci cineon file [which is too large to attach to the bug report], and "everybody" use this reference instead of the 470 as recognized by Kodak itself:
"Finally note that some facilities may choose to use a digital LAD with code values other than 445, 445, 445. We chose these values to be consistent with a large body of industry practice."
So, not even Kodak use the 470 grey patch as reference. With the 445 value as reference, compositing packages (Ae, Fusion, Nuke, etc) and also 3D packages (LW, Maya, 3dsMAX, etc) match exactly this criteria (less Autodesk Composite which it seems tried to conform to a messed spec).
[The attached jpeg shows the gray patch picked in Ae, Fusion, and LightWave 3D, with the value:]
445 / 1023 = 0.43499
So when developing a Cineon Converter tool with the standard default values specified above, it would be good to be sure the results match the 445 grey patch as Ae, Nuke and Fusion do, as well as main 3D packages do. This would be useful not only to keep consistency with the VFX industry practices but also to more easily retrieve radiometric linear values from Cineon log files.
(In reply to Elle Stone from comment #6)
> 6. Conversion Gamma (typically 0.6 - some converters only provide the Film
> Stock Gamma option and always assumes 1.0 for this parameter)
Sorry! That should read "6. Conversion Gamma (typically 1.7 "
There are no existing patches for this. After the Wilber Week meeting, isn't it typically one of these bug report we could just postpone?
Note that as we discussed at Wilber Week, such a feature could still be released even in a minor 2.10.x release if someone provides a patch afterwards (new release policy), but I think it is worth updating milestone of such bugs (to 3.0?) to get a simpler list to process.
So can I push this to 3.0 milestone?
Speaking as the person who reported the bug, pushing this to 3.0 milestone is fine with me.
I completely forgot about this bug. Having been reminded of it, if someone else doesn't get there first I'll try to update the patch (no promises).
Fine. Milestone updated to 3.0. It could still make it to 2.10 if someone soon makes a relevant patch. It can also make it to a later 2.10.x minor release with our new policy allowing new features in minor versions.
-- GitLab Migration Automatic Message --
This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/705.