Define How to Deal With Different Preview Sizes and DPIs #81972

New Issue

Julian Eisel · 2020-10-22T19:22:30+02:00

Julian Eisel commented

2020-10-22 19:22:30 +02:00

Choosing a size to generate a preview/thumbnail for is not trivial. Users may want to show thumbnails in different sizes (e.g. relatively small in the asset list, bigger in the sidebar). But also, the previews are stored with the assets in .blends - how to deal with different DPIs the asset previews may be shown in?

E.g. a user creates an asset inside a .blend with a non-hiDPI screen and installs that .blend as asset repository on a hiDPI machine. Or the other way around: Create asset on hiDPI screen, install .blend as repository for a non-hiDPI setup.

Choosing a size to generate a preview/thumbnail for is not trivial. Users may want to show thumbnails in different sizes (e.g. relatively small in the asset list, bigger in the sidebar). But also, the previews are stored with the assets in .blends - how to deal with different DPIs the asset previews may be shown in? E.g. a user creates an asset inside a .blend with a non-hiDPI screen and installs that .blend as asset repository on a hiDPI machine. Or the other way around: Create asset on hiDPI screen, install .blend as repository for a non-hiDPI setup.

Julian Eisel commented

2020-10-22 19:22:31 +02:00

Added subscriber: @JulianEisel

Harley Acheson commented

2020-10-22 22:21:10 +02:00

Added subscriber: @Harley

Harley Acheson commented

2020-10-22 22:21:10 +02:00

Some notes (mostly for self).

We have a ThumbSize enum that isn't really setting size, contains THB_NORMAL, THB_LARGE, THB_FAIL, which is really used to determine where thumbnail files are stored in the file system. Of these THB_NORMAL is not actually used, and THB_FAIL is used to indicate a folder of thumbnail failures (saved as 1x1px images). When it comes to actually creating thumbnails (thumb_create_ex(()) we have a singular define PREVIEW_RENDER_DEFAULT_HEIGHT, currently 128. This is doubled for the only valid size of THB_LARGE, to get us our current 256x256 thumbnail sizes.

Might be nice to get rid of THB_NORMAL, clarify what ThumbSize is used for (just to indicate errors so could be a bool). Then have multiple size defines that we could tailor per-type. So we could make larger image and blend thumbs, but smaller video and even smaller font thumbs.

Some notes (mostly for self). We have a ThumbSize enum that isn't really setting size, contains THB_NORMAL, THB_LARGE, THB_FAIL, which is really used to determine where thumbnail files are stored in the file system. Of these THB_NORMAL is not actually used, and THB_FAIL is used to indicate a folder of thumbnail failures (saved as 1x1px images). When it comes to actually creating thumbnails (thumb_create_ex(()) we have a singular define PREVIEW_RENDER_DEFAULT_HEIGHT, currently 128. This is doubled for the only valid size of THB_LARGE, to get us our current 256x256 thumbnail sizes. Might be nice to get rid of THB_NORMAL, clarify what ThumbSize is used for (just to indicate errors so could be a bool). Then have multiple size defines that we could tailor per-type. So we could make larger image and blend thumbs, but smaller video and even smaller font thumbs.

Sybren A. Stüvel commented

2021-04-23 15:01:05 +02:00

Added subscriber: @dr.sybren

Sybren A. Stüvel commented

2021-04-23 15:01:05 +02:00

Is resizing an image on the fly really still a problem nowadays? Can't we just let the GPU handle that when drawing the UI? I think just storing a 256x256 image and resizing it to suit our needs should be good enough (given a suitable resizing algorithm of course).

Julian Eisel commented

2021-04-23 15:06:12 +02:00

AFAIK it isn't. We do the same with the splash now, we used to have two versions, one for Retina screens. Now it's just the higher-resolution one and we downscale it. The difference is visually pretty much indistinguishable.
We can just do the same with previews. Store them in a big size, and down-scale as needed. I think we already do that, just use the worse resizing algorithm of the options available.

The thing is, to get good looking previews on Retina screens, they will have to be rendered at twice the resolution. Not sure if we want to do that.

AFAIK it isn't. We do the same with the splash now, we used to have two versions, one for Retina screens. Now it's just the higher-resolution one and we downscale it. The difference is visually pretty much indistinguishable. We can just do the same with previews. Store them in a big size, and down-scale as needed. I think we already do that, just use the worse resizing algorithm of the options available. The thing is, to get good looking previews on Retina screens, they will have to be rendered at twice the resolution. Not sure if we want to do that.

Harley Acheson commented

2021-04-23 19:13:26 +02:00

Not sure if this applies to these types of thumbnails, but when I was looking at how we create the ones that make it into the filesystem ".thumbnails" cache I found a few things that can sometimes make them less than perfect.

Those are saved as 256x256 PNGs, but with blend file previews we are rendering the scene at 256x256, then reducing to 128x128 to add some antialiasing, then it gets blown back up to 256x256. So we end up with half the resolution as other thumbnails. Ideally that would be rendered at 512x512 then reduced to 256. But note that the version of the blend thumbnail we keep inside the blend is an uncompressed 128x128 bitmap.

There might be a few things in here that could apply too: https://developer.blender.org/D9397

There is a use of IMB_scalefastImBuf to scale, that should be IMB_scaleImBuf
There is an added IMB_premultiply_alpha(ibuf); to help with color fringes at edges if the preview used transparency.
When using immDrawPixelsTexScaled, it helps to set use_filter to true.

Not sure if this applies to these types of thumbnails, but when I was looking at how we create the ones that make it into the filesystem ".thumbnails" cache I found a few things that can sometimes make them less than perfect. Those are saved as 256x256 PNGs, but with blend file previews we are rendering the scene at 256x256, then reducing to 128x128 to add some antialiasing, then it gets blown back up to 256x256. So we end up with half the resolution as other thumbnails. Ideally that would be rendered at 512x512 then reduced to 256. But note that the version of the blend thumbnail we keep inside the blend is an uncompressed 128x128 bitmap. There might be a few things in here that could apply too: https://developer.blender.org/D9397 - There is a use of IMB_scalefastImBuf to scale, that should be IMB_scaleImBuf - There is an added IMB_premultiply_alpha(ibuf); to help with color fringes at edges if the preview used transparency. - When using immDrawPixelsTexScaled, it helps to set use_filter to true.

Harley Acheson commented

2021-04-23 19:19:41 +02:00

And a bit of an off-topic note, but still about the images in the file system cache. Those files stored in there are following a particular standard that encourages adding PNG meta-data to them. So if you are looking at the thumbnail of a video, for example, you can not only have a preview of what it looks like but also have information about the resolution, bit depth, etc. No reason to have to load the file again just to have this information that might help select it.

I have a patch that adds metadata for images, videos, fonts, and blend files. https://developer.blender.org/D9454. It is out of date now, but I mostly wanted to mention this as a consideration.

And a bit of an off-topic note, but still about the images in the file system cache. Those files stored in there are following a particular standard that encourages adding PNG meta-data to them. So if you are looking at the thumbnail of a video, for example, you can not only have a preview of what it looks like but also have information about the resolution, bit depth, etc. No reason to have to load the file again just to have this information that might help select it. I have a patch that adds metadata for images, videos, fonts, and blend files. https://developer.blender.org/D9454. It is out of date now, but I mostly wanted to mention this as a consideration.

Alaska commented

2024-04-07 05:53:09 +02:00

I am removing the Needs Triage label. This is under the general rule that Design and TODO tasks should not have a status.

If you believe this task is no longer relevant, feel free to close it.

I am removing the `Needs Triage` label. This is under the general rule that Design and TODO tasks should not have a status. If you believe this task is no longer relevant, feel free to close it.

Alaska removed the

Status

Needs Triage

label 2024-04-07 05:53:41 +02:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Define How to Deal With Different Preview Sizes and DPIs #81972