Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Image thumbnails of newly uploaded images are always shown in a landscape frame when using layout 1 or 2; portrait images get clipped #1388

Closed
doclbn opened this issue Jul 1, 2022 · 7 comments · Fixed by #1389
Labels
bug Something isn't working High Priority High priority issues

Comments

@doclbn
Copy link

doclbn commented Jul 1, 2022

Detailed description of the problem [REQUIRED]

Since upgrade to 4.5.1 (from 4.5.0, iirc...), thumbnails of newly imported images are always shown in a landscape frame when using layout 1 or 2.

  • Portrait images are shown centered and clipped top and bottom.
  • Image orientation itself is correct and not affected.

How can I get correctly oriented thumbnail frames with undistorted, unclipped images?
-> It would be great if can this be fixed without re-importing the images (I imported >1k since 4.5.1 =)

Steps to reproduce the issue

  • All images were imported from local filesystem using the UploadPhoto feature.
  • This only happens to newly imported images (since upgrading to 4.5.1). Images already in database are not affected.
  • Images were from various sources (Nikon SLR, iOS 12..15 devices, Android 4.1.2 device, Photoshop 5.0.2, SilverFast v6.4.4r7, various email clients, ...).
  • When using the "rotate clockwise / counter-clockwise" feature, the thumbnail frame will rotate accordingly. A portrait image shown clipped in a landscape thumbnail frame will turn into a landscape image shown clipped in a portrait frame.

While analyzing this, I realized when switching layout (0/1/2, regardless), image thumbnails are always square showing the whole image distorted to a square until I hit F5 (browser refresh).

Additional information:
When upgrading to a very freshly released v4.5.1, the upgrade failed on a database migration step and I had to do a composer rollback. Another attempt using a newer build a few days later was successful.

Screenshots
Screenshots of original images:
image
image

Always landscape oriented thumbnails (using Layout 1) - portrait image gets clipped:
image

Thumbnail frame after using Rotate clockwise feature:
image
Information on portrayed antenna:

Output of the diagnostics [REQUIRED]

System Information
--------------
Lychee Version (git):            master (46ae70b) -- Up to date (2 hours ago).
DB Version:                      4.5.1

composer install:                --no-dev
APP_ENV:                         production
APP_DEBUG:                       false

System:                          Linux
PHP Version:                     8.0.19
PHP User agent:                  Lychee/4 (https://lycheeorg.github.io/)
Timezone:                        Europe/Berlin
Max uploaded file size:          500M
Max post size:                   500M
Max execution time:              200
MySQL Version:                   10.5.16-MariaDB-1:10.5.16+maria~stretch

Imagick Available:               1
Imagick Enabled:                 1
Imagick Version:                 1687
GD Version:                      2.2.5



Config Information
--------------
version:                         040501
check_for_updates:               1
sorting_photos_col:              title
sorting_photos_order:            ASC
sorting_albums_col:              title
sorting_albums_order:            ASC
imagick:                         1
skip_duplicates:                 0
small_max_width:                 0
small_max_height:                360
medium_max_width:                1920
medium_max_height:               1080
lang:                            en
layout:                          1
image_overlay_type:              exif
default_license:                 reserved
compression_quality:             90
full_photo:                      1
delete_imported:                 0
Mod_Frame:                       1
Mod_Frame_refresh:               30
thumb_2x:                        1
small_2x:                        1
medium_2x:                       1
landing_page_enable:             0
landing_owner:                   doclbn
landing_title:                   doclbn
landing_subtitle:                Cats, Dogs & Humans Photography
landing_facebook:                https://www.facebook.com/JohnSmith
landing_flickr:                  https://www.flickr.com/JohnSmith
landing_twitter:                 https://www.twitter.com/JohnSmith
landing_instagram:               https://instagram.com/JohnSmith
landing_youtube:                 https://www.youtube.com/JohnSmith
landing_background:              dist/cat.jpg
site_title:                      D&L Fotoalben
site_copyright_enable:           1
site_copyright_begin:            1977
site_copyright_end:              2022
additional_footer_text:          
display_social_in_gallery:       0
public_search:                   0
SL_enable:                       0
SL_for_admin:                    0
public_recent:                   0
recent_age:                      1
public_starred:                  0
downloadable:                    0
photos_wraparound:               1
map_display:                     1
zip64:                           1
map_display_public:              0
map_provider:                    Wikimedia
force_32bit_ids:                 0
map_include_subalbums:           1
update_check_every_days:         7
has_exiftool:                    1
share_button_visible:            0
import_via_symlink:              0
has_ffmpeg:                      1
location_decoding:               1
location_decoding_timeout:       30
location_show:                   1
location_show_public:            0
rss_enable:                      0
rss_recent_days:                 7
rss_max_items:                   100
prefer_available_xmp_metadata:   0
editor_enabled:                  1
lossless_optimization:           0
swipe_tolerance_x:               150
swipe_tolerance_y:               250
local_takestamp_video_formats:   .avi|.mov
log_max_num_line:                1000
unlock_password_photos_with_url_param: 0
nsfw_visible:                    0
nsfw_blur:                       0
nsfw_warning:                    0
nsfw_warning_admin:              0
map_display_direction:           1
album_subtitle_type:             oldstyle
upload_processing_limit:         4
public_photos_hidden:            1
new_photos_notification:         0
legacy_id_redirection:           1

Browser and system

Lychee running on Linux 4.9.0-18-amd64 #1 SMP Debian 4.9.303-1 (2022-03-07) x86_64
Images viewed with Microsoft Edge Version 103.0.1264.44 (Official Build) (64-Bit) on Windows 8.1 Pro

@doclbn doclbn changed the title Image thumbnails of newly uploaded images are always shown in landscape orientation when layout 1 or 2 Image thumbnails of newly uploaded images are always shown in landscape orientation when using layout 1 or 2 Jul 1, 2022
@doclbn doclbn changed the title Image thumbnails of newly uploaded images are always shown in landscape orientation when using layout 1 or 2 Image thumbnails of newly uploaded images are always shown in a landscape frame when using layout 1 or 2; portrait images get clipped Jul 1, 2022
@kamil4 kamil4 added bug Something isn't working High Priority High priority issues labels Jul 1, 2022
@kamil4
Copy link
Contributor

kamil4 commented Jul 1, 2022

Confirmed. Probably another regression after #1336.

@kamil4
Copy link
Contributor

kamil4 commented Jul 1, 2022

I take it back. This bug predates #1336. Still, an annoying regression.

@kamil4
Copy link
Contributor

kamil4 commented Jul 1, 2022

@doclbn I've got a fix pending; hopefully it won't be more than a day or so before it's merged, but if you are in a hurry, you can replace the file Lychee/app/Actions/Photo/Strategies/AddStandaloneStrategy.php in your installation with the contents of https://raw.githubusercontent.com/LycheeOrg/Lychee/630d4ecae17cca61c48be6a31b903ad0456f8df0/app/Actions/Photo/Strategies/AddStandaloneStrategy.php.

Unfortunately, while the intermediate image sizes generated during upload are fine, the affected images have wrong size information in the database and applying the patch won't magically fix that. Conceptually, the easiest fix would indeed be to reupload them. If you want to avoid it, you will need to manually fix the broken entries in the database. You'll need to collect the ids of all the affected photos (they are the last part of the URL when you click on a photo (after the last /)) and then, in the database, in the size_variants table, for each entry with photo_id from the list of affected photos and the type equal to 0, swap the width and height.

@doclbn
Copy link
Author

doclbn commented Jul 1, 2022

@kamil4 Thanks for this extremely quick response and insightful information.
I'm not in a hurry, i'll happily wait for the merge, but i've uploaded a huge number of images spread over hundreds of albums over the last month, and I really don't want to go over these again =)
(I kinda noticed the botched thumbs but it didn't bother me enough to stop me uploading, or so it seems...)

Sooooooo if I get that right, i'd might go about SELECTing all images uploaded since the update (I do know the day when I did that, at least), find a way to identify the portrait ones (they should match height > width? Or is this the actual problem??) and swap these two on the type 0 ones, bingo.
I'll look into that asap (might be next week though) and report back.

Thx again,
-Lars aka doclbn

@doclbn
Copy link
Author

doclbn commented Jul 1, 2022

@kamil4 mmkay, after reading the actual code of your fix I see that the swapped height/width sequence is indeed the cause of the problem. Still, since it'd require me to manually open and visually assess every image in every album modified since the update to fix this, I'll take a look into the database and will try to find a way to algorithmically identify the portrait ones.

@kamil4
Copy link
Contributor

kamil4 commented Jul 1, 2022

Yes, it should be possible to identify them algorithmically by inspecting the size_variants table. type = 0 entries denote the original images, and those are the entries where width and height need to be swapped. type equal to 1 through 4 denote smaller sizes. Normally the aspect ratio of all of those should be roughly the same, but for the affected images, the aspect ratio of "type 0" entries will be inverse (1/x) of the rest. I hope this helps...

@doclbn
Copy link
Author

doclbn commented Jul 1, 2022

Thanks yet again, that was exactly what I was hoping to find =)
I'll look into it soon(tm), and if I find an elegant way to patch it I'll post the sql statement(s) here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working High Priority High priority issues
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants