This is really a question about controlling PNG output format but it is triggered by a slap comp workflow.

The aim is to have the output file be 8-bit sRGB and look like the scene view. When we render a scene using Karma XPU and output with the USD render ROP, the resulting file looks just like the scene view:



When we use a chromatic aberration COP node, the two look the same again:



But when we use a glow COP node, the output file is a lot brighter than the scene view:



There is nothing in the documentation to suggest that the glow COP node is somehow different. Why is there this discrepancy and how can we control the PNG output encoding/colour space/gamma?

The graphs:

RGBA with PNG is a bit weird - PNG has non-associated alpha, IIRC, but how people actually write or read it is pretty random.

First pass would be to do a RGBA -> RGB before saving as png to verify your colour space is right. On ROP Image, usually Color Space Conversion: "Bake to Display/View" will get you the WYSIWYG as it will handle any tone-mapping your display may have. If the RGB looks right, then it is an associated alpha issue. On ROP IMage, the Optimization tab has PNG/TGA Pre Multiplication. Try changing to raw and see if your viewer is happier.

Glow I think is building an emissive RGBA which can't be represented as an unassociated alpha, so you'll have to pick a non-zero alpha and bake it down.

jlait
RGBA with PNG is a bit weird - PNG has non-associated alpha, IIRC, but how people actually write or read it is pretty random.

First pass would be to do a RGBA -> RGB before saving as png to verify your colour space is right. On ROP Image, usually Color Space Conversion: "Bake to Display/View" will get you the WYSIWYG as it will handle any tone-mapping your display may have. If the RGB looks right, then it is an associated alpha issue. On ROP IMage, the Optimization tab has PNG/TGA Pre Multiplication. Try changing to raw and see if your viewer is happier.

Glow I think is building an emissive RGBA which can't be represented as an unassociated alpha, so you'll have to pick a non-zero alpha and bake it down.

Thank you for the reply!

Doing a ROP Image output directly from the COP network outputs the correct PNG file. The issue is with doing the PNG output from the USD Render ROP in Solaris. There are no colour space or PNG settings on the USD Render ROP node.

I tried out some ideas with alpha in Copernicus, to see if anything changes in the ROP Image output. We already apply the slap comp only to the RGB channels and manually trying to build an RGBA image from the data using a const Alpha seems to have no effect. Neither does changing premultiply settings on the ROP Image node, suggesting that this is not a variable in the current issue.

The aim is to have a single button solution where "Save to disk" will do a full Karma render, followed by a slap comp and finally output to disk. Having to use a separate ROP Image inside Copernicus would complicate that, where the render and compositing are two separate actions and the COP network would work with "the last render" which is a potential source of user error. (From my beginner understanding of these systems)

Yes, having to use a ROP Image rather defeats the purpose of a having slapcomp.

If you can assemble this into a .hip and submit as a bug to support we can look into it, there could be several different things going wrong at this point.