[Feature Request] Multiple images for better screen utilization

[cdecoux]

First of all, this utility has been exactly what I was looking for and thank you for taking the time to implement it!

For the feature request: the only thing has bugged me is that some of my images have a lot of whitespace (blurry background fill). I'm running this with a large 16:9 monitor with my album having a mix of portrait and landscape orientated photos. It would be awesome to get support for pulling in multiple images with the goal of maximizing screen usage.

I think there's a lot of potential for configuration here - but I want to provide a simple first step that should satisfy majority cases:

1. Determine orientation of the display (landscape or portrait), taking into account the configured rotation
2. Determine the orientation of the image to display.
3. If the orientations match, display a single image as normal. If the orientations are in conflict, save the photo until another conflicting photo can be paired with it
4. When two images are saved with the conflicting orientation, split the display into two by dividing the longest edge and display the images in each section.

On 3. above, there's nuances here due to potentially different use-cases:

• For unordered, random slideshows it seems the most reasonable to just save the image in memory (or save to disk, but eventually two images will need to be in memory anyway) and continue displaying non-conflicting photos as normal.
• When order matters but multi-images are allowed, it might make sense to pull the next image and see if it's conflicting also. If so, then they can both be displayed ad described above. If it's not conflicting, then just display them in order individually.

Perhaps a config for --multi-image-type with where None is the current implementation, and the method described above could be Simple, Split, or Auto. I'd love to see this feature add more types, such as dynamic collage displays for when users have even larger screen space to work with.

Happy to provide support on this, but wanted to get this feature request out there in case anyone could knock it out beforehand.

[Caleb9]

Hi @cdecoux, thanks. Sounds interesting! :) Though there will be some complexity.

I just refactored large part of the app, so unfortunately I'm not sure when I'll have some free time again to take a look at this, but if you'd like to give an implementation a shot, that would be great!

In regard to your proposal for point 3, I'm pretty sure it's possible to extract the image dimensions / orientation from the JSON metadata served by the API, so it wouldn't even be necessary to cache the actual photo bytes. Currently, as you can see in the slideshow.rs file, the app fetches metadata for all photos in the album, and then based on that fetches actual photo bytes one-by-one. You'd need to inspect the JSON payload returned by the API to find out where this information is, and then extend the DTO struct with the dimensions / orientation. Based on that you could implement some sort of algorithm to match same orientation photos and create some specific sequence.

Btw. the DTOs are implemented in another library: syno_api for Synology Photos, and for Immich they are under immich_client.rs.

Let me know what you think. :)

[Caleb9]

@cdecoux I added resolution and orientation fields to syno_api 0.3.4, see here. For Synology Photos API to return these fields, you need to add "resolution","orientation" to the additional form parameter of api="SYNO.Foto.Browse.Item",method="list" request (here). Not sure how the orientation values are to be interpreted (numbers), probably needs some experimentation / reverse engineering to figure it out.