Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This merge request addresses #198.
It's a pretty large patch so allow me to provide an overview/motivation for why I coded it the way I did. I can of course make any modifications you deem necessary to make it acceptable for merging.
Lychee currently supports HiDPI ("retina") for the square thumbnails only, by creating
@2x
files on the server side during image upload and assuming on the frontend side that those files are always present (the@2x
names are unconditionally used insrcset
when generating HTML).To keep things configurable, I added three new options to the
configs
table:thumb_2x
,small_2x
, andmedium_2x
. Only the first one defaults to 1, to mimic the current behavior. The others need to be set to 1 manually to activate the generation of@2x
versions of small and medium images.Depending on the input image size, some of the image variants, especially the medium@2x, may end up not getting generated. I decided to extend the
photos
table with additional columnsmedium2x
,small2x
, and for the sake of completeness alsothumb2x
to store that info. The server API needed to be extended to pass the data on 2x variants to the frontend.In image view mode, as well as in justified album view, the images may not be rendered at their natural resolution but may be resized. In those cases, passing density value of
2x
in thesrcset
tag would be incorrect. Instead, the best solution is to pass the widths of each image variant (using the<width>w
syntax insrcset
) and the expected rendered size in thesizes
tag. But we need to know those widths, and they are not readily available in the frontend. The server knows them when it generates the images, so I changed thesmall
/small2x
/medium
/medium2x
columns in thephotos
table to store<width>x<height>
strings for each variant, or an empty string if that variant is not available. I keptthumb2x
as a 0/1 since that has a fixed size of 400x400. Again, the server API needed to be extended to pass this additional data (insmall_dim
/medium_dim
/small2x_dim
/medium2x_dim
fields).Given the size of the patch, I have no intention of backporting it to Lychee v3; however, the patched frontend will also work with an unpatched server.
With that lengthy preface out of the way, I can now discuss parts of the patch itself:
database/migrations/*
verifies for each image that thethumb2x
variant actually exists and also extracts the sizes ofsmall
/medium
variants using GD.Image/
handlers were extended to return the width/height of generated images via two arguments passed by reference. If this syntax is too ugly to tolerate, please recommend an alternative (I've never coded in PHP before).In
ModelFunctions/PhotoFunctions.php
, I made the generation of thethumb2x
variant increateThumb()
conditional on the input image size to match what was already done forsmall
/medium
. I added the generation of 2x variants toadd()
andcreateMedium()
, conditional on the config variables.There are two areas that I wasn't sure of:
I believe I did the right thing for
Console/Commands/medium.php
andsmall.php
but I didn't test because I don't know how to use these things -- any hint? Also, should I add support for generating 2x variants there?I wasn't sure what to do about
getRandom()
inapp/Http/Controllers/PhotoController.php
because I couldn't figure out how to get that Frame mode to work. Though I feel that that API is needlessly restrictive and it shouldn't be the server's job to pick big vs medium variant. Why not simply return a wholePhoto
object and let the frontend pick whatever it needs out of it -- there's already code for that?