Fix #107212: Fix file browser thumbnails for images #107515

Jesse Yurkovich · 2023-05-01T22:10:26+02:00

Jesse Yurkovich commented

2023-05-01 22:10:26 +02:00

Fix several issues found while investigating missing browser thumbnails.

TIFF, PSD, and PNG now use their old file check code. This is due to
OIIO not having an early-out check within .open. Calling .open
required a large portion of the file to be available (more than 8192
bytes). The code here can be removed in the future if/when a new API is
available which alleviates this problem.[1]

PSD files often carry along a large blob of ICCProfile metadata.
Attempting to roundtrip this metadata when we cache the thumbnail to
.png was leading to problems. We suppress this metadata now as ICC
profiles are not supported in general and are quite large.

Lastly, even after the mentioned new API is available, OIIO will want to
validate the full header of some file formats. DPX is the largest at a
full 2048 bytes so we must have this as our minimum now too. OS's should
be servicing this read call just as efficiently as when using 64. I
could spot no performance difference here at least.

This was missed during development because Blender will cache thumbnails
into a special .thumbnails directory and the images I was using to test
had already been cached there.

[1] I plan on submitting a PR to OIIO to allow their ImageInput::valid_file API to take in a memory proxy. If that is accepted we would gain two nice things:

We'd be able to once again remove the custom TIFF, PSD, and PNG header checks
It would be more efficient than calling .open like we do today for some of the other formats

Fix several issues found while investigating missing browser thumbnails. TIFF, PSD, and PNG now use their old file check code. This is due to OIIO not having an early-out check within `.open`. Calling `.open` required a large portion of the file to be available (more than 8192 bytes). The code here can be removed in the future if/when a new API is available which alleviates this problem.[1] PSD files often carry along a large blob of ICCProfile metadata. Attempting to roundtrip this metadata when we cache the thumbnail to .png was leading to problems. We suppress this metadata now as ICC profiles are not supported in general and are quite large. Lastly, even after the mentioned new API is available, OIIO will want to validate the full header of some file formats. DPX is the largest at a full 2048 bytes so we must have this as our minimum now too. OS's should be servicing this read call just as efficiently as when using 64. I could spot no performance difference here at least. This was missed during development because Blender will cache thumbnails into a special .thumbnails directory and the images I was using to test had already been cached there. ---- [1] I plan on submitting a PR to OIIO to allow their `ImageInput::valid_file` API to take in a memory proxy. If that is accepted we would gain two nice things: - We'd be able to once again remove the custom TIFF, PSD, and PNG header checks - It would be more efficient than calling `.open` like we do today for some of the other formats

Jesse Yurkovich added this to the Core project 2023-05-02 00:53:51 +02:00

Jesse Yurkovich commented

2023-05-02 00:54:17 +02:00

@blender-bot build

Jesse Yurkovich force-pushed fix-browser-thumbnails from d9b4b30666 to 0aad8bf77a

2023-05-02 02:10:06 +02:00

Compare

Jesse Yurkovich commented

2023-05-02 02:10:31 +02:00

@blender-bot build

Jesse Yurkovich force-pushed fix-browser-thumbnails from 0aad8bf77a to 39a1a7b7c1

2023-05-02 19:28:03 +02:00

Compare

Jesse Yurkovich commented

2023-05-02 19:54:43 +02:00

@blender-bot build

Jesse Yurkovich referenced this pull request

2023-05-05 19:59:13 +02:00

Fix #107212: imb_is_a_ Failures Detecting Valid Images #107661

Harley Acheson commented

2023-05-05 21:09:28 +02:00

Although this passes far more of my tests, I still get failures on the attached 5 PNG files. These do pass on my PR #107661 though that just reverts us back to signature checking and remains reading just 64 bytes.

Reverting to signature checking (as this PR does for PSD and TIFF) and leaving the HEADER_SIZE at 64 seems like a safe fix for this.

Although this passes far more of my tests, I still get failures on the attached 5 PNG files. These do pass on my PR #107661 though that just reverts us back to signature checking and remains reading just 64 bytes. Reverting to signature checking (as this PR does for PSD and TIFF) and leaving the HEADER_SIZE at 64 seems like a safe fix for this.

k3b.png

14 KiB

restart.png

12 KiB

logout.png

16 KiB

quick_restart.png

9.2 KiB

shutdown.png

17 KiB