Tthis exact info, including gamma, should be near the top of the thread/website/PDFs to clear some confusion.
Primers colour management: transformation, optimisation, unification
- Thread starter Hrvoje Simic^
- Start date
Tthis exact info, including gamma, should be near the top of the thread/website/PDFs to clear some confusion.
Happy Solstice
I think he means baking the transforms into a LUT as opposed to having them in a more flexible state like a DCTL with adjustable parameters, etc
Having played around with Primers (mostly for the BMP4K) for a while now, I'm not sure I agree. While I like the sensor corrections Primers provides, I mainly see myself using the Base version as part of a larger picture formation change that includes other tools like Troy's AgX and/or Juan's 2499 DRT and not using Primers to go directly to my 709g24 output (especially if my target's not 709). Both of these tools expect a flavor of LOG/WCG, and while I can use CSTs to get the Primers output there, I often find myself second-guessing the recipe and I'm not in love with going from WCG > normalized > WCG. Maybe it doesn't really matter THAT much as long as the results are good, but it seems like you have put a lot of thought into very strong and specific targets for what a given Primer is fixing and I'd like to use them with more confidence that I'm not breaking anything or kneecapping myself.
Let's get this part perfectly clear:
Founded caution and in its extreme variant paranoia from "baked in transforms into a LUT" come from using them for transferring creative looks which a) limits undoing and tweaking the look and b) prevents undoing processing errors in case LUT is of poor technical quality. This train of thought transferred by automatism to colour management, further motivated by imperfections and limitations of standard log-to-display LUTs. So people assumed this is a LUT thing or "baking a LUT" thing. It is not.
In case of camera-to-display colour management you don't want flexibility in choosing your own way the image data hits the display, like you don't want to choose your own thing for monitor calibration. These options are today sitting in post because having more options creates a sense of advancement and due to unfinished colour pipeline in standard workflows, where there is no single, widely applicable transformation which takes care of multiple image properties within one conversion step.
If you had to tweak the engine management or the gas pedal response of your car for every street and while driving it might be seen as "advanced features" but wouldn't really be an advancement, would it.
It is an immense undertaking to take care of real life, camera-recorded, wide gamut & high dynamic range material and multiple image properties, throughout the signal range and within one conversion step achieve a proper conversion for all to land properly for non-linear display, plus doing this for multitude of camera responses,
...so currently crucial parts for proper image formation are left unloaded on the "either/or", need to compensate in post and user tampering with image engineering with few checkboxes and sliders for the colourists.
Which does NOT achieve proper transformation and where tampering with options will NOT remove processing imperfections and image deviations. Those "flexible" options are equivalent of a duck tape, giving some sense of accomplishment and feeling of control to the colourists while the outcome has issues.
Primers complete the colour pipeline.
So one can fully focus on the creative look and give some ease to the left brain. The technical conversion does its job completely.
This is one of the reasons it took 8 years to accomplish this. Covering few image parameters is easy, the effort and time for covering more and more rises exponentially.
This is one part of historical importance of this project.
Also, transforms are processes, 3DLUT is the embodied outcome of multiple processes with defined targets.
Processing has errors, LUTs can be examined and corrected for processing errors.
This is the superior route for this purpose, not inferior.
The other way around.
...
Let's see this again.
Especially examples 6 and 11.
These are not even from the latest generation.
Primers Camera Colour Management for RED cameras
Professional sensor-specific colour management tools for RED cameras
omeneo.com
Last edited:
Yeah, I'm not sure either of us were arguing against he logic of locking the math down... in fact didn't Juan explicitly state he couldn't see it presenting any issues? I think you'll find I'm in no way anti-LUT. So if you're responding to just the bit you quoted, I'm not sure who you're trying to convince of what.
If you're also responding to the rest of what I wrote, the pipeline may be "complete," but as of right now Primers are (maybe?) not (fully? elegantly?) compatible with some very good tools I want to use to sculpt my creative look. Or maybe they are. Not sure.
If you're also responding to the rest of what I wrote, the pipeline may be "complete," but as of right now Primers are (maybe?) not (fully? elegantly?) compatible with some very good tools I want to use to sculpt my creative look. Or maybe they are. Not sure.
Last edited:
That depends on a pile of things, what those tools are designed for and, what they "expect" as input, at which point are they applied, do they alter the tone curve, what colour processing they do, etc etc variables multiply.
Also, with this route, one should avoid camera-specific tools, Primers deal with camera-specific part.
Do you plan to make demo versions of Primers, e.g. watermarked, encrypted DCTLs?
"Multiple LUTs can be defined and applied in a single DCTL"
github.com
"Multiple LUTs can be defined and applied in a single DCTL"
ResolveCafe/docs/developers/dctl.md at main · CommandPost/ResolveCafe
The resolve.cafe website. Contribute to CommandPost/ResolveCafe development by creating an account on GitHub.
github.com
If I understand this, isn’t Primers then not just another DRT (that only goes to 709), that tries to give every camera sensor a similar carefully chosen ‘neutral look’?
Because this image on the website led me to believe it was some sort of log to log curve, which IMO would make way more sense (for creative grading) and would be more flexible. But obviously you would be bound to the creative decisions of the DRT you select and if you want to control the chain you need a DRT..
If the goal is to just select the DRT and be mostly happy with the look it gives you, its a justified choice.
Nope.
Nope.
Info on the web needs redoing for better insight and due for an update and more info coming up in this thread will help.
Quick preview: some of the changes to that graph:
1) Replace"native log & wide gamut" with
"recording-optimised non linear image data state (camera maker's log coding & wide gamut)"
and "output transformation" with
"viewing-optimised non linear image data state (default landing on SDR 709/2.4)
2) No branching to either SDR or HDR, sequential order, HDR node goes after SDR
3) pre-LUT main balance & creative look (part1), post LUT - creative look (part2), I need to test a few things and resulting signal properties.
Also - simple 709/2.4 info as output was present on earlier info versions but removed after the discovery that fully normalised, all-actual-recorded-range-containing, properly compressed image data for display also lands on HDR nicely with appropriate CST (tested with HLG) which indicated that:
a) this image formation methodology is not limited to 709 and achieves display gamut independent optimisations and
b) some conceptions will have to be re-considered.
This may also shed some light on why Cullen's simple question on page 1 was not met with a simple straightforward answer, the lack of which drew some concerns, understandably so.
Last edited:
Very interesting results from a phone.
Last edited:
Why? Would I not want the most correct input as a starting point regardless how far I push the look creatively?
More info, restructuring
Part 1
Using some of the concepts in current worflows Primers can be seen as having properties equivalent to ODT + RRT.
Specifics differing from standard tools and workflows:
1) Transformation is designed and engineered directly based on thoroughly analysed actual camera response, differentiating and addresing specific properties of both content (image data qualities affected by image capture device properties) and content context - image data state (log OETF & wide gamut)
2) Transformation is scene-independent and throughout different scenes basic colour correction easily compensates, no need for multiple transformations for specific scenes
3) No need for "scene-linear" processing stage for camera unification > reduced processing steps and minimised processing errors
4) Processing results embodied within a 3DLUT are thoroughly analysed to check and remove any processing errors > utmost smoothness
5) High quality non-linear to non-linear mapping achieving:
a) full definition across the exposure range while keeping tonal separation and stability;
b) preserving all recorded dynamic range and gamut data;
c) fully natural image rendering and rolloff to max values;
removes the need for separate "gamut compression" feature, variants of saturation response or any additional manual tampering guesswork in post for base image formation. Image data is fully prepped from the get go and ready for creative look design.
6) Default SDR output becomes normalised unified viewing intermediate
7) Due to achieved full range mapping within SDR intermediate and technical qualities across the range:
- Converted result (viewing & normalisation intermediate) can be brought to working intermediate via CST, taken from initial "SDR viewing state" back to linear, any log or DWG/intermediate wide gamut "working data state" for building and applying same creative look on different camera material, unconditioned from processing boundaries of default "viewing state";
- Same SDR pipe can be used for succesive remapping output to HDR without loosing original recorded range or damaging image/data properties
8) Same tools can be applied in cameras, monitors, recorders and in post
9) Standard conversion form > platform independent
10) Camera-referred, scene independent & viewing-referred, delivery independent
Part 1
Using some of the concepts in current worflows Primers can be seen as having properties equivalent to ODT + RRT.
Specifics differing from standard tools and workflows:
1) Transformation is designed and engineered directly based on thoroughly analysed actual camera response, differentiating and addresing specific properties of both content (image data qualities affected by image capture device properties) and content context - image data state (log OETF & wide gamut)
2) Transformation is scene-independent and throughout different scenes basic colour correction easily compensates, no need for multiple transformations for specific scenes
3) No need for "scene-linear" processing stage for camera unification > reduced processing steps and minimised processing errors
4) Processing results embodied within a 3DLUT are thoroughly analysed to check and remove any processing errors > utmost smoothness
5) High quality non-linear to non-linear mapping achieving:
a) full definition across the exposure range while keeping tonal separation and stability;
b) preserving all recorded dynamic range and gamut data;
c) fully natural image rendering and rolloff to max values;
removes the need for separate "gamut compression" feature, variants of saturation response or any additional manual tampering guesswork in post for base image formation. Image data is fully prepped from the get go and ready for creative look design.
6) Default SDR output becomes normalised unified viewing intermediate
7) Due to achieved full range mapping within SDR intermediate and technical qualities across the range:
- Converted result (viewing & normalisation intermediate) can be brought to working intermediate via CST, taken from initial "SDR viewing state" back to linear, any log or DWG/intermediate wide gamut "working data state" for building and applying same creative look on different camera material, unconditioned from processing boundaries of default "viewing state";
- Same SDR pipe can be used for succesive remapping output to HDR without loosing original recorded range or damaging image/data properties
8) Same tools can be applied in cameras, monitors, recorders and in post
9) Standard conversion form > platform independent
10) Camera-referred, scene independent & viewing-referred, delivery independent
Last edited:
I wonder how that project turned out.
