Toggle Out of Gamut Display for OCIO

[London]

I'm not sure if I'm using the right term for this, but with OCIO and sRGB view activated, the areas are too bright to display on my monitor are showing as dark blue even after I color correct. (I think this is what's being displayed—it's visible when the entire image is white because I haven't adjusted the exposure, and it's visible after I add an exposure node to correct the for it). This makes it hard to work on the image. Can this be toggled on and off? If I turn off OCIO color management, the overlay disappears, but then I don't have the color management which is the primary reason I'm considering switching to Affinity.

[James Ritson]

Hi @London, I've looked through your post history to get an idea of your workflow etc. I work with blender and OCIO quite frequently but I only come across strange colour artefacting when I'm using blend modes that don't work well with unbounded float values (e.g. Screen, Soft/Hard/Vivid Light). Certain tonal adjustments (e.g. Selective Colour, HSL) may also saturate colour values very quickly in linear space, which can often lead to unwanted results.

Are you using any particular blend modes or adjustment layers to produce the dark blue? If you grab the colour picker and pick one of these offending colours, you will often find that one of the channels has a large negative value, or the readout may in fact say "nan" (not-a-number). This is normally a sign that you're using a blend mode which doesn't work well with unbounded values (typically >1).

Just to troubleshoot, if you open up your EXR document and make no changes apart from configuring the OCIO device and view transforms, do you see any odd colour values or does everything look correct?

One final thing worth mentioning: Affinity Photo's OCIO integration is mainly for pass-through editing (e.g. when you want to slot it into a post-production workflow chain with other software that uses OCIO). If your purpose is to export a retouched render from Photo to a non-linear format (e.g. 8-bit JPEG, 16-bit TIFF), you will instead want to use ICC Display Transform as this represents how your document will look with the typical document-screen profile conversion.

This does of course complicate things when you want to match the Filmic transforms (or indeed any other OCIO transforms you might be using), since the transform chain for these usually involves a non-linear transform at the end—sRGB OETF, for example. Add this on top of your existing non-linear view transform (using ICC Display Transform) and everything ends up looking too bright. You can use a live Procedural Texture to perform a 2.2 power transform on the RGB channels which will counteract this. Alternatively, I'm almost finished with a small macro pack for adding Filmic transforms and will link to them here shortly...

[London]

Thanks, @JamesR_Affinity, I was going to submit a bug report, but when I tried to reproduce it with new images, I couldn't. I opened up my early files and the problem is still there, so I don't know what's going on. With both the new, working and old, bugged images, I use lighten mode to stack the outputs from each light in the scene on top of the environmental pass. The attached image shows the problem with my original files. Re: the troubleshooting, since I'm using multiple light passes, things look different if I set one to normal, since it's only part of the light. However, the darker image is set to normal with only an exposure node above it (my renderer outputs EXRs at +12 stops)—the problem persists. Enabling EDR does show the overwhites as white in ICC mode but not in OCIO mode (without Enabling EDR, the overwhites are displayed as in the attached images with either OCIO or ICC)

Thanks for the tip on ICC Display Transform vs OCIO. I am using Photo to composite and finish my renders before exporting them as JPEG for posting. Looking at the two files I opened to compare old vs. newer images, there wasn't a huge difference between them, but it explains why my exported images weren't always matching what I was seeing on screen. 

I'll anticipate your macro pack…and am going to spend some time with your tutorials. My last project taught me my decade+ of Photoshop experience doesn't necessarily mean I know how to do things in Photo. That was often to my great frustration (the amount of time it took me to make a mask almost made me switch back), but also revealed some powerful new approaches (procedural textures, at least once I figure out how to use them properly).

[James Ritson]

On 6/16/2020 at 7:56 PM, London said:

Thanks, @JamesR_Affinity, I was going to submit a bug report, but when I tried to reproduce it with new images, I couldn't. I opened up my early files and the problem is still there, so I don't know what's going on. With both the new, working and old, bugged images, I use lighten mode to stack the outputs from each light in the scene on top of the environmental pass. The attached image shows the problem with my original files. Re: the troubleshooting, since I'm using multiple light passes, things look different if I set one to normal, since it's only part of the light. However, the darker image is set to normal with only an exposure node above it (my renderer outputs EXRs at +12 stops)—the problem persists. Enabling EDR does show the overwhites as white in ICC mode but not in OCIO mode (without Enabling EDR, the overwhites are displayed as in the attached images with either OCIO or ICC)

Thanks for the tip on ICC Display Transform vs OCIO. I am using Photo to composite and finish my renders before exporting them as JPEG for posting. Looking at the two files I opened to compare old vs. newer images, there wasn't a huge difference between them, but it explains why my exported images weren't always matching what I was seeing on screen. 

I'll anticipate your macro pack…and am going to spend some time with your tutorials. My last project taught me my decade+ of Photoshop experience doesn't necessarily mean I know how to do things in Photo. That was often to my great frustration (the amount of time it took me to make a mask almost made me switch back), but also revealed some powerful new approaches (procedural textures, at least once I figure out how to use them properly).

Hi again, the macro pack is pretty much finished so I need to test it cross-platform and then I'll upload a test version—I would be really grateful if you could give it a try and let me know how you get on! It's quite exciting because I've implemented the log transform using existing Photo filters and functions, so you don't actually need the relevant OCIO configuration set up—anyone can use these macros and get the Filmic looks without having to extract the configuration files from blender.

Straight away, I suspect Screen mode is your problem. The maths involved mean that it would be very easy to produce negative values. For example, let's say you were blending two float pixel values that were both out of range (greater than 0-1). Take 1.323 and 5.12 as an example:

1-(1-1.323)*(1-5.12)

This results in a pixel value of -0.33076.

If you want to blend light areas on top of your main pass (for example, I do this with the bloom pass you can now get using Eevee), just use Add. Simple addition means you won't end up with negative values. Use Opacity or an Exposure adjustment clipped into the layer to control the blending strength.

By the way, regarding EDR—do you have an actual EDR/HDR capable display? If not, there's not much point to EDR, since it will simply "unclip" the pixel values from the document colour profile, which by default is sRGB. The overwhites you might be seeing will be outside the coverage of sRGB. If you are actually using an EDR display (or an HDR display with HDR compositing enabled) then ignore this 🙂

Finally, procedural textures are awesome, especially for 3D and compositing workflows! I'll post back here once I've organised those macros.

[London]

I'd be happy to test out the pack. I haven't been rendering much this week, but have a new project planned, so I should have a bunch of passes to throw at them.

[James Ritson]

Hi @London, I'd appreciate your feedback: http://www.jamesritson.co.uk/downloads/macros/jr_macros_blender_filmic.zip

I'll make this available low-key for now to see how people get on with it. There's an included PDF with installation and usage instructions. A couple of things to note:

• The first run of a macro whenever you start up Affinity Photo will take a couple of seconds (or possibly longer) before you see a result—this is due to a complex 3D LUT being loaded. Subsequent macro applications will be instant.
• Don't expect an absolute 1:1 match with blender—this is designed to allow people to bake Filmic looks into their 3D renders when using ICC Display Transform (traditional document-to-screen colour management). This colour management differs to the sRGB EOTF device transform within Blender, so I don't believe you could ever get a 1:1 match. Even TIFF files with a Filmic look baked in look different in Affinity Photo when compared to Blender. In short, you can match any exported bitmap image from Blender (e.g. a TIFF with Very Low Contrast), but you might not be able to match exactly what you see in Blender's viewport.

I could have gotten a slightly closer match to Blender by using an OCIO adjustment layer, but that would be dependent on the user setting up Blender's OpenColorIO configuration within Affinity Photo—something I wanted to avoid. Instead, these macros use a bunch of maths to approximate a log transform 🙂

Let me know how you get on! Here's a comparison I'll use for forum posts etc:

[James Ritson]

Just bumping this @London — I've revised the macros because I was working off an inconsistency. Looks like LUT transforms with GPU acceleration on Mac aren't performed correctly. I've adjusted all the macros to render correctly across Windows and Mac when in software (CPU rendering). Not sure which platform you're on?

It may not be a huge deal, since the difference can be slight for most image cases, but if you're on Mac and you absolutely want a 1:1 recreation of the Filmic looks, you'll have to disable Metal compute for now. You can do that through Preferences>Performance, where you can uncheck "Enable Metal compute acceleration". If you're on Windows, no worries, continue as usual 🙂

Revised macros are available at the same download link above..

 

[London]

Thanks for the update, @JamesR_Affinity. I am on a Mac, so I'll try to remember to switch off Metal compute when I try this. I rendered something out yesterday, but had an annoying geometry error. Hopefully, I'll be able to get that fixed and test this later today. i'm definitely excited to give it a go and report back!

[London]

I played with these macros a bit today. they worked great in ICC Display Transform mode. (After your earlier comments about ICC DT vs. OICC DT, I kept with ICC. And I just read your note in the PDF about doing that if you've already set up OICC, which I'd done  ). If you have the time for it, I'd love to understand what each of the layers is doing in the transformation. I'm not sure I know what crosstalk does for this (or at all).

In the process of testing this, I used an older file, one I'd previously toned and printed (love the soft proof node: I was able to use the printer's profile to make sure everything was how I wanted it). I realized that while I thought I'd saved the file, when using an .EXR, it doesn't seem to actually save the file. I just tested this and, indeed, the saved file was the same as the original (this is really obvious because my 3D app saves EXR files as about 12 stops over exposed and I'd put in a LUT that changed the color to be much warmer). Is there a way to force Photo so save EXRs in afphoto format, or ask?

[James Ritson]

12 hours ago, London said:

I played with these macros a bit today. they worked great in ICC Display Transform mode. (After your earlier comments about ICC DT vs. OICC DT, I kept with ICC. And I just read your note in the PDF about doing that if you've already set up OICC, which I'd done  ). If you have the time for it, I'd love to understand what each of the layers is doing in the transformation. I'm not sure I know what crosstalk does for this (or at all).

In the process of testing this, I used an older file, one I'd previously toned and printed (love the soft proof node: I was able to use the printer's profile to make sure everything was how I wanted it). I realized that while I thought I'd saved the file, when using an .EXR, it doesn't seem to actually save the file. I just tested this and, indeed, the saved file was the same as the original (this is really obvious because my 3D app saves EXR files as about 12 stops over exposed and I'd put in a LUT that changed the color to be much warmer). Is there a way to force Photo so save EXRs in afphoto format, or ask?

Hi, it was a case of studying the OCIO configuration and picking it apart—that only gets you so far, unfortunately. Filmic uses a normalised log2 transform which has to be approximated at the moment in Affinity Photo, and there are transforms either side of that which are just basic maths. They're not exposed in the OCIO configuration file, however, so a bit of digging was required..

The 3D LUT is what performs the crosstalk—essentially, emulating an organic film-like response. In the digital domain, a colour becoming more intense would just become more saturated. The LUT emulates an organic response: instead, as these colours become intense, the channels "crosstalk"—so an incredibly bright red colour would gradually start to desaturate as it mixes with the blue and green channels. That's my understanding, anyway—might not be correct!

The "looks" are actually just 1D LUTs that are applied once the colour values are in Filmic Log space—then there's an sRGB device transform at the end (another LUT) which completes the chain.

Photo has a write-back feature for most bitmap formats (JPEG, TIFF, PNG etc) when you Ctrl+S or CMD+S to save. Seems this applies to EXR files as well. The workaround is just to use File>Save As and save as a native .afphoto document—hope that helps!