Extract Image: Export as flatten image for exr

[moonyuet]

Changelog Description

This PR is to make sure the image would be exported as flatten image if user choose to use exr. This is to avoid the potential bug where users would save the multiple layers in EXR.
Resolve #136

Additional review information

You need to install extension.zxp to make the flattern option work.

Testing notes:

1. Make sure Extract Image enabled in the addon-setting and set exr as image format in ayon+settings://photoshop/publish/ExtractImage/formats
2. Launch PS
3. Create Image
4. Publish

[Copilot]

🟡 Changes recommended

The current EXR flattening can permanently flatten the user’s original document in some cases, which is a destructive behavior that should be avoided.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

This PR targets issue #136 by ensuring EXR exports are flattened to avoid failures when publishing selected layers (hidden layers / multi-layer EXR export edge cases) in the Photoshop extension host script.

Changes:

• Adjust EXR export flow to pass the working document into saveEXR() and flatten before saving.
• Bump the extension bundle version in the CSXS manifest.

File summaries

File	Description
client/ayon_photoshop/api/extension/host/index.jsx	Updates EXR saving to flatten before export (via saveEXR(savePath, doc)).
client/ayon_photoshop/api/extension/CSXS/manifest.xml	Increments extension bundle version (1.1.17 → 1.1.18).

Review details

• Files reviewed: 2/3 changed files
• Comments generated: 2
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

🟡 Changes recommended

The new EXR flattening is implemented in a block whose gating logic can unintentionally trigger for non-EXR exports and still won’t flatten 32-bit EXR exports, risking regressions and incomplete bug resolution.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

• Files reviewed: 2/3 changed files
• Comments generated: 1
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

The EXR export path still relies on implicit duplicate() side effects for which document is active, risking saving/flattening the wrong document during saveEXR() execution.

Review details

Suppressed comments (1)

client/ayon_photoshop/api/extension/host/index.jsx:339

• saveEXR() saves via executeAction('save', ...), which targets the active Photoshop document. In this EXR branch you manipulate a duplicated document via the local doc variable, but never explicitly activate it, so the export can accidentally save the wrong document depending on duplicate() side effects. Make the duplicate the active document explicitly before flattening/exporting.

            doc = doc.duplicate();
            is_temp_doc = true;
            doc.bitsPerChannel = BitsPerChannelType.THIRTYTWO;
            doc.flatten();
        }

• Files reviewed: 2/3 changed files
• Comments generated: 0 new
• Review effort level: Lite

[BigRoy]

I don't think this entirely the right fix - we may still want to export EXRs with layers, right? Is force flattening it really what we want to do?

Is the failure in the error report due to the special character in the layer name? Like ℗ imageRwe.lib_texture?

Executing: C:\Users\Kayla\AppData\Local\Ynput\AYON\addons_resources\ayon_third_party\ffmpeg_windows_3d2b8241\bin\ffmpeg.exe -layer ℗ imageRwe.lib_texture -i C:\Users\Kayla\AppData\Local\Temp\ay_tmp_3zkrba5g\il_lib_art_v039_test_new_creator_image_image_image_image.exr -filter:v "scale=1920x1080:flags=lanczos:force_original_aspect_ratio=decrease,pad=1920:1080:(ow-iw)/2:(oh-ih)/2:#000000,setsar=1" -y C:\Users\Kayla\AppData\Local\Temp\ay_tmp_3zkrba5g\il_lib_art_v039_test_new_creator_image_image_image_image_png.png

Failing on:

[exr @ 0000025285466d40] Unsupported channel ℗ imageRwe.lib_texture.A.
[exr @ 0000025285466d40] Unsupported channel ℗ imageRwe.lib_texture.B.
[exr @ 0000025285466d40] Unsupported channel ℗ imageRwe.lib_texture.G.
[exr @ 0000025285466d40] Unsupported channel ℗ imageRwe.lib_texture.R.
[exr @ 0000025285466d40] Missing red channel.
[exr @ 0000025285466d40] Missing green channel.
[exr @ 0000025285466d40] Missing blue channel.
[exr_pipe @ 0000025285454dc0] Could not find codec parameters for stream 0 (Video: exr, none): unspecified size

Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options
Input #0, exr_pipe, from 'C:\Users\Kayla\AppData\Local\Temp\ay_tmp_3zkrba5g\il_lib_art_v039_test_new_creator_image_image_image_image.exr':
  Duration: N/A, bitrate: N/A
  Stream #0:0: Video: exr, none, 25 fps, 25 tbr, 25 tbn
[AVFormatContext @ 00000252854ab600] Unable to choose an output format for 'imageRwe.lib_texture'; use a standard extension for the filename or specify the format manually.
[out#0 @ 00000252854aaf40] Error initializing the muxer for imageRwe.lib_texture: Invalid argument
Error opening output file imageRwe.lib_texture.
Error opening output files: Invalid argument

I'm also a bit confused why it's trying to "open" output file imageRwe.lib_texture.

[moonyuet]

I don't think this entirely the right fix - we may still want to export EXRs with layers, right? Is force flattening it really what we want to do?

This is not the best solution for sure and usually the issue can be fixed when you copy your layers into new project files. I am not the only one who hits the issue, @LiborBatek also got some files hit that error too.
But why does Extract Review not work in existing scene? There must be something going on, and I dont think it is related to Extract Review. It does work for other DCCs and png image in Photoshop.

Coming up with these changes, I have evaluated the questions below:

1. When we are exporting certain layers, are we exporting image with layers which are compatible with other DCCs?
2. Can these images with those layers be passing through those transcoding, review, burnin?
3. Why are they not able to pass through ffmpeg for Extract Review? Why are there many weird names in channel layers in the publish report? Where do they come from? Are they coming from the naming of your group node or the naming of the nested group with tons of layers?

The main concern is whether it affects any adjustment on the loaded textures/AOVs.
I dont think it is potentially affecting loaded textures as they are using channel layers to distribute the texture(I am talking about Roughness-AO-Metallic maps in that case). Flatten does not flatten channel layers.
And for the render AOVs -> why are you messing up the multipass AOVs in Photoshop?

[BigRoy]

@LiborBatek can you answer above questions - I'm fine with this 'fix' but I consider it more of a hotfix. Because we may actually want to write out EXRs while maintaining the layers which are now forced to be flattened out, but maybe it's not the top priority - that'd be for you to provide some thoughts on then.

[LiborBatek]

Ok, here is my pov...

There is dedicated PS addon product called ImageFlatten and as the name suggests it should give flattened image of any present/visible layer in the PSD (active workfile) as simple as that. The reasoning been sometimes its all is needed - taking anything and output it as flat image (basically performing merge visible layers afaik). The beauty is that its super simple...just trigger the publish while having this "auto image" instance enabled...originated from clients' requested feature back then.

My recent experience with this product have been - it fails when having configured output to EXR instead of the defaults we are having in ayon-photoshop which are png and jpg.

It would be desirable this auto image or implicit publish instance works also in the occasion mentioned above...

Regarding workfile layers and how to treat 'em - we should follow the existing procedures/principles we are already using.

Maybe there is a one more thing to discuss and that is AOVs and what to do if any present in the PSD file...cant tell atm as Im not much aware how PS treat multilayer EXR but the safest could be to maintain those in workfile repre for sure. We could maybe add multilayer EXR output to the settings or on the instance - now Im really shooting air / not really aware how its treated in PS.

I hope this enlight it a bit and brought my opinion to the table.