[BUG] 16-bit psd files saved from photoshop not showing subimages #3900
Comments
|
Cross-posting the comment here. I explain in the discussion page why this isnt working and how it could be implemented: |
This was referenced Mar 27, 2024
lgritz
added a commit
that referenced
this issue
Apr 2, 2024
As mentioned in #4205, #3900 and #3910 (reply in thread) OpenImageIO previously did not support reading of 16- and 32-bit files beyond their merged image data section. I have now implemented this by: 1. Adding support for reading layer info from the "Lr16" and "Lr32" Tagged Blocks as well as adding additional checks to the regular layer info section 2. Implemented the Zip and ZipPrediction compression codec which is required to read these files as that is photoshops preferred compression codec for those bitdepths Due to the way the Zip data is stored (per channel but not per scanline) the current implementation reads the whole channel into a buffer which is then memcpy'd from by calls to `read_native_scanline()`. The buffer gets cleared on deletion of the `PSDInput` object --------- Signed-off-by: EmilDohne <86836589+EmilDohne@users.noreply.github.com> Signed-off-by: Larry Gritz <lg@larrygritz.com> Co-authored-by: Larry Gritz <lg@larrygritz.com>
|
@EmilDohne Is this issue fully solved by #4208? Can this one be closed? |
lgritz
added a commit
to lgritz/OpenImageIO
that referenced
this issue
Apr 2, 2024
…mySoftwareFoundation#4208) As mentioned in AcademySoftwareFoundation#4205, AcademySoftwareFoundation#3900 and AcademySoftwareFoundation#3910 (reply in thread) OpenImageIO previously did not support reading of 16- and 32-bit files beyond their merged image data section. I have now implemented this by: 1. Adding support for reading layer info from the "Lr16" and "Lr32" Tagged Blocks as well as adding additional checks to the regular layer info section 2. Implemented the Zip and ZipPrediction compression codec which is required to read these files as that is photoshops preferred compression codec for those bitdepths Due to the way the Zip data is stored (per channel but not per scanline) the current implementation reads the whole channel into a buffer which is then memcpy'd from by calls to `read_native_scanline()`. The buffer gets cleared on deletion of the `PSDInput` object --------- Signed-off-by: EmilDohne <86836589+EmilDohne@users.noreply.github.com> Signed-off-by: Larry Gritz <lg@larrygritz.com> Co-authored-by: Larry Gritz <lg@larrygritz.com>
lgritz
added a commit
to lgritz/OpenImageIO
that referenced
this issue
Apr 2, 2024
…mySoftwareFoundation#4208) As mentioned in AcademySoftwareFoundation#4205, AcademySoftwareFoundation#3900 and AcademySoftwareFoundation#3910 (reply in thread) OpenImageIO previously did not support reading of 16- and 32-bit files beyond their merged image data section. I have now implemented this by: 1. Adding support for reading layer info from the "Lr16" and "Lr32" Tagged Blocks as well as adding additional checks to the regular layer info section 2. Implemented the Zip and ZipPrediction compression codec which is required to read these files as that is photoshops preferred compression codec for those bitdepths Due to the way the Zip data is stored (per channel but not per scanline) the current implementation reads the whole channel into a buffer which is then memcpy'd from by calls to `read_native_scanline()`. The buffer gets cleared on deletion of the `PSDInput` object --------- Signed-off-by: EmilDohne <86836589+EmilDohne@users.noreply.github.com> Signed-off-by: Larry Gritz <lg@larrygritz.com> Co-authored-by: Larry Gritz <lg@larrygritz.com>
|
@igritz yes, this is now fixed! |
|
Fixed by #4208 |
lgritz
added a commit
to lgritz/OpenImageIO
that referenced
this issue
Apr 2, 2024
…mySoftwareFoundation#4208) As mentioned in AcademySoftwareFoundation#4205, AcademySoftwareFoundation#3900 and AcademySoftwareFoundation#3910 (reply in thread) OpenImageIO previously did not support reading of 16- and 32-bit files beyond their merged image data section. I have now implemented this by: 1. Adding support for reading layer info from the "Lr16" and "Lr32" Tagged Blocks as well as adding additional checks to the regular layer info section 2. Implemented the Zip and ZipPrediction compression codec which is required to read these files as that is photoshops preferred compression codec for those bitdepths Due to the way the Zip data is stored (per channel but not per scanline) the current implementation reads the whole channel into a buffer which is then memcpy'd from by calls to `read_native_scanline()`. The buffer gets cleared on deletion of the `PSDInput` object --------- Signed-off-by: EmilDohne <86836589+EmilDohne@users.noreply.github.com> Signed-off-by: Larry Gritz <lg@larrygritz.com> Co-authored-by: Larry Gritz <lg@larrygritz.com>
|
Awesome news! Thanks so much @EmilDohne and @lgritz ! |
|
I'm backporting this so it will be in (next month's) release patch. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When using the python API to get subimage names or oiiotool to get info on all the subimages, a 16-bit photoshop file saved from windows photoshop shows no subimages. Saving the same photoshop file as an 8-bit file then shows all the layers. A little testing and it appears that 32-bit psd files exhibit the same behavior as 16-bit.
The attached psd files have 4 layers/subimages. Saved from photoshop 21.1.2 on windows.
PSD files saved from Krita on linux as 16-bit images work fine, only psds from photoshop seem to show this behavior
To Reproduce
Run oiiotool to see all subimage info for the 16-bit psd file vs. the 8-bit file
oiiotool --info -v -a color_squares_small_16bit.psdThe 8-bit file shows all the subimages while the 16-bit file does not.
Expected behavior
Show all relevant image info comparable to what the same file saved as 8-bit shows.
Evidence
oiiotool --info -v -a color_squares_small_16bit.psdoiiotool --info -v -a color_squares_small_8bit.psdPlease find reproducing images attached.
Platform information:
color_squares_small.zip
The text was updated successfully, but these errors were encountered: