Thoughts on thumbnail generation (and odd performance behavior) #3839
jessey-git
started this conversation in
General
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
As part of transitioning Blender to use OIIO for all its image formats, a few formats were purposely left behind due to feature parity in one particular scenario: efficiently generating small thumbnails for display in a file browser.
These thumbnails are not the thumbnails that exists in OIIO today. They will be generated on the fly if embedded previews are not present or if the formats don't support them at all.
For most formats we open the full-res original and then scale afterwards. However, some formats like JPG and WEBP can do better (the formats left behind). Both offer API settings to decode their data directly into a smaller size buffer; reducing memory requirements and eliminating most scaling costs entirely. In any case, I was hoping that I could use OIIO facilities to tackle both the situation where full-res originals are used as well as get close to parity with JPG and WEBP without needing to add support for such specialized APIs inside OIIO.
I started off by seeing if an
ImageBufAlgo::fit
(with a box filter; seems cheapest) would be good enough quality (it is!) but it's quite a bit slower; sometimes slower than just opening the full-res image and scaling using Blender's existing code. Even the simplerImageBufAlgo::resample
turns out slower too in some circumstances.Thinking that there might be something going on with ImageBufAlgo, I decided to implement my own sample-nearest using
ImageInput::read_scanline
and looping myself.ImageInput::read_scanline
seems to beatImageBufAlgo::resample
by ~2x at 8192x8192 … but it was nearly identical at 4096x4096. It's like performance fell off the cliff here for ImageBufAlgo.ImageInput::read_scanline
is orders of magnitude slower thanImageBufAlgo::resample
though…Is there perhaps another way of approaching this problem or is there a go-faster version of the code below?
This scenario is kind of a 1 and done thing. Once the thumbs are generated, they're cached on disk locally. Is there a way to have ImageBufAlgo not use the ImageCache?
The code in question is more or less just:
Some timings at 8192x8192 resolution:
Beta Was this translation helpful? Give feedback.
All reactions