This should not happen in the official Win64 package. It should be ready in few hours…
Works for me now.
I used filmic (OCIO) in my latest few PlayRaws but not in the conventional manner. Typically, my G’MIC processing flattens the far ends of the highlights and shadows, so very low contrast is actually useful for me.
1 Like
@Carmelo_DrRaw I think it would make more sense for the order to be
- slope
- power
- offset
Currently, it is
- slope
- offset
- power
In fact, Slope/Offset/Gamma (SOP for brevity) seems to be the recommended wording from ASC, and also matches the order in which the adjustments are actually applied.
Blender uses Offset/Gamma/Slope, but I guess this is for compatibility with the legacy Lift/Gamma/Gain mode…
Yes, depending on the orientation of the module, I prefer SPO (top to bottom) or OPS (left to right) because, loosely speaking, offset affects the shadows the most, power the mid tones and slope the highlights. I understand the SOP order but I always go to the middle field intuitively thinking it is power. Does that make sense?
Another reason that I would place offset at the bottom is that it seems to be really sensitive; small values affect the overall image a lot from my testing. It is a set of parameters that I would want to adjust the least.
BTW, I am doing a series of PlayRaws with OCIO and am really enjoying it.
Dumb question - using OCIO how can you specify a particular ACES .ctl file as an input/color transform/output colorspace, rather than just being able to pick from a preset list ?
Thanks.
If I am not mistaken, the implementation is far from complete.
Sorry, what does that mean ?
No, at least not with the current OCIO v1.
AFAIK the ACES ctl are backed into LUTs+colorspace transforms and referenced in a configuration file. If you want a specific input/color transform/output colorspace sequence tat is not already part of the existing OCIO configs, you have to build a new one…
OK - thanks for clarifying that.
Disappointing though, since it makes OCIO a lot less flexible that I thought.
I think it would be possible to implement a CTL language interpreter… the question is how useful it would, and how many potential users it could have.
If I remember correctly there is an existing library to interpret chk files, so maybe the required work is not really huge.
CTL is the heart of ACES, so an implementation already exists - it just doesn’t seem to be part of OCIO. [ I guess I don’t understand why many other formats are part of OCIO (i.e. CTF), but CTL is left out. ]
Aparently this is no longer working.
The strange thing is that yesterday I was editing with one of the usm appimages and then I added an OCIO ACES layer and it just worked, and I hadn’t set up the variable in the terminal before.
Now, both the latest stable and the usm releases show a black display area when the OCIO ACES layer is active.
I need that layer 
… it gives excelent results in this image I’m working with.
EDIT: Oh, my! OCIO layers no longer exist in the latest release 
Can’t they be brought back to life?
As implemented so far, there are too many gotchas for me to be comfortable with OCIO in PF. Occasionally, I use OCIO filmic to see what can be juiced out of the raw but I think that is clipped or normalized and also sRGB, so not nondestructive.
So is/was is it meant to be used only at the end of the pixel pipe?
The fact is that with this specific image it really popped things out.
Only OCIO filmic. The other OCIO module is mostly for taking in configurations. I haven’t used the latter in any practical way since it usually crashes on me or gives me those large rectangular artifacts in the preview that show up whenever something goes wrong. You’ve seen those before.
1 Like
I will have a look tomorrow. Indeed OCIO has been removed by mistake from the tools menu, will fix that asap. Then I’ll see if it works or not on my system…
1 Like
I have restored the OCIO tools in the UI, and the ACES config seems to work fine at least on my system:
Indeed, the ACES views are mostly intended to target a given display type, applying some tone-mapping and highlights compression on the way, so they should come at the very end of the pixel pipe…
1 Like
I will try it again when I have the time. Sometimes it works between commits for some reason. Looks like you have cleaned and tightened up the UI aesthetic: I like it.
That’s WIP, I am trying to ficus on the widgets layout, to give then a cleaner and more “professional” look. I hope to merge something usable very soon…
2 Likes