fix(server): adjust panorama medata for new image dimensions

[meesfrensel]

Description

Introduced in #23953, the copied metadata contains some pixel values referencing what part of the sphere is covered. These values have to be multplied by the ratio between preview and original size.

#23953 (comment)

Fixes #24333

How Has This Been Tested?

Tested on hte three test panoramas I use: one is (way) bigger than the preview size, one is a little smaller, and one is 'cropped' aka not covering the whole sphere.

Checklist:

• I have performed a self-review of my own code
• I have made corresponding changes to the documentation if applicable
• I have no unrelated changes in the PR.
• I have confirmed that any new dependencies are strictly necessary.
• I have written tests for new code (if applicable)
• I have followed naming conventions/patterns in the surrounding code
• All code in src/services/ uses repositories implementations for database calls, filesystem operations, etc.
• All code in src/repositories/ is pretty basic/simple and does not have any immich specific logic (that belongs in src/services/)

Please describe to which degree, if any, an LLM was used in creating this pull request.

...

[immich-push-o-matic]

Label error. Requires exactly 1 of: changelog:.*. Found: 🗄️server. A maintainer will add the required label.

[mertalev]

A few code style comments, but otherwise it looks right. I do want to get input from @bwees on this because image editing (not landed yet) can throw a serious curve ball here given the preview and full-size images can be cropped and rotated.

[mertalev]

It seems like it'd be cleaner if the logic inside this conditional were moved to a separate method.

[mertalev]

The preview and full-size handling seems the same aside from the scaling done for the preview (which could be a scaling of 1 for the full-size image). Could this be extracted to a helper method instead?

[mertalev]

Re: image editing, the consensus is for editing to not support panoramas in the first pass, so the earlier comment about crop/rotation isn't a blocker for this PR.

[mertalev]

This is assuming the full-size image has the same dimensions as the original, right? If we used the embedded preview above for the full-size image, then the dimensions could be different. sharp can return the output image dimensions from toBuffer, so using those values and scaling both is probably safer.

[meesfrensel]

That's assumed, yes. I was not aware that the 'full size' image could be not-full size :o Good catch.

The ternary-based control flow confuses me quite a bit, but basically you're suggesting something like below right? And then propagate that to the (now extracted) helper method.

let fullsizePath: string | undefined;
+ let fullsizeSize: number | undefined;

if (convertFullsize) {
// convert a new fullsize image from the same source as the thumbnail
fullsizePath = StorageCore.getImagePath(asset, AssetPathType.FullSize, image.fullsize.format);
+ fullsizeSize = asset.exifInfo.exifImageHeight;
const fullsizeOptions = { format: image.fullsize.format, quality: image.fullsize.quality, ...thumbnailOptions };
promises.push(this.mediaRepository.generateThumbnail(data, fullsizeOptions, fullsizePath));
} else if (generateFullsize && extracted && extracted.format === RawExtractedFormat.Jpeg) {
fullsizePath = StorageCore.getImagePath(asset, AssetPathType.FullSize, extracted.format);
+ fullsizeSize = extracted.<somehow get the size here>;
this.storageCore.ensureFolders(fullsizePath);

One thing about this: I don't see a way to get the size of the extracted image buffer. It's not done with sharp, but exiftool's extractBinaryTagToBuffer which ofc only returns a buffer.

[meesfrensel]

Ok I found a way. Changes are in a separate second commit for easy reviewing. Let me know what you think!