Hi everybody,
to compare with what you get, here is the ACES TIF 16 bits HD that give me correct gamma and correct colors if i ingest it in RESOLVE in a ACES CCt AP0 workflow.
DNG-direct_AP0_bb_1.1.2.tif.zip (4.9 MB)
regards.
JC
That does not explain why your screenshot shows a horizontally scretched image from RT while my screenshot shows it correctly…
Well then, my comment is pertinent. Having the same camera profile in both workflows is all about that - a set of primaries that appropriately represent the camera’s spectral response. If the color primaries are different in the two softwares, the output color could be different…
To be fair, most folk who make such are likely using sufficient tools to render similar results. But, in comparisons, I’d want to eliminate as many such differences as possible so the real differences are apparent.
I might be missing something but appending a profile to raw processing won’t give you the same result because the rest of the processing workflow would be different between apps. My guess is that @heckflosse’s edit isn’t as heavily tweaked and processed as yours.
My comment was mainly about the horizontal stretching…
I was referring to the side by side images of @Jean-Charles_Fouche. The main question should be about colour accuracy and keeping the workflow colour managed. My remark is that the display-referred appearance of colour at the intermediary steps should not matter and a side by side comparison irrelevant as long as the data is intact and the profiles are correctly done.
Regarding the first point, that is not the reason that we don’t use ACES as the input profile. The input profile should be the camera’s profile, either stock profile or manually profiled profile. Once specified, RT will know what to do to convert the data to the working profile according to RT’s extended Adobe coefficients info.
Selecting the output profile is the most straightforward step, as you should be able to set it to anything you wish. In particular, since ACES AP0 is so large, you don’t need to worry about gamut clipping or compression.
Notice how I skipped working profile just now; because this is where it gets complicated. It isn’t as simple as making it the same as the output profile and your job is done. That is okay only if there are no other subsequent operations. I don’t know if RT’s neutral preset has nothing in the pipeline after the working profile is appended. It would also depend on what you plan to do at the ingest stage prior to exporting to Resolve.
You may ask, What is the fuss if my working profile is sufficiently large and the output profile is the same so no final conversion takes place? There are things to discuss but they are out of my depth. The thing to note is that if the working space is too large or too small or the profile is malformed, you could have problems with artifacts or discontinuities. Moreover, not all operations are compatible with all spaces.
If you insist on using ACES, note that ACES is mainly a storage format. That is a monkey wrench for you. @XavAL mentioned @Elle’s profiles. You would have to double check but if memory serves her ACES profiles should be AP1 not AP0. This is for the explicit reason that I described above: AP0 is for transport and too large of a colour space is no good. There are other more specific ACES specifications but that is over my head again.
The takeaway is that at this point we are getting in the weeds. The topics discussed might not matter to us regular folk. The reason behind all reasons is that ICC profiles, CLUTs and matrices are limited and don’t sufficiently describe the psycho-physical properties of colour or how colour is designed to be stored and processed digitally. It is a broad and complex subject that is still being researched. E.g., characterizing a camera’s actual spectral sensitivities and implementing them into the workflow.
Certainly, we can do our due diligence, learn from one another and control our workflow as much as possible but then we need the resources, people, expertise and close collaboration to accomplish that, especially in the cases where the project is expansive like those in Hollywood.
1 Like
This happens because RT does not support (yet…) the use of the embedded (in the DNG file) dcp profile. Only uses the cameramatrix2 …
We can extract the dcp with dngtool and use it as custom profile … then the renders match if we use the the “tone curve” checkd or maybe the RT’s “auto-matched tone curve” in exposure tab 
kl-fp.dcp (4.7 KB)
Although I find the embedded in dcp tone curve too aggressive (see the curve shape using the “automatched tone curve”) … I would prefer a better smoother tone curve with at least better handling of bright tones.
2 Likes
Did a quick google but failed to find a good match. What is dngtool and where is it available from?
Hi everybody, thanks for spending time with my question.
I will check my settings in RT, but to make everything more clear for you, here is what i’m looking for:
- I work with the NETFLIX workfow: that mean that my colorgrading worklow has to be ACES.
- My main colorgrading software is RESOLVE.
- The color management settings is ACES CCt.
- I need to output ACES APO files for NAM and GAM (storage and delivering format)
- When in ingest EXR or TIF files like NAM or GAM, i use no IDT at all, so Resolve convert my source file directly with my ODT (today REC709).
- I use to shoot with Alexa, Venice or Varicam camera, they all have they correct IDT in RESOLVE and until today, i have no problem with unappropriate Gamma or Color primaries.
BUT - I’m now working with RAW files that are not so well demosaiced by RESOLVE: Blackmagic and the new Sigma FP cameras.
- I’m trying to demosaic them outside RESOLVE to get best result (in term of noise level, aliasing and precision): The “instant” demosaic in RESOLVE is lossy.
- The big problem with the SIGMA FP camera is that RESOLVE doesn’t know it (no LOG/wide gamut for her for example), and i need to manage it outside RESOLVE.
SO - i decided to find a tool to batch demosaic sigma FP .DNG files, and i tried RAWtherapee, darktable and some others Tools.
- At this point, RAWTherapee gave me the best result as a CLI tool, with ACES output profiles. But it’s new for me.
My goal is to find some good settings that give me the appropriate color workflow (from FP primary to ACES primaries) to ingest EXR or TIF files into RESOLVE in a ACES workflow.
Sorry to be long to explain… 
regards,
JC
Following my previous post, these are the profiles required:
- for the input profile, you need to create a custom profile for each of your cameras. I don’t know if RT has the proper profiles for them, but even if it has them, it’s much better that you have a custom profile for your own cameras (not a generic profile for that model).
To do so, read and follow these articles from Elle’s website:
How to make a target shot
How to make a custom camera profile - the working profile must be ACESp0
- assuming that you have extracted the ACES profiles from Elle’s profiles bundle, and you have pointed RT to the folder where they are in, the output profile must be ACES-elle-V4-g10 (that would be a linear gamma and version 4 profile). If you need to know what those options are for, read the link I gave about the explanation of all the profiles.
I think with the steps I gave you, those images should be have the proper colors with the proper primaries upon exporting them.
Please, tell us if that is the proper solution for you once you have checked it.
profile created with the rawtherapee tool
RTv2_ACES-AP0_g1.000000_s0.00000.icc (928 Bytes)
this is the RT version ( neutral profile ) converted to srgb
rt-resolve-aces.zip (17.1 MB)
The rt-aces.tif in the .zip is the rt output with linear gamma and AP0
primaries 
Edit
RT with dcp converted to srgb
rt-dcp-aces.zip (12.2 MB)
1 Like
This image has ap0 primaries and rec.709 trc, it isn’t linear.
Is this that you want?
I think that the V2 e V4 icc AP0 profiles in rawtherapee have srgb trc…
The custom icc profile i’ve attached before has linear gamma.
your tiff with the correct icc profile assigned (RTv2_ACES-AP0_BT709_g=2.2_s=4.5.icc|attachment (24.9 KB) )and converted to srgb
Rawtherapee converted to srgb
Some confusion in our discussion.
1 We aren’t the best people to ask about workflow. acescentral.com would be a better place to ask what would be the ideal file specs to ingest without an IDT.
2 Only ACES2065-1 and ACEScg can have AP0 primaries. The rest are AP1. ACEScct has its own encoding (not Rec709) and is ACEScc with a toe. This is by memory. Please refer to
for the exact information.
If this forum is not the best place to ask how to work with RT…, where should that place be?
Well, my best guess is that this is fundamentally incorrect.
If we read:
- Wikipedia ACES explanation about the different color spaces defined
- A Maya workflow with ACES
- Chris Brejon ACES explanation
and many others, including the technical documentation, it is clear that all those ACESxxx color spaces are part of a framework mostly oriented to movies, but yet usable with still frames.
But all of this is mostly an out of topic discussion regarding the question asked.
I think the OP is more than capable to create his own workflow with all that conversions between different color spaces (all of them part of the ACES specification). All that has been asked is how to get a proper starting image that meets his input needs. And how to do it with RT.
I guess that answer has already been answered. All we have to do is wait for him to test it and report back if the proposed solution gives him what he needs
1 Like
The storage file should have always AP0 primaries (tiff or exr).
Probably he just needs to decode the raw file with the dcp tone curve enabled (like resolve does) and export a linear tiff with AP0 primaries.
And by the way, this is a comparison of both ACESp0 and ACESp1 (done with DisplayCal):
(ACEScg has the same gamut as ACESp1)
Please be patient with me and reread my posts. I believe they are relevant and informative. We have already established how to do colour management in RT. Besides my discussion on color space, processing, etc., the rest is totally about profiles and ACES. Where better to learn than from ACES Central and the technical PDFs?
@Elle has been mentioned multiple times. She can be reached via various mailing lists and email:
Other people to ask are @KelSolaar and Troy Sobotka. Elle and Troy no longer frequent this forum for various reasons. This wraps up my involvement in this thread. Hope you found it helpful.
Sorry Afre I don’t see how your posts are relevant to this discussion.
If you want to be helpfull to the discussion you should have downloaded that picture and see that he doesn’t have create an icc profile but rather used the pre-installed one in rt
This is why i have directly linked the AP0 linear profile.
The second question is how to match the resolve raw decoding, does resolve use the dcp tone curve? how to do the same in rawtherapee?
Here ilias_giarimis has kindly provided the dcp profile and with the dcp enabled rawtherapee and resolve are a very close match.
I don’t understand why you suggest him to contact elle, troy or goes ask in the aces central forum.
Hi everyboby,
i did import into RAWtherapee GUI the DCP file, ICC files, i did setup my output profile, and after a while, it’s works fine with RESOLVE !
The good result from RT: ACES AP0 Lin
the correct render in RESOLVE When ingesting the AP0 TIFF files from RT Gui
- So i understood how to make it working within the RT software and the GUI.
- My workflow is ACES AP0, and if i ingest directly my TIFF file, i get the correct picture in my timeline.
So thanks alot to everybody.
I have another question:
- If i use the rawtherapee-cli with the PP3 i used to make the correct TIF files, i dont get the same result (in terms of gamma): i dont know why i dont have the same result with the CLI version ? (rawtherapee-cli -o kl-fp-cli-jeudi.tif -p aces2.pp3 -t -c kl-fp.dng)
on the left: the correct ACES AP0 with the GUI / On the right the wrong render with CLI
What i’m missing with the CLI version ?
Thanks !
JC
1 Like