Skip to content

Extract embedded JPEG previews for fast interim thumbnails#1128

Open
bennetthermanoff wants to merge 1 commit into
CyberTimon:mainfrom
bennetthermanoff:bhermano/jpeg-extract
Open

Extract embedded JPEG previews for fast interim thumbnails#1128
bennetthermanoff wants to merge 1 commit into
CyberTimon:mainfrom
bennetthermanoff:bhermano/jpeg-extract

Conversation

@bennetthermanoff
Copy link
Copy Markdown

This commit expands the thumbnail generation system to include two new tiers of embedded JPEG previews:

For RAW files:

  • "Tiny" previews are extracted from the first 64K of a file
    • These are also scanned for any orientation metadata which is applied if present.
  • "Embedded" previews extract the full embedded JPEG preview
    • These can be significantly larger than the tiny previews, on Fuji RAF files for example they can be ~1MB in size, but they are still much faster to decode than generating a thumbnail from the RAW data.

For JPEG files:

  • Only "Tiny" previews are extracted

This commit also adds a new setting (default enabled) to allow users to disable the use of embedded JPEG thumbnails on RAWs if they prefer.

From a usability and first time user experience perspective this is a huge improvement especially when browsing large libraries of RAW and JPEG files. Other RAW editors utilize these embedded previews so I believe users will understand that final thumbnails will be more accurate.

Description

Type of Change

  • Bug fix
  • New feature
  • Breaking change
  • Performance improvement
  • Code refactoring
  • Documentation update
  • UI/UX improvement
  • Build/CI or Dependency update

Changes Made

Backend:

  • Spawns two new workers for tiny/embedded previews
  • Adds scanning of files for tiny/embedded previews
    • More efficient scanning for RAF files, (Fuji) others can come later
  • Adds setting for disabling RAW embedded previews
    • Even off, tiny previews are used for JPEG files

Frontend:

  • Extract a few Thumbnail state providers into the useThumbnails hook
  • Add "flattening" the 3 possible thumbnails for consumers of thumbnails (Selects best possible thumbnail available and only gives that one to components)

Screenshots/Videos

Screencast.From.2026-05-03.20-42-36.mp4

Testing

  • I have tested these changes locally and confirmed that they work as expected without issues

Test Configuration:

  • OS: Bazzite Linux 6.17.7-ba29.fc43.x86_64
  • Hardware: Ryzen 5800X3D, Radeon RX9070 XT, 32GB memory
  • Tested with Fujifilm RAF and JPEG files only. More testing would be great but if a preview fails nothing happens other than old behavior.

Checklist

  • My code follows the project's code style
  • I haven't added unnecessary AI-generated code comments
  • My changes generate no new warnings or errors

AI Disclaimer:

Please state the involvement of AI in this PR:

  • This PR is entirely AI-generated
  • This PR is AI-generated but guided by a human
  • This PR was handwritten with AI assistance (spell check, logic suggestions, error resolving)
  • This PR contains only blood, sweat, and coffee (AI-free)

AI was instrumental in writing the actual extraction logic of JPEG previews.

This commit expands the thumbnail generation system to include two new tiers of embedded JPEG previews:

For RAW files:
- "Tiny" previews are extracted from the first 64K of a file
  - These are also scanned for any orientation metadata which is applied if present.
- "Embedded" previews extract the full embedded JPEG preview
  - These can be significantly larger than the tiny previews, on Fuji RAF files for example they can be ~1MB in size, but they are still much faster to decode than generating a thumbnail from the RAW data.

For JPEG files:
- Only "Tiny" previews are extracted

This commit also adds a new setting (default enabled) to allow users to disable the use of embedded JPEG thumbnails on RAWs if they prefer.

From a usability and first time user experience perspective this is a huge improvement especially when browsing large libraries of RAW and JPEG files. Other RAW editors utilize these embedded previews so I believe users will understand that final thumbnails will be more accurate.
@Flohhhhh
Copy link
Copy Markdown
Contributor

Flohhhhh commented May 4, 2026

Awesome! Was this really not implemented already?!

I surely thought it was. Great work!

@fcmss
Copy link
Copy Markdown

fcmss commented May 4, 2026

Maybe you could indicate that the real thumbnail is being generated with a little loading icon or something? Any icon/indication that would tell the user the thumbnail they're seeing is not the final one, basically.
But other than that, I really like this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants