ACES Matte Painting Workflow

[deekay]

Dear Serif Team and Affinity Photo users,

I'm a VFX Compositor & Matte Painter and I'd like to move from PS to AP. I hope you can help me with some questions regarding the Implementation and proper use of ACES and 32-bit. My background plate is exported from Nuke as an ACES - ACES2065-1 16-bit EXR file. The import into AP (1.6.4.104) works fine - the file get's recognized as an ACES file and I get the same result using OCIO. 

But there are a few things I can't get my head around yet:

1. How do I pick and paint high color values? Using the exposure slider in the 32-bit Preview I see that there are high values. If I pick and paint them back in, the result is way darker. (Changing the exposure doesn't effect the false picked color)

picked in Nuke for comparison

I moved from PS because there is a 16Bit limitation and I had to work with ACEScc files (log encoded) and use an ICC profile to check my work. I hoped to get around this using AP. 

Those threads are dealing with the same issue but the information is contradictory and I can't reproduce the method quoted first.

Quote

Your HDR image should open in Affinity as a 32 bpc document where click-dragging an eyedropper will display floating point values. The Colour Chooser window (opened by double-clicking a colour well) will also provide floating point values at its bottom left corner. The Info panel currently is useless for floating point images.

https://forum.affinity.serif.com/index.php?/topic/49815-hdr-raw-pixel-values/

Quote

Are you after the ability to enter values up to 65535 when working in 16bit? This can be done by switching the colour tab into 16bit from the tab's pop up menu. Colour inputs only accept integers and not floating point values as bits aren't floating point. Currently I don't believe we support 32bit but I know that it is coming. 

https://forum.affinity.serif.com/index.php?/topic/19787--/

 

1. What is the proper workflow of importing and edit JPGs in an ACES setup in AP? Unfortunately there's no way of assigning an IDT during import (as in Nuke) but I can reproduce Nukes behavior with OCIO Adjustment Layers, which seams pretty inconvenient.

(Windows Photo Viewer as comparison)

Bottom left: Two OCIO nodes in sequence [ACES2056-1 to Utility - Curve - sRGB] followed by [Output - sRGB to ACEScg].

Bottom right: Two OCIO nodes in sequence [ACES2056-1 to Utility - Curve - sRGB] followed by [Utility - sRGB - Texture to ACEScg].

This post deals with the question of the right IDT for JPGs in general. I guess going the Utility - sRGB - Texture way is better, isn't it? 

My color settings:

 

If you need further information or I haven't made my questions clear enough please don't hesitate to ask. I'm glad about any help or further learning resources!

 

Thanks a lot

[Gabe]

Hi @dkrez,

Welcome to the forums. 

Currently, it seems that Windows clamps the values to 1.00 regardless of the actual value. We've logged this with our developers for more investigations. We will come back when we have more details about this.

However, on Mac, it seems to be fine, both picking and painting out-of-range values. You cannot create one from scratch though, but if you colour pick it you should be fine. 

Thanks,

Gabe. 

[deekay]

Thanks a lot for your helpful answer Gabriel!

52 minutes ago, GabrielM said:

You cannot create one from scratch though, but if you colour pick it you should be fine. 

 

I hope this get's fixed as well. Painting high values would be a huge benefit when working on feature film stills.  

[lepr]

.

[James Ritson]

On 6/22/2018 at 6:13 PM, owenr said:

That statement is definitely incorrect.

Unfortunately, this statement is correct within context of the Windows builds. @dkrez, ordinarily you could double-click the active colour to bring up the Colour Chooser dialog—this has additional 32-bit options where you can set out of range values using input boxes and an Intensity slider. Currently, however, these don't work as expected on Windows, as the values will be clamped back to 1. The same issue applies when colour picking out of range values (as Gabriel has mentioned above).

Apologies for this, it's a UI issue and the developers have been made aware. Additionally, saving colour values as swatches will also clamp (they're stored in LAB)—the developers are also aware of this and there's a desire to improve it.

[lepr]

.

[Patrick Connor]

This issue has been addressed in the current beta build. Thanks for reporting this.

[James Ritson]

On 6/25/2018 at 3:45 PM, >|< said:

On a Mac, you can create a colour with a component value greater than 1.0, hence my post which you attempted to contradict.

I appreciate it's from last year but I've only just seen this post because of the thread bump. Based on your more recent posts I've read, however, I would ask you to reign in your combative attitude: it's counterproductive and contributes nothing to the overall goal of this forum. The assumption that the purpose of my response was to somehow undermine and contradict you is incorrect. I was stating that you cannot create initial out-of-bound colour values in the Windows version because of a UI bug. Whilst I would ordinarily agree that the statement was wrong, I had to point out this inconsistency for the benefit of the user, and also cover how you would go about creating out-of-bound values within the user interface, since that was not actually explained.

[hulmanen]

This is an old thread, but the issue seems to remain, or have resurfaced.

On Windows 10, using the ACES 1.0.3 OCIO config, I can't pick color values above 1.0 (255, 65535, depending on the colour panel settings). The picked values are just clamped to 1.0. Should this work as of now?