That’s it!
Why? Is my Ubuntu environment messy?
Not your fault. 
1 Like
No, it’s an OCIO bug, see here.
I will set the variable in the AppImage startup script, at least until OCIO gets fixed.
1 Like
@afre and other Win users: could you please try this experimental Win64 package with OCIO support, and let me know if it works properly for you? I would like to make sure it is OK before updating the downloads in the continuous release…
Here is the link: Filebin | w5ibd2bs2t2v0uus (size is quite large, but I need to clean up the OCIO config folders…)
Thanks!
Feedback
1. Looks okay (pun intended). Since it is an extra layer, takes longer to process. (Remember that my system is slow.)
2. It appears that the Filmic (OCIO) module includes both the view and the look transforms because when I add a view from ACES (OCIO) underneath it doesn’t result in the appearance that I would expect. Maybe it is doing the right thing because of colour management (or the lack thereof) and my screen type.
- Does this override the display profile? Or adjust things before / after?
3. I would be interested in having access to Troy’s greyscale and false colour looks as well.
4. When I click on the view selection menu, I get an infinitely(?) scroll-able option list (white section).
PS 5. I know that it is still early days, but it would be cool to have a module to examine the view and look presets and be able to create our own. Sorry that this is multiple feature requests wrapped in one list item. I know that you aren’t Santa @Claes. 
PPS 6. Since it is yet another layer, I wonder if it could have a mask.
- Regular masking isn’t working for me ATM. Is it broken? When I add a curve or threshold, nothing happens. Maybe I forgot how to because I rarely use it. It also crashes when I make an adjustment with
show masktoggled. Maybe it is related to @chroma_ghost’s woes…
I tried to load @gadolf’s PFI again using the latest commit. PF seems to be looping endlessly when I open the file; that, or it is taking a very long time.
Now it’s just a positive feedback.
I opened an image and just added OCIO filmic: bingo! It’s almost as if the image is ready. Amazing!
Before:
After:
The highlights warning that shows in the first screenshot has gone in the second.
So, if I correctly understood it, this layer should be kept at top. If I want to do more edits, I should add other layers beneath it.
1 Like
I haven’t had the time to try it yet, but the typical workflow with ASC DCL is to apply the transform in ACEScc (of any log space) instead of a linear one.
Exactly!
Not necessarily. IN fact, in log space the adjustments are less intuitive. The correspondance is:
- offset (linear) → slope (log)
- slope (linear) → gamma (log)
- hamma (linear) → undefined (log)
In other words, in log space you cannot apply an offset, and the gamma adjustment does not have an obvious mathematical interpretation.
More details in the answer to this question: cycles render engine - What is the the ASC-CDL node? - Blender Stack Exchange
Oh I absolutely agree with that. However, the ASC CDL spec does not define in which colorspace the transform should be applied. And in my experience, most (read: all) cinematographers do apply their changes on the original log signal from the camera (or in ACEScc or ACEScct), and most colorists do the same. I still dont understand why they do it. I think it’s mostly out of habit.
In fact, I believe the colorspace ACEScct was added exactly for that reason: colorists could not do an offset in ACEScc and so they added a toe to the curve.
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.