Pixelatedvertex

Apologies, I agree that it does not seem to be working currently -  I thought in my original testing that the grey value was being selected but with a different image I'm clearly seeing that the Loupe shows the grey tone, but picks the colour from the image layer itself when set to 'Global'. When set to 'Current Layer' the Loupe again shows the expected grey but will only pick a 0,0,0 value for me on Windows - so I'll get this logged for further investigation

Thanks, the white fill layer at the bottom the group hierarchy seems to solve this issue, would be nice though, to have this work without weird workarounds, that you have to spend a lot time looking for in the forums.

"By design" often appears to be Affinityspeak for "an unforeseen consequence of the design" rather than "a deliberate design decision".
There is a trick/workaround that makes Passthrough behave as it does in Photoshop: put a white Fill layer (or vector Rectangle covering the entire canvas) with blend mode Multiply as the bottom object inside the group.

I thought grouping arbitrary layers into passthrough group is pure convenience and shouldn't affect resulting picture at all, but it's not true — adjustment layers inside group stop affecting layers below the group. Is it by design or not? If yes, then how is passthrough group different from normal one?

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.
 
 

This really needs to be added.

This would really benefit my workflow. Right now, the color picker in the Brush tool is pretty much useless.

Hi, while I'm not on the beta, cryptomatte is a feature, I would really appreciate for postproduction of renderings. Would implementing this be possible?
For those who don't know this, it's a render output in exr format, that holds masks for all the objects/materials/special tags for the entire scene and is starting to become the standard for post-production in softwares like Nuke or Fusion, it's also become available for Photoshop users thanks to the EXR-IO plugin recently.
It would be great to have this in Affinity Photo as well.
Cheers,
Ivan

Hi eobet, thans for chiming in. As mentioned above, what is shown in the video is not actually the use of a cryptomatte pass, but rather a very crude method of using the diagnostic preview of the cryptomatte pass in the frame buffer of your renderer to do very crude selections and I find that quite off topic, or maybe just a lack of understanding of what cryptomatte is. Currently, I'm using a workflow, where I use Blackmagic Fusion to prepare my alpha masks from the cryptomatte pass to use in Affinity Photo, which brings me to my other problem, which is premultiplication of images with alpha, which I find difficult to manage. And which causes some amount of problems even with my current workflow. But this could only be a problem on my side. I'll try and start another thread on this topic.

This looks really nice at first, but I'm kind of getting the feeling, that this is more of an awkward workaround, than a real implementation of cryptomatte.
First of all, even after downloading the latest version, my cryptomatte passes don't get imported the same way they look in the tutorial and for some reason don't seem to allow me to do flood selections (probably because the values in the cryptomatte pass aren't really colors). My suspicion is, that before comp, they saved the cryptomatte, that is supposed to be an EXR to work properly, as a tiff or png or something from the vray frame buffer (so pretty much just a diagnostic view of the cryptomatte instead of the cryptomatte itself), to get the color info into affinity photo, discarding the data that makes the cryptomatte pass actually useful in the process. You can see at the file tab, that it's a 8-bit file, that could never hold the necessary amount of data for an actual cryptomatte layer to work. The workflow shown here looks more like using render ID passes, which I've seen some people do before cryptomatte became a thing, but's not the same. Please don't get me wrong, this can save you a lot of time setting up masks, but doesn't give you the functionality cryptomatte was supposed to give you.
The way cryptomatte is supposed to work, is, as far as I understand it, that you get a channel for every object/material/tag, that the cryptomatte pass is supposed to capture and you end up with a file, that basically contains an alpha mask for every unique tag in the scene. Sure, the files get huge, but you get really nice selections including antialiasing and sub-pixel details.
Kudos on the spare channels trick though. That is something I didn't know about and it looks super useful!
But back to the topic. There's two problems with the workflow presented here:
+one is, you're limited to 100 objects, that can be stored in the mask, if the Flood select tool slider works with 1% increments, which can be a problem in more complex scenes with 100+ tags, maybe even less, since the colors are assigned randomly and can be pretty close together at times
+the other, much bigger problem, in my opinion, is the selection borders. Since you're not really extracting cryptomatte data, but only doing a flood select on a flat color image, you don't get antialiasing working and you lose definition in areas with very fine detail, often in sub-pixel scales. You'll also probably get nasty selection borders with glowing edges or some kind of ghosting, if you try and do some kind of a more extreme adjustment.
Maybe I'm just clumsy, couldn't get it to work and am misunderstanding something, but I find this video a bit misleading to present it as working with cryptomattes.
 
Cheers,
Ivan

This looks really nice at first, but I'm kind of getting the feeling, that this is more of an awkward workaround, than a real implementation of cryptomatte.
First of all, even after downloading the latest version, my cryptomatte passes don't get imported the same way they look in the tutorial and for some reason don't seem to allow me to do flood selections (probably because the values in the cryptomatte pass aren't really colors). My suspicion is, that before comp, they saved the cryptomatte, that is supposed to be an EXR to work properly, as a tiff or png or something from the vray frame buffer (so pretty much just a diagnostic view of the cryptomatte instead of the cryptomatte itself), to get the color info into affinity photo, discarding the data that makes the cryptomatte pass actually useful in the process. You can see at the file tab, that it's a 8-bit file, that could never hold the necessary amount of data for an actual cryptomatte layer to work. The workflow shown here looks more like using render ID passes, which I've seen some people do before cryptomatte became a thing, but's not the same. Please don't get me wrong, this can save you a lot of time setting up masks, but doesn't give you the functionality cryptomatte was supposed to give you.
The way cryptomatte is supposed to work, is, as far as I understand it, that you get a channel for every object/material/tag, that the cryptomatte pass is supposed to capture and you end up with a file, that basically contains an alpha mask for every unique tag in the scene. Sure, the files get huge, but you get really nice selections including antialiasing and sub-pixel details.
Kudos on the spare channels trick though. That is something I didn't know about and it looks super useful!
But back to the topic. There's two problems with the workflow presented here:
+one is, you're limited to 100 objects, that can be stored in the mask, if the Flood select tool slider works with 1% increments, which can be a problem in more complex scenes with 100+ tags, maybe even less, since the colors are assigned randomly and can be pretty close together at times
+the other, much bigger problem, in my opinion, is the selection borders. Since you're not really extracting cryptomatte data, but only doing a flood select on a flat color image, you don't get antialiasing working and you lose definition in areas with very fine detail, often in sub-pixel scales. You'll also probably get nasty selection borders with glowing edges or some kind of ghosting, if you try and do some kind of a more extreme adjustment.
Maybe I'm just clumsy, couldn't get it to work and am misunderstanding something, but I find this video a bit misleading to present it as working with cryptomattes.
 
Cheers,
Ivan

This looks really nice at first, but I'm kind of getting the feeling, that this is more of an awkward workaround, than a real implementation of cryptomatte.
First of all, even after downloading the latest version, my cryptomatte passes don't get imported the same way they look in the tutorial and for some reason don't seem to allow me to do flood selections (probably because the values in the cryptomatte pass aren't really colors). My suspicion is, that before comp, they saved the cryptomatte, that is supposed to be an EXR to work properly, as a tiff or png or something from the vray frame buffer (so pretty much just a diagnostic view of the cryptomatte instead of the cryptomatte itself), to get the color info into affinity photo, discarding the data that makes the cryptomatte pass actually useful in the process. You can see at the file tab, that it's a 8-bit file, that could never hold the necessary amount of data for an actual cryptomatte layer to work. The workflow shown here looks more like using render ID passes, which I've seen some people do before cryptomatte became a thing, but's not the same. Please don't get me wrong, this can save you a lot of time setting up masks, but doesn't give you the functionality cryptomatte was supposed to give you.
The way cryptomatte is supposed to work, is, as far as I understand it, that you get a channel for every object/material/tag, that the cryptomatte pass is supposed to capture and you end up with a file, that basically contains an alpha mask for every unique tag in the scene. Sure, the files get huge, but you get really nice selections including antialiasing and sub-pixel details.
Kudos on the spare channels trick though. That is something I didn't know about and it looks super useful!
But back to the topic. There's two problems with the workflow presented here:
+one is, you're limited to 100 objects, that can be stored in the mask, if the Flood select tool slider works with 1% increments, which can be a problem in more complex scenes with 100+ tags, maybe even less, since the colors are assigned randomly and can be pretty close together at times
+the other, much bigger problem, in my opinion, is the selection borders. Since you're not really extracting cryptomatte data, but only doing a flood select on a flat color image, you don't get antialiasing working and you lose definition in areas with very fine detail, often in sub-pixel scales. You'll also probably get nasty selection borders with glowing edges or some kind of ghosting, if you try and do some kind of a more extreme adjustment.
Maybe I'm just clumsy, couldn't get it to work and am misunderstanding something, but I find this video a bit misleading to present it as working with cryptomattes.
 
Cheers,
Ivan

Hi, while I'm not on the beta, cryptomatte is a feature, I would really appreciate for postproduction of renderings. Would implementing this be possible?
For those who don't know this, it's a render output in exr format, that holds masks for all the objects/materials/special tags for the entire scene and is starting to become the standard for post-production in softwares like Nuke or Fusion, it's also become available for Photoshop users thanks to the EXR-IO plugin recently.
It would be great to have this in Affinity Photo as well.
Cheers,
Ivan

Hi, while I'm not on the beta, cryptomatte is a feature, I would really appreciate for postproduction of renderings. Would implementing this be possible?
For those who don't know this, it's a render output in exr format, that holds masks for all the objects/materials/special tags for the entire scene and is starting to become the standard for post-production in softwares like Nuke or Fusion, it's also become available for Photoshop users thanks to the EXR-IO plugin recently.
It would be great to have this in Affinity Photo as well.
Cheers,
Ivan

Hi, while I'm not on the beta, cryptomatte is a feature, I would really appreciate for postproduction of renderings. Would implementing this be possible?
For those who don't know this, it's a render output in exr format, that holds masks for all the objects/materials/special tags for the entire scene and is starting to become the standard for post-production in softwares like Nuke or Fusion, it's also become available for Photoshop users thanks to the EXR-IO plugin recently.
It would be great to have this in Affinity Photo as well.
Cheers,
Ivan

Hi, while I'm not on the beta, cryptomatte is a feature, I would really appreciate for postproduction of renderings. Would implementing this be possible?
For those who don't know this, it's a render output in exr format, that holds masks for all the objects/materials/special tags for the entire scene and is starting to become the standard for post-production in softwares like Nuke or Fusion, it's also become available for Photoshop users thanks to the EXR-IO plugin recently.
It would be great to have this in Affinity Photo as well.
Cheers,
Ivan