Mike_A

I wasn't meaning to imply those features were unimportant - they are important for me too. I'm mainly working in 3D CGI - so 32bit renders, ACES and EXR are one of the main reasons I got AP in the first place. It just seems very odd to me that they claim their target market to be 'photographers and photo editing', but do support advanced features and functionality such as 32b, ACES, EXR - and yet don't support basic features like direct and unrestricted alpha manipulation. Bizzare.

...and yet they support ACES colour management and 32 bit exr files... How many photographers use those?

So frustrating. This application is really good in so many respects and could be in every professional studio worldwide. Except it can't because of just few silly issues like this. I really don't get Serif. I really don't. Affinity Photo 2.0 trial uninstalled - and back to Photoshop.

Fundamentally - users should be able to edit any channel with the same tools and flexibility they enjoy in any standard color layer. Its not only game artists who need this. At the end of the day it's just an 'image' and AP is an image editing software, no?

Is there any indication from the devs that this whole area of channel editing and manipulation will be improved? My work centers around 3D CGI and I use a lot of channel manipulation. Affinity is good in the area of 32bit work, and I'd like to use it more, but working with channels feels about as enjoyable as booking an appointment at the dentist...

+1 for this feature.

This one. This is a notable mis-representation of Cryptomatte and how it's intended to be used. Selecting flat colour from a raw Cryptomatte data pass is not 'using Cryptomatte' and Affinity shouldn't be suggesting it is. What's shown is simply a crude hack. A user who knows nothing about this may well come away thinking AP has 'Cryptomatte support'. For the benefit of others reading this topic: It doesn't. Look at the misunderstanding here:

MT-mm, If you're still following this ... I had a similar issue, see: However, after a bit more testing - read down the thread to 'important update' - it looks likely that the issue is EXRs saved from C4Ds multi-pass system. Other exrs I've tried import into AP as expected - as RGB layers. I use Redshift and that has an alternative ' direct' saving mechanism which avoids this issue. I've no idea if Octane has something similar. So: This is seems to be a glitch somewhere on the C4D - AP axis. It isn't 'by design'.

No Cryptomatte = No go for a serious CGI artist. Please add support. And, no - the crude hack of doing a flood fill selection from the raw Cryptomatte colour data isn't acceptable. Please don't propagate poor information like that in your 'id pass' video. That's not the right way to use Cryptomatte, and you know it - I hope.

Chris - an important update: I've generated another EXR using a different method of saving - and that has imported correctly. File attached. So, it seems the issue is probably with the EXR generated by Maxon C4D - my original sample file posted above. If you could pass this info to your devs that would be helpful. Let me explain how these files are generated: The 3D program is Cinema 4D (C4D). The rendering engine is 'Redshift' (https://www.redshift3d.com/). There are two routes to saving a multi-layer EXR in this set up: 1. Via C4D's built in multi-pass file saving system - my first sample file that did not import correctly. or 2. Through Redshift's 'direct' system of file saving - file attached to this post, which did import correctly. Both of these files import correctly into all the other software I use: Photoshop, After Effects, Blackmagic Fusion, etc. But AP seems to have difficulty with the file saved from the C4D multi-pass system. I hope this helps. Rs_test_scene_210827_Rs DIRECT.exr

Thank you Chris, If this is the 'current design' there really seems to be a misunderstanding of how these files are intended to be used. The standard for professional CGI compositing these days is 32bit EXR. AP has decent overall support for 32bit and OCIO / ACES etc - but if it can't open the relevant files in a sensible way all that is for nothing. These files should be opened just like a standard layered Photoshop file, ie: a number of RGB layers. If you need any further example files or info please ask. PS: I suspect that this has 'cropped up a number of times recently' due to the shift to Open Color IO (OCIO) and Academy Color Encoding System (ACES) as the preferred standard for professional video and CGI colour management. OCIO / ACES are 32bit workflows - and 32bit EXR's are the standard file format for that. Photoshop has poor support for OCIO and ACES - but it does open EXR's correctly : ) It will be to your competitive advantage to get this import mis-step fixed asap... Your developers may also want to look at https://www.exr-io.com/ for inspiration on what you should be offering with regard to EXR import features.

If this is 'by design', it suggests those who are doing the designing have no idea how these files are intended to be used.

Unfortunately for AP, I could also just open the file in Photoshop = job done.

Stokerg, Thanks. Just before your response I'd (re)posted this under 'bugs' - and included an example file with that posting. File was generated by Maxon Cinema 4D (C4D) version R21. I'll add these details to the above post. Could this thread be deleted pleae.

Alert: Experienced worker - but AP newbie : ) AP 1.10.1 / Windows 10 /64 I want to use AP to edit multi-layer exr exports from a 3D CGI software. The EXR files typically contain up to 15 layers of information. Each of those layers contain full RGB data. I've attached a test file for your experimentation. + When AP imports these files it: Treats the first layer as an RGB layer = 'Layer one (pixel)' Treats all the other layers as though they were individual colour channels, rather than composite RGB layers..., ie: Layer two [blue] (Pixel) Layer two [green] (Pixel) Layer two [red] (Pixel) So I end up with 43 layers, rather than 15... Am I missing some preference or other setting here? EDIT: The file was generated by Maxon Cinema 4D version R21. The renderer in use was 'Redshift', but the file saving mechanism is through C4D itself using the 'Multi-pass' rendering option. ---------- What should happen: AP needs to interpret these files correctly - importing them with RGB layers - not individual greyscale channels. ---------- This is more than a little disappointing as I purchased AP specifically to work on these types of files. The help manual claims that it can. Rs_test_scene_210826_main_MP_.exr

I'd just like to say thank you to loukash for posting those videos - as a new user I'll certainly be studying them. Nevertheless, the fact that it takes six videos to explain how to manipulate channels seems to suggest that AP needs some serious re-working in this area!

What is telling is that in the first video answer posted above the guy takes around 2.5 mins to demo in Photoshop - and 5.5 mins to demo in AP : )

As a new AP user I found this thread having experienced the 'why can I not copy and paste channels' moment... I'm not a game artist, but I do work in CGI and I frequently need to copy / paste and generally manipulate channel data. I'll have to look into the 'live procedural texture' thing - but at this moment in time this feels like a real AP roadblock to me... +1 for easy copy / paste channel manipulation.

Thanks for the suggestion - but no joy there...

I've got it : ) Thank you !!

Thanks for the heads up - unfortunately my know-how on making a cmd file ends with something like: cd C:\Program Files\Affinity\Photo\ start Photo.exe How would I set a custom OCIO config for AP using this? Any help is most appreciated. Thank you.

Alert: Experienced worker - but AP newbie : ) I want to use AP to edit multi-layer exr exports from a 3D CGI software. The EXR files typically contain up to 15 layers of information. Each of those layers contain full RGB data. When AP imports these files it: Treats the first layer as an RGB layer = 'Layer one (pixel)' Treats all the other layers as though they were individual colour channels, rather than composite RGB layers..., ie: Layer two [blue] (Pixel) Layer two [green] (Pixel) Layer two [red] (Pixel) So I end up with 43 layers, rather than 15... Two questions: 1. Is there a way for AP to interpret all these layers as RGB composite layers on import / open ? or, if not: 2. What is the most efficient way to take: Layer two [blue] (Pixel) Layer two [green] (Pixel) Layer two [red] (Pixel) and make it into: Layer two (Pixel) - ie, a full composite RGB layer. Thanks for any help.

I need to run two OCIO config files - a version 1.x and a version 2.x - because some software I use needs one or the other. I have a Windows OCIO environment variable set to the version 2.x config. In AP colour prefs I had originally set a direct file path to the version 1.x OCIO config - as AP requires. However, having subsequently established the Win environment variable to the version 2.x config... AP automatically decided to use that - which fails as you do not yet support v2.x AP is overriding my direct file path entry without my permission and without any option to correct it as the 'Select' button is now grayed out... Actions required: DO NOT automatically override this, or any other, user preference. Allow a manually entered direct OCIO file path, whether or not an OCIO environment variable exists. If no direct file path is entered, and an OCIO environment variable does - then feel free to use it. Just don't override my path!

Here is a very small (480 x 270 pixel : ) multichannel exr test. I can open this is Photoshop, Fusion, After Effects... but not in AP (Windows desktop) Can you? If so please post and let me know. Rs_test_scene_210811_210811_T165236_main_MP_.exr

Made sure I had the latest Visual C++ runtime libraries, updated graphics card drivers... Same issue. Tried on a completely different machine... Same issue. Has anyone got a test multichannel exr image they can open in AP, that they could upload so I can see if I can open that? Thanks