fix(psd): skip empty layers when reading PSD files

[jeevan6996]

Fixes #5561.

Description

PSD files containing empty layers could fail to open. This change skips layers with zero width or height while preserving the composite image and the order of populated layers. Canvas validation and PSD/PSB dimension limits remain enforced.

Tests

Added checked-in PSD/PSB regression fixtures covering empty layers, subimage ordering and pixel hashes, compressed channels, layer masks, and invalid inputs. The fixture-generation script is retained for reference and maintenance.

The reporter confirmed that the patch fixes all three reported files. (#5562 (comment))

Assisted-by: Codex / GPT-6-Astra

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: jeevan6996 / name: jeevan6996 (c67fef0, c829a3b)

[lgritz]

I think the most important thing that needs to happen here before finalizing the implementation is to decide what is the right behavior for empty layers: to gracefully allow PSD subimages with 0x0 images (presumably holding metadata only?), or whether to just "skip them" and not report their being in the file.

I honestly don't have a preference myself, and am hoping that people who deal with psd files regularly will give us some guidance.

Since OIIO doesn't currently output PSD files, we don't have to worry about situations like oiiotool in.psd -o out.psd and whether that obligates us to handle empty layers in order to faithfully preserve what's in the file. So we have more freedom than we would with other formats that we read and write. Though perhaps we have stronger feelings about what iinfo -v -a file.psd ought to say about a psd file with empty layers?

If we do read them fully, we should implement the supports("noimage") query in the PSD reader.

[lgritz]

I strongly encourage everybody to write your own PR messages using your actual brains. It's the best proof that you understand what you are submitting. At the very least, even if the robot writes the first draft, please edit it yourself to make it seem like a human thought about it and understood it. That means not including information that is obvious, irrelevant, or that is too specific your personal computer.

Since we won't merge a PR without fully passing CI (all tests, all platforms), most of the this information does not need to be stated in the PR description:

Local validation on macOS ARM64 with AppleClang 21:

* The unpatched source reproduces the failure on both supplied PSD files.

* The patched source opens both files, preserving their 5 and 32 subimages.

* Composite pixel hashes match the previously working 3.1.13.0 release.

* `psd`, `psd-colormodes`, and `psd-empty-layers` pass.

* Restoring strict layer validation makes the new regression fail.

* The unpatched 3.1.18.1 reader rejects both generated hidden empty-layer fixtures; the patched reader accepts them.

* Local clang-format and whitespace checks pass.

Command: ctest --test-dir build-psd -R '^psd' --output-on-failure

Result: 100% tests passed, 0 tests failed out of 3

Fork CI passed all 28 jobs, including clang-format, on the current PR commit f5860414a: https://github.com/jeevan6996/OpenImageIO/actions/runs/38301267940

Windows/Linux and sanitizer validation have not been performed locally. The exact file mentioned in the additional hidden-layer comment was not available for testing.

All the important information in this entire part could have been stated as:

"I checked that the images from the issue failed before and read correctly with this patch, and also that the composite pixel hashes exactly match the previously working release for images without empty layers."

[lgritz]

@jessey-git Is this ok and helpful to you as it stands?

[jessey-git]

Yes, as it stands it fixes the issue on the 3 reported files for us.

[lgritz]

LGTM

[lgritz]

@jeevan6996 Before I merge, would you mind please editing the PR description to reflect the final state of the patch and what it does? It doesn't need to describe its history, like "the published patch [does thing it no longer does], then after revision [thing it now does]," and it doesn't need language that appears to be describing your personal machine or the state of the patch while it was still in development, like "the local copy..." or "tests pass locally."

And also please add our required AI tool attribution. It's obvious that an LLM was used, but there was no notice.

[jeevan6996]

• CI status: run 39145910314 finished with 23 passed, one failed and four cancelled jobs.
• Failure: GCC16/C++26 fails in nanobind’s nb_func.cpp because nb_func_check_redefined is unused and -Werror is enabled.
• Evidence: the job tracks nanobind master; commit a1c8924 added that helper after OIIO’s earlier successful upstream run.
• Conclusion: evidence points to a dependency regression rather than the PSD change, but no controlled unchanged-base rebuild has been performed.

Failed run (https://github.com/jeevan6996/OpenImageIO/actions/runs/39145910314).

Nanobind change (wjakob/nanobind@a1c8924).

[lgritz]

• CI status: run 39145910314 finished with 23 passed, one failed and four cancelled jobs.

  • Failure: GCC16/C++26 fails in nanobind’s nb_func.cpp because nb_func_check_redefined is unused and -Werror is enabled.

  • Evidence: the job tracks nanobind master; commit a1c8924 added that helper after OIIO’s earlier successful upstream run.

  • Conclusion: evidence points to a dependency regression rather than the PSD change, but no controlled unchanged-base rebuild has been performed.

Failed run (https://github.com/jeevan6996/OpenImageIO/actions/runs/39145910314).

Nanobind change (wjakob/nanobind@a1c8924).

This is obviously written by a machine. Here's how I would have composed this comment:

"The 'bleeding edge' CI test is failing because of a recent change upstream in nanobind. It's unrelated to this PR."

[lgritz]

LGTM! Thanks for this fix, and for going through a few iterations to get it just right.