Aderalia wrote:

The 'body { width: auto; }' part is from the plugin documentation and should probably be updates with the new code since the old one doesn't work anymore (or at least it didn't for me, maybe someone should verify that first).

You were correct again, this revision of the theme broke it. So the documentation really needs an update.
https://piwigo.org/dev/changeset?repona … styles.css

Hi, thanks for the great plugin, it is exactly what I was looking for and have been using it for some time now.

I have only one problem - now I am creating derivatives (thumbnails) outside piwigo, which works perfectly for any landscape images. But all portrait images are stretched to 4:3 landscape ratio. The derivatives themselves are fine, I checked multiple times and even tried swapping the gdT generated portrait thumbnail for the "outside" generated and that made no difference. This means that the wrong aspect ratio is not related to the physical thumbnail. My idea is, that since the thumbnails are already created, then gdT never analyses the actual image and hence doesnt know if it is portrait or landscape and returns to some default value. Is this possible? Does gdT write anything to the database?

I tried looking through the code, but I have very little experience with programming, let alone css/php/js, so couldnt find anything meaningful myself. I suspect the culprint might be in some js code, which determines the correct aspect ration of the thumb, right? But why doesnt gdT use the thumbnails physical aspect ratio, but rather defualt to a "standard" value if it has not processed the image beforehand?

Any help or at least point in the right direction would be welcome.

Hi and thanks for the really quick response and pointing me into the right direction. The dimensions are correct in a sense that the physical dimensions are right, but they do not reflect the EXIF orientation tag. An example:
- Image1 => physical=landscape, exif orientation=none; shown correctly as 2592*1728
- Image2 => physical=landscape, exif orientation=RightTop (i.e. oriented to portrait); shown "wrongly" as 2592*1728
- Image3 => physical=portrait, exif orientation=none; shown correctly as 1728*2592

So this means that piwigo and/or GDT takes only the physical dimensions of the image (not taking into account any EXIF orientation tag) and GDT then "blindly" uses this value to generate the thumbnail CSS box. This is why pregenerated derivatives are stretched for cases such as Image2. But if Piwigo generates the thumbnail itself, then it seems to analyse the picture in more depth (i.e. read the EXIF orientation) and GDT somehow reflects this. So to fix my issue I will convert all my EXIF oriented images to "physically" oriented one with something like jhead or exiftran and let you know if that solved my issue (I did it on a small sample and worked fine).

And just to answer your questions, if gdThumb generates them, they are fine. Once generated, I can substitute the "old" custom generated one and they are also shown fine. So simply swapping the thumbs has no effect (neither when initially correct, nor when stretched).

By the way, shouldnt Piwigo reflect the EXIF orientation if showing image dimensions in image details or in the database? They seem to be ignored in my case, always showing the physical picture size

rajdude wrote:

Thanks for this nice plugin!

May I ask what this does:

"Block for Panoramic Photo Page"

I tried enabling it but nothing happens. Is it looking for something in addition to checking that checkbox?

I know it is an old question, but if anyone is interested:
Block is intended to help when a first thumb has a ratio outside (ratio > 2.2) || (ratio < 0.455), i.e what I consider a panoramic view photo. To keep the layout consistent when encountered, the such thumb will be blocked from being enlarged for this category.

Kinsman wrote:

This is likely a clash of plugins I think, but since updating to 13.1 if I enable GDThumb then all the base albums vanish from my homepage.

I think it is the same problem with the last version of plugin like here: https://piwigo.org/forum/viewtopic.php? … 09#p184709
There is some calling in the circle there and behavior is dependent on how browser handle this situation.

Reverting to 1.24 fixed it for me.

Thanks, tested working ok.

Any way to have this auto pre-cache?