ayon-core
ayon-core copied to clipboard
Allow review/transcoding of more channels, like "Z", "Y", "XYZ", "AR", "AG" "AB"
Changelog Description
Allow review/transcoding of more channels, like "Z", "Y", "XYZ", "AR", "AG" "AB"
Additional info
Do not error if review or transcoding happens on EXRs that only contain e.g. "Z" channel or "Y" channels. Allow more channel names to pass through.
Fix https://github.com/ynput/ayon-core/issues/989
Testing notes:
- Regular EXR publishes, that contain RGB or RGBA channels (even with named layers) should continue to work as they did.
- EXR with only Z-channel should be transcoded fine.
- EXRs with non RGBA channels or the other esoteric ones should not raise the error.
- [ ] Maya publish render with transcode should still come through fine.
- [ ] Houdini publish render with transcode should still come through fine.
- [ ] Throw esoteric EXRs into Tray Publisher, transcoding should work fine (if ExtractOIIOTranscode settings are configured to actually transcode the files of course.)
Added unittest with some "example channel names". Note that it does not actually go through testing EXR files, only by some channel names.
so it was not actually skipping non RGBA channels.
This by the way, is correct. With this PR it shouldn't skip it.. but it'll try to match as much channel names as possible. Which admittedly I'm still on the fence about whether in the long wrong is a better approach than just skipping them... 🤦 (The AOV filters technically should still apply, that logic hasn't changed here.)
@LiborBatek Can you check how this exact same scenario behaves without this PR?
My assumption this actually broke due to a recent PR here https://github.com/ynput/ayon-core/pull/1276 by @jakubjezek001 because now that filepath has the %04d or alike kind of pattern in the filename, which it looks like it's passing onto the repre dictionary... (which would mean that any publish going through that would essentially be broken in that same scenario?)
Can you please test the same settings but in develop?
Thanks @LiborBatek that does make sense.
Can you do the same but remove Z and uv AOVs and add a specular AOV (something that is known to still render RGB channel names.) Because yes, without this PR Z (and maybe uv) would fail because the EXR file wouldn't have RGBA channel names. Should've thought of this :)
Thanks @LiborBatek that does make sense.
Can you do the same but remove Z and uv AOVs and add a specular AOV (something that is known to still render RGB channel names.) Because yes, without this PR
Z(and maybeuv) would fail because the EXR file wouldn't have RGBA channel names. Should've thought of this :)
Yes, sure...will do another testing round! are u refering using this PR branch or latest develop as with the last testing round btw? as Im not sure sry!
Yes, sure...will do another testing round! are u refering using this PR branch or latest
developas with the last testing round btw? as Im not sure sry!
Latest develop please.
Additional note: Try latest develop to validate if it crashes because of this PR, or the same error happens in develop too.
So when tested with RGB aovs only, in my case:
beauty, specular, diffuse, albedo it worked and DL Publish Job finnishes ok...
here is the DL publish job log: DL-Job_2025-06-12_15-10-22_684ad1becd43efa5fb8d89ef.txt
Im experiencing errors when having enabled OIIO Transcode even tho its not directly related to this PR Im not able to test atm (as I guess OIIO Transcode should be enabled for this PR).
Here are my publish / DL publish job logs:
Maya-publish-report-251103-17-03.json.txt
DL-PublishJob_2025-11-03_16-45-03_6908cdffe30a68594b0c59d9.txt
we have found the possible cause of this issue...so this might be helpful?
https://github.com/ynput/ayon-core/blame/develop/client/ayon_core/plugins/publish/extract_color_transcode.py
Ok, found it. Definitely a bug not introduced by this PR - I'm curious why no productions aren't being affected yet!
@LiborBatek can you review again please?
@iLLiCiTiT can you double check latest code changes? Essentially develop seems to have had a bug where a processed sequence would be stored as 1001-1025%04d in the filepaths of representations instead of the individual files, which made Extract Review fail as soon as it tried to process those paths - or at least, that's what Libor faced.
I have successfully tested using maya and ID P Z AOVs which contains no RGB but Y or other value based data. No failure whatsoever. Also got reviewables too...
Here e.g. Position AOV:
And also when using Tray Publisher and image seq with non RGB data works fine and without a glitch...
So the PR so far LGTM.
maybe @MustafaJafar could test it out within Houdini host app...
@iLLiCiTiT I committed your change - should be good now?