ExtractOIIOTranscode strange behavior

timsergeeff · 3 October 2025 09:27

Hi, i wornder if im duing something wrong? I’m rendering acescg from houdini and I’m waiting oiio transcode of my file. however ayon gives oiio both view and colorspace and since view is srgb my file will not be converted, just resaved. Why oiio uses view and not colorspace and how to change it?

2025-10-01 15:57:05:  0: STDOUT: WARNING:pyblish.ExtractOIIOTranscode:Both source display/view and source_colorspace provided. Using source display/view pair and ignoring source_colorspace.
2025-10-01 15:57:05:  0: STDOUT: DEBUG:pyblish.ExtractOIIOTranscode:Conversion command: C:\Users\cg0\AppData\Local\Ynput\AYON\addons_resources\ayon_third_party\oiio_windows_83e412e9\bin\oiiotool.exe --nosoftwareattrib --colorconfig Z:/admin_dev/Ayon_shared_dont_touch/Ocio_config/config.ocio -i Z:/!!!work_w_ayon/Detraleks/sequences/sq01/sh080/work/rendering/render\renderRenderingMain.1070.exr --ch R=R,G=G,B=B,A=A --ociodisplay:inverse=1:subimages=0 ACES sRGB --colorconvert:subimages=0 scene_linear Output - sRGB -o C:\Users\cg0\AppData\Local\Temp\ay_tmp_d3z4gj89\renderRenderingMain.1070.png
2025-10-01 15:57:06:  0: STDOUT: INFO:pyblish.ExtractOIIOTranscode:oiiotool WARNING: -o : png does not support multiple subimages for C:\Users\cg0\AppData\Local\Temp\ay_tmp_d3z4gj89\renderRenderingMain.1070.png
2025-10-01 15:57:06:  0: STDOUT: DEBUG:pyblish.ExtractReview:[{'colorspaceData': {'colorspace': 'ACES - ACEScg', 'config': {'path': 'Z:/admin_dev/Ayon_shared_dont_touch/Ocio_config/config.ocio', 'template': 'Z:/admin_dev/Ayon_shared_dont_touch/Ocio_config/config.ocio'}, 'display': 'ACES', 'view': 'sRGB'}, 'ext': 'exr', 'files': 'renderRenderingMain.1070.exr', 'fps': 25.0, 'frameEnd': 1070, 'frameStart': 1070, 'name': 'exr', 'stagingDir': 'Z:/!!!work_w_ayon/Detraleks/sequences/sq01/sh080/work/rendering/render', 'tags': []}, {'colorspaceData': {'colorspace': 'Output - sRGB', 'config': {'path': 'Z:/admin_dev/Ayon_shared_dont_touch/Ocio_config/config.ocio', 'template': 'Z:/admin_dev/Ayon_shared_dont_touch/Ocio_config/config.ocio'}, 'display': 'ACES', 'view': 'sRGB'}, 'ext': 'png', 'files': 'renderRenderingMain.1070.png', 'fps': 25.0, 'frameEnd': 1070, 'frameStart': 1070, 'name': 'sRGB_png', 'stagingDir': 'C:\\Users\\cg0\\AppData\\Local\\Temp\\ay_tmp_d3z4gj89', 'tags': ['review'], 'outputName': 'sRGB_png'}]
2025-10-01 15:57:06:  0: STDOUT: DEBUG:pyblish.ExtractReview:Processing instance "renderRenderingMain"

timsergeeff · 3 October 2025 09:43

For information my exr is from karma houdini and aces 1.2

actualy i see what a command and command looks correct, but i get this and for now idk why

on the left is from houdini after oiio on the right- from manual color convert

by the way exect same command lauched from cmd gives an error

C:\Users\timse>C:\Users\timse\AppData\Local\Ynput\AYON\addons_resources\ayon_third_party\oiio_windows_83e412e9\bin\oiiotool.exe --nosoftwareattrib --colorconfig Z:/admin_dev/Ayon_shared_dont_touch/Ocio_config/config.ocio -i Z:/!!!work_w_ayon/Detraleks/sequences/sq01/sh080/work/rendering/render\renderRenderingMain.1070.exr --ch R=R,G=G,B=B,A=A --ociodisplay:inverse=1:subimages=0 ACES sRGB --colorconvert:subimages=0 scene_linear Output - sRGB -o C:\Users\timse\Desktop\renderRenderingMain.1070.png
oiiotool ERROR: colorconvert : Color space 'Output' could not be found.
Full command line was:
> oiiotool.exe --nosoftwareattrib --colorconfig Z:/admin_dev/Ayon_shared_dont_touch/Ocio_config/config.ocio -i Z:/!!!work_w_ayon/Detraleks/sequences/sq01/sh080/work/rendering/render/renderRenderingMain.1070.exr --ch R=R,G=G,B=B,A=A --ociodisplay:inverse=1:subimages=0 ACES sRGB --colorconvert:subimages=0 scene_linear Output - sRGB -o C:\\Users\\timse\\Desktop\\renderRenderingMain.1070.png

using command like this solves color space name issue ( uning alt name wo spaces)

C:\Users\timse\AppData\Local\Ynput\AYON\addons_resources\ayon_third_party\oiio_windows_83e412e9\bin\oiiotool.exe --nosoftwareattrib --colorconfig Z:/admin_dev/Ayon_shared_dont_touch/Ocio_config/config.ocio -i Z:/!!!work_w_ayon/Detraleks/sequences/sq01/sh080/work/rendering/render\renderRenderingMain.1070.exr --ch R=R,G=G,B=B,A=A --ociodisplay:inverse=1:subimages=0 ACES sRGB --colorconvert:subimages=0 scene_linear color_picking -o C:\Users\timse\Desktop\renderRenderingMain.1070.png

but picture will be the same as from ayon

but if i remove

–ociodisplay:inverse=1:subimages=0 ACES sRGB

then it wil start to look correct with this like commang

C:\Users\timse\AppData\Local\Ynput\AYON\addons_resources\ayon_third_party\oiio_windows_83e412e9\bin\oiiotool.exe --nosoftwareattrib --colorconfig Z:/admin_dev/Ayon_shared_dont_touch/Ocio_config/config.ocio -i Z:/!!!work_w_ayon/Detraleks/sequences/sq01/sh080/work/rendering/render\renderRenderingMain.1070.exr --ch R=R,G=G,B=B,A=A --ociodisplay:inverse=1:subimages=0 ACES sRGB --colorconvert:subimages=0 scene_linear color_picking -o C:\Users\timse\Desktop\renderRenderingMain.1070.png

so the qestion is does this is nessesary? and if it is why it break conversion?

–ociodisplay:inverse=1:subimages=0 ACES sRGB

for me it looks like that it does two convercions idk why so the second one will never be srgb because the first now is not aces cg

i think logic from recent pr is incorrect

as i see it tries to convert my exr to acescg and after to srg, but why are we converting exr to acescg (it already is)

and i think colorconvert cant use view and display

https://openimageio.readthedocs.io/en/latest/oiiotool.html#cmdoption-colorconvert

previously it was aces 1.2 (from top to this place)
now i’m expimenting with aces 1.3 and i wonder why we dont provide colorspace to ociodisplay function? and why do we need to apply ocio display to image at all??? For me it works now like that: image exr acecg-> apply inverce display untonemap(idk why untonemap either)->convert from acecg with invert untonemap to display?( not color space)

\Users\cg0\AppData\Local\Ynput\AYON\addons_resources\ayon_third_party\oiio_windows_83e412e9\bin\oiiotool.exe --nosoftwareattrib --colorconfig Z:/shared/Ayon_shared/OCIO/studio-config-v1.0.0_aces-v1.3_ocio-v2.0.ocio -i Z:/!!!work_w_ayon/Detraleks/sequences/sq01/sh080/work/rendering/render\renderRenderingMain.1070.exr --ch R=R,G=G,B=B,A=A --ociodisplay:inverse=1:subimages=0 sRGB - Display Un-tone-mapped --colorconvert:subimages=0 sRGB - Display ACES 1.0 - SDR Video -o C:\Users\cg0\AppData\Local\Temp\ay_tmp_hsy8mnuj\renderRenderingMain.1070.png

for now it makes no sence for me.

why do we need to care about source display and view at all? i dont get it, because in file stored only raw acescg (or just aces) data and we just need to convert it to colorspace of choice or display and view of choice

i see the lask step whitch doing exactley what i decribed but it will never go to that step because some view and display will be pressented in renders all the time( even if data is incorrect)

i’m just intrested why do we need to apply reverce display fuctions at all?

soo now i see why you’ve done like that, but why my exr have display and view when comming from houdini?

so this data is not from file, this is already inside metadata.json at the very start of a render

but so from where?

jiri.sin · 5 October 2025 18:57

Just speculating here, but maybe the change is from the latest Core 1.6.1.

This PR broke previously working ACES 1.2 OCIO 1.0 Ayon project setting for OIIO transcode for me. I didn’t find time yet to investigate deeper.

github.com/ynput/ayon-core

Handles OCIO shared view token

ynput:develop ← ynput:bugfix/ocio-v2-aces1.3-display-resolving-error

opened 03:57PM - 09 May 25 UTC

jakubjezek001

+223 -40

## Changelog Description - The OCIO config can return a special token "<USE_DIS…PLAY_NAME>" as the colorspace name for a display view. This commit - implements handling for this token, replacing it with the display name if the token is found. This is fixing compatibility for >= Aces 1.3 configs. - updating colorspace conversion method to support source and target colorspace handling ## Additional info - I had been doing tests in regards of implementation for new ocio configs https://github.com/ynput/ayon-core/pull/1115. Following issue had been blocking me from farther tests. - the `convert_colorspace` function was marked as deprecated and new function `oiiotool_transcode` with improved set of input args were added. ## Testing notes: 1. ExtractOIIOtrancode presets should work as they were before. 2. Use following snippet in any of your DCC or Tray Console ``` from ayon_core.pipeline.colorspace import get_display_view_colorspace_name ocio_config_path = "<path to any of new aces1.3 configs from ayon-ocio addon >=1.2.1>" display = "sRGB - Display" view = "ACES 1.0 - SDR Video" resolved_colorspace = get_display_view_colorspace_name( ocio_config_path, display, view, ) print(resolved_colorspace) ``` 3. This should be printing `sRGB - Display` but before it was returning `<USE_DISPLAY_NAME>`. 4.

Maybe try downgrading Core addon and see if it helps?

timsergeeff · 6 October 2025 09:57

maybe yes but for now i cant find from code where my display and view was popullated with imaginary data (i’ve never used un-tone-mapped) so i thing json just creates some defaults idk

jiri.sin · 6 October 2025 15:15

It might be that Core Settings can store Target Colorspace and Target Display 7 View, but only show one or other depending on Transcoding type.

This might be the code:

github.com/ynput/ayon-core

client/ayon_core/lib/transcoding.py

2a32d56bc


      
          if source_view and source_display:
              if target_colorspace:
                  # This is a two-step conversion process since there's no direct
                  # display/view to colorspace command
                  # This could be a config parameter or determined from OCIO config
                  # Use temporarty role space 'scene_linear'
                  color_convert_args = ("scene_linear", target_colorspace)
              elif source_display != target_display or source_view != target_view:
                  # Complete display/view pair conversion
                  # - go through a reference space
                  color_convert_args = (target_display, target_view)
              else:
                  color_convert_args = None
                  logger.debug(
                      "Source and target display/view pairs are identical."
                      " No color conversion needed."
                  )
          
              if color_convert_args:
                  oiio_cmd.extend([

This file has been truncated. show original

timsergeeff · 6 October 2025 18:22

for me issue is that generated json has display and view but it can’t be. So conversion will be from colorspace (aces cg) to display view, but according to code if a file has display and view baked it it tries to deview and dedisplay image) so its broken not in color convert stage but in “add color tags to representation” stage

timsergeeff · 7 October 2025 19:38

this is short fix for colorconvert fuction that is not support display and view

but i cant understand how to fix husk providing wrong data in first place?

why it tells ayon that i use sRGB - Display un-tone-mapped when houdini has ACES 1.0-sdr display inside. Maybe this is a problem with render on farm only when houdini is launched wo interface…

actualy i figured it out! but it need some work to do it right (code and logic changes

this thing causes houdini to return default values NOT actual values from ocio config

so for now i will just do like that and it suppose to work with fix ive done earlier (default was un-tone-mapped and this was a problem)

but we need to change houdini logic not to populate wrong values

BigRoy · 8 October 2025 10:27

So, in your case you were expecting Raw… where did you configure Raw in Houdini for us to know what value to query for? As far as I in the scenefile itself you can set them per viewport. There is no clear “this is the view state that I want” other than the OCIO defaults to rely on. If you have the code that can reliably query the Display and View the user DOES use, then please provide it and then it’s an easy fix.

timsergeeff · 8 October 2025 11:09

There was multiple errors and issues:

incorrect command for display/view conversion because colorconvert in oiiotool cant use view and display. This pr fixes it
using correct func for view display conversion by timsergeeff · Pull Request #1467 · ynput/ayon-core · GitHub
this code in houdini addon is incorrect

image651×240 15.1 KB

because hou.color.ociodefaultDisplay and hou.ocio.deafault view will weturn not my display and view but DEAFAULT from ocio file

so i’ve just take yours ocio config and there was exactely un-tone-mapped for view and i’ve changed it to raw and hou.ocio.deafault view gives me raw now

i know this is just work around and not a sollution but at least i found a problematic spot in houdini addon. Had no time to find proper way to use hou to give proper and not default values.

so at the end for some reason houdini addon takes default values from ocio but rendered files must not contain view and display at all and in hodudini i cant find any spot where can i change the view exept ocio settings that doig it glogaly for viewers but not for render, so render will always be raw but addon things that default view and display from ocio config are ours render view and display

BigRoy · 8 October 2025 12:26

Correct - the question is what is your display and view? Are you referring to the one you’ve applied in your viewport, if so… you can have multiple viewports, each with differing display/view applied, right? Or where did you apply your display & view you expected it to be taken from?

timsergeeff · 8 October 2025 13:41

my display srgb display aces-sdr1.0 and we all can select it once for all displays in houdini

this is the problem! im doing nothing so my exr will not have display and view applied but ayon thinks it is

BigRoy · 8 October 2025 13:54

There is a misconception here - AYON does not think it is. Unless recent change by @jakub.jezek made it so. But essentially, AYON stores what Display/View the content is set up to be viewed in inside the DCC, used for generated a transcoded image that looks 1:1 to what you’re viewing inside the DCC. The display view in this case does not define the source - but the target output. I believe a recent PR was intended to clarify that by naming them target_display and target_view if I’m not mistaken. Right @mustafa_jafar ?

Anyway, it sounds like you don’t want it applied at all… which sounds like what you’re looking for is just not running the transcode plug-in - which you can configure just fine.

timsergeeff · 8 October 2025 16:17

No it’s not. It stores default values from ocio file (if we are talking houdini)

No) ayon tries to deview and dedisplay the image with stored data (default from ocio)

and the logic of recent pr for core almost works (with my pr) because problem not in color conversion logic itself, the problem is in json written for deadline whitch will have default ocio view and display comming from houdini plugin (but rendered files does not have nor view nor display, they are just aces cg)

i want transcode plugin! Thats why i’m tring to do))

Now the flow is like that : houdini creates json with source display and view ->ayon publishes and tries to deview and dedisplay->ayon converts to desired ocio view and display-> publish finish.

the problem is that source exr doesnt have source view and display (but ayon thinks it has) so thats why istead of “acescg->srgb -display aces 1.0-sdr” it goes “acescg->srgb-display un-tone-mapped->srgb -display aces 1.0-sdr” whitch is obviously is wrong and this happens because houdini plugin stores wrong data in json

thats why i changed default ocio display to raw in ocio file. It changes nothing in term of work but now houdini provides raw display and trip will be “acescg->srgb-display raw->srgb -display aces 1.0-sdr” ( so basicaly it will not do first conversion)

Is it clear now?

mustafa_jafar · 11 October 2025 00:03

Yes, this one Handles OCIO shared view token #1268

I was reading through this discussion and I think it mentions the same issue mentioned in this comment Handles OCIO shared view token by jakubjezek001 · Pull Request #1268 · ynput/ayon-core · GitHub on the linked PR above.

timsergeeff · 11 October 2025 09:49

yes looks like this comment exactly about problem there as source display and view was inversively applied to raw footage