feat: original-sized previews for RAW images

[eligao]

• Server: extract and keep the original-sized preview image
  • If image.extractEmbedded in options is set, it will attempt to extract the JPG/Preview from RAW images.
  • If the preview is too small or the extractEmbedded is not set, it will fall back to creating a full-sized image from RAW.
  • The result will be saved as a separate AssetFileType.converted file.
• OpenAPI: a new AssetMediaSize.Original size is available under the viewThumbnail API
  • It returns the original-sized preview for RAW files
  • Or otherwise the original image itself.
• Web: photo-viewer
  • When zoomed in, the browser loads the AssetMediaSize.Original preview via the viewThumbnail API
  • This applies to both RAW and non-RAW images, instead of previously only loading the original file for non-RAW image.
  • This file can be right-clicked and downloaded/copied for sharing.

Some loose ends:

• The converted preview of RAW don't have original EXIF
  • Especially the color profile is missing, making the rendering a bit off other than sRGB images.
  • This would be a nice touch to help easier organize and share the compressed images from RAW.
  • And it can open up the possibilities to "trim" the RAW images and replace them with just the JPG with all EXIF, freeing the space on the server.
• The way to download the file is implicit
  • A button, especially on the mobile app, would be helpful, but I'm not familiar with flutter.
• The API endpoint to download the original preview and original file for non-RAW files are different, but the contents are identical, this is not good for caching, maybe better use 302 instead?

[mertalev]

Thank you for the PR! I mostly looked at the server code, where I think it needs some more polishing.

Re: caching, this also affects the case where the user zooms in and no extracted image exists, right? It will load the preview again.

[eligao]

any more comments from maintainers to get this merged, so that I can continue with previews of other images?
@danieldietzler @alextran1502

[alextran1502]

@eligao no rush here

[mertalev]

I think we should wait until we're done with hot fixes for the current release.

[michelheusschen]

For a DNG image with a resolution of 5376x3956 and 41.3MiB in size, the following variants are generated using the default settings:

Variant	Format	Resolution	Size
Thumbnail	webp	5280x3956	887KiB
Preview	jpeg	5280x3956	1794KiB
Original	jpeg	5280x3956	1794KiB

These generated variants seem larger than expected and don't match the configured settings, with the preview and original being identical. It's also strange that the resolution has slightly changed.

[eligao]

For a DNG image with a resolution of 5376x3956 and 41.3MiB in size, the following variants are generated using the default settings:

Variant Format Resolution Size
Thumbnail webp 5280x3956 887KiB
Preview jpeg 5280x3956 1794KiB
Original jpeg 5280x3956 1794KiB
These generated variants seem larger than expected and don't match the configured settings, with the preview and original being identical. It's also strange that the resolution has slightly increased.

nice catch, the file sizes are indeed wrong, let me fix that and add checks to tests.
as for the sizes being slightly different, it's likely due to the crop tags in exif:

[mertalev]

Hi again @eligao! We've been talking about the PR and think there are a few changes it'll need for it to be merge-able.

1. It should apply to all images that aren't web compatible (using the same list as web, ignoring that Safari can view HEIF images)
2. It should be configurable in the image settings, similar to the thumbnail and preview sections
   • There should be an "enabled" toggle that is disabled by default
   • The target format should be configurable in the case where an embedded image is not used and a new image has to be generated
3. Rename the "converted" enum to "fullsize"