Skip to content

mipmaps to cover higher resolution screeens and increased mipf resolution#20184

Merged
TurboGit merged 3 commits intodarktable-org:masterfrom
dtorop:update-mipmaps-to-2020s-tech
Feb 9, 2026
Merged

mipmaps to cover higher resolution screeens and increased mipf resolution#20184
TurboGit merged 3 commits intodarktable-org:masterfrom
dtorop:update-mipmaps-to-2020s-tech

Conversation

@dtorop
Copy link
Copy Markdown
Contributor

@dtorop dtorop commented Jan 20, 2026

  • Update/add higher resolution mipmaps:
    • New mip8 to cover 6K displays
    • New mip9 to cover 8K displays
    • New mip10 for full-sized 8-bit mipmaps (previously these were mip8)
  • Increase mipf resolution from mip2 to mip3 dimensions, as per suggestion from @jenshannoschwalm.
  • Add an alias DT_MIPMAP_LDR_MAX for the full-sized 8 bit mipmap, to ease any future mipmap size adjustments.

Adding higher resolution mipmaps both covers higher resolution displays and should allow for less jumpy zooming in on high megapixel files. Increasing the mipf resolution should produce better preview pipe data.

In _get_dimensions_for_img_to_fit(), prior code looked at mip7 or smaller. This code looks at the full-sized 8 bit mipmap or smaller, which should produce more accurate results without a slowdown.

In the crawler, I noticed that the code never creates a full-sized 8 bit mipmap, nor a mip0. I left that behavior unchanged.

Closes #20178.

@TurboGit TurboGit added this to the 5.6 milestone Jan 20, 2026
@TurboGit TurboGit added feature: enhancement current features to improve priority: medium core features are degraded in a way that is still mostly usable, software stutters scope: DAM managing files, collections, archiving, metadata, etc. scope: performance doing everything the same but faster release notes: pending labels Jan 20, 2026
@dtorop
Copy link
Copy Markdown
Contributor Author

dtorop commented Jan 20, 2026

See #20178 (comment), some second thoughts on the mipmap levels.

And those second thoughts answered, I hope, by some third thoughts.

This clears the way for not depending on the largest 8 bit mipmap
being mip8 or using the not always obvious fact that it is one less
than DT_MIPMAP_F.

Note that the compiler may cast dt_mipmap_size_t to an unsigned
integer type. This requires some care in comparisons against values
which may be negative. We can use a dt_mipmap_size_t as a loop index
type so long as we count from 0 up. Counting down could trigger an
infinite loop, as if the compiler makes dt_mipmap_size_t unsigned, a <
0 condition will never occur.

Don't create DT_MIPMAPLDR_MIN. It is just as clear to use DT_MIPMAP_0,
and casting to a dt_mipmap_size_t can mess up comparisons as it can
cast both values to unsigned.

In _get_dimensions_for_img_to_fit(), prior code looked for mip7
down. It should produce most accurate results to start with the full
sized 8-bit mipmap, so this commit does that.

In crawler, use LDR_MAX instead of mip8. But assume that there is
wisdom in never creating a full-sized 8 bit mipmap, nor a mip0, so
leave that code unchanged.

Also give a hint in comments about what these mipmap levels mean.
Add new mip8 to cover 6K and mip9 to cover 8K displays.

Rationale:

- 5K monitors are somewhat common (Apple Studio Display, 5k iMacs, LG
UltraFine), so it makes sense to keep a mipmap for fullscreen display
in those monitors.
- 10K monitors do not currently exist, so it doesn't make sense to
have a mipmap to support these.

I'm a bit puzzled why mip7 has been in the code as 5120x3200, as 5K is
5120x2880. Perhaps it's possible to scale a 6K or 8K display to that
dimension, or it just is an even 1.25x mip6? Regardless, not mucking
with this now, to not meddle too much in this PR.

Closes darktable-org#20178.
As per @jenshannoschwalm, mip2

> was chosen when usual images were a few mpix, i think we should
> increase that level by one having a) some performance penalty b) but
> clearly better data that use output from preview pipe and c) less
> differences when calculating dimensions based on preview.
@dtorop dtorop force-pushed the update-mipmaps-to-2020s-tech branch from 2495d23 to 59dca5d Compare February 8, 2026 03:25
@dtorop
Copy link
Copy Markdown
Contributor Author

dtorop commented Feb 8, 2026

Updated this PR to make it merge cleanly and to simplify commit record.

@TurboGit
Copy link
Copy Markdown
Member

TurboGit commented Feb 8, 2026

@dtorop : Looks good, I'll do some testing in the coming days.

Copy link
Copy Markdown
Member

@TurboGit TurboGit left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@TurboGit TurboGit merged commit 64189d6 into darktable-org:master Feb 9, 2026
5 checks passed
@wpferguson
Copy link
Copy Markdown
Member

Does this PR "rearrange" the existing cache so that mip8 is now mip10, or is the crawler expected to take care of this?

@jenshannoschwalm
Copy link
Copy Markdown
Collaborator

jenshannoschwalm commented Feb 9, 2026

I will take care of that, seems good to me as existing mipmip sizes didn't change and you would have to manually change a setting for larger ones

@dtorop dtorop deleted the update-mipmaps-to-2020s-tech branch February 10, 2026 02:13
dtorop added a commit to dtorop/darktable that referenced this pull request Feb 28, 2026
TurboGit pushed a commit that referenced this pull request Mar 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

feature: enhancement current features to improve priority: medium core features are degraded in a way that is still mostly usable, software stutters scope: DAM managing files, collections, archiving, metadata, etc. scope: performance doing everything the same but faster

Projects

None yet

Development

Successfully merging this pull request may close these issues.

RFC: Add larger 8-bit mipmaps to handle larger displays and higher resolution cameras

4 participants