Zenphoto
The simpler media website CMS
ZenphotoThe simpler media website CMS
Forum search only. You might also want to search on the main site's user guide.
Your support helps pay for this server, and helps development of zenphoto. Thank you!
Visit the donations page
Hi,
First of all, I'd like to thank the authors for a great application I have been using since 2009.
My initial installation was ZP 1.2.5. The gallery was abandoned in 2015, but I want to start over now.
Here is a static copy of the old gallery for reference: http://leitseite.net/photo/galleries/index.html
As you can see, the thumbnails (and all images inside) are uncropped, have constant image height and variable image width. On the second page, there is a Panorama gallery with a custom cropped image.
I found this not to be (easily) possible with recent ZP versions, here is my attempt: http://leitseite.net/photo/galleries.new
The main index size is enlarged from 650px to 1170px in the CSS (was too small then, and is much too small now for modern screens).
Standard image size is 1170x780.
The first index page is already like a clone, however I had to use the custom functions to get there:
There is a similar problem in case of the thumbnails: you cannot get uncropped constant height even in principle, in spite of the recommendations I found here in the forum.
The standard aspect ratio is square. Using the crop option does not help because it crops all images equally (a 3:2 shot will look even wider).
I am now stuck on my Panorama gallery on the second page (http://leitseite.net/photo/galleries.new/page/2/) because I cannot custom crop the wide images to a fitting thumbnail (had to use custom functions because of the above), and the wide thumbnail image destroys the layout of the index page. I would have to delve in and find out how I can define something different for that single gallery.
This could all be easily fixed if a constant height with preserved aspect ratio would be offered, which I think is also the way it makes most sense because it never messes with the layout. Film contact sheets were also produced this way.
Ironically, that was just the way the old Zenphoto up to 1.3 was working, as you can see from the static copy. The panorama thumbnail is a custom crop and the rest was just defined in the theme options.
Comments
No this is not a bug. The default size options you set for uncropped images in the backend is either based on various measures that are documented on the option on the backend itself. These are by definition
If you want uncropped images that never exceed neither a specific widht or height you have to modify your theme to use the set of "maxspace" custom image functions. Then you would define e.g. 500x500 and the image would always be within that size. So a 1000x500 image would be 500x250 to fit in.
You find info on these on the documentation:
https://docs.zenphoto.org/1.5.x/
You will find the real strength of Zenphoto is doing such custom things. When I create themes for clients I never use the default images sizes because they are so unpredictable.
I really doubt that this was working by default on the old Zenphoto 1.3 and older. The "maxspace" function where introduced especially because of this.Perhaps whatever theme you were using did use these but for sure no official one (Zenpage does on the image.php page though).
Constant height did work with the old ZP and the standard theme without using custom functions, my old gallery had just that: http://leitseite.net/photo/galleries/index6494.html?album=misc
The portrait shots are constant height, all thumbnails too, and this was definitely not hacked into the setup somewhere.
Regarding the possible bug, note that I had defined 780 pixels height, but the landscape images got 780 width (NOT height as defined) and then got scaled up by the browser to 780 height with its ugly nearest neighbor scaling. That makes this setting unusable. No other setting caused browser scaling.
I do not find the constant height requirement very unusual, it is the standard method for contact sheets, most raw converters' thumbnails etc.. otherwise you have chaotic thumbnail sizes all over the place.
If I remember correctly, maxspace did not work for me because thumb images would be strechted into the space. Might require changes to the CSS layout, but I know even less about CSS than about PHP..
Also, the problem with using custom functions is that I now cannot define a custom crop for the panorama shots in the UI. But the pano gallery destroys the layout of the second page.
I cannot say anything to the old site as this behaviour also depends on the what exact settings you used. (longest side, shortest side etc).
Longest side would result in the behaviour you described as on landscape that is the width.
How something is display is entirely up to the theme. The default theme is very old and not made for maxspace functions. So they might not work without changes to the CSS. However the theme will not get any updates anymore. The standard usage is cropped thumbs as that makes everything easier layoutwise.
Either you use custom function so the theme controls the sizes or you use the default functions with custom crops. Sorry, you cannot have both for obvious reasons.
I am sorry, if you have specific requirements you have to learn to modify your theme. Zenphoto is not a ready-made-for-everything regarding themes but also a framework to do lots of individual things.
Perhaps you confusing about the thumbs is something differetn. The "Image size" option is for the single sized images, not for thumbs. Although all image sizing function use the same tool this does not affect the thumbs as those interally treated differently and only use the thumb setting. Which don't have any limitation for widht/height at all if uncropped. Again you would have to modify the theme to use other size functions to achieve this.
Again, you could also use CSS to "fake resize" images to the same width.
I am talking about two different things, yes. But they are related. My examples are much clearer than describing it all. First, the thumbnails:
I understand it is all based on square tiles, but the old options allowed properly scaled thumbs without problems, while still fitting it all into a grid, which was perfect.
I just checked admin-options.php of 1.2.5, and the description there says "If checked the thumbnail cropped to the width and height indicated". Seems to be pixel values as users have previously remarked in discussions, which was also doubted then.
printAlbumThumbImage in template-functions.php directly calculates width and height values for cropping with this, unlike the newer version.
Now the second issue. I have reverted album.php to the original 1.5.7 file and used the UI to define 780 pixels of height. This is not working properly, please have a look:
http://leitseite.net/photo/galleries.new/misc/IMG_0676.JPG
Browser reports on image: 780px × 520px (scaled to 1,170px × 780px).
Old gallery page, correct 1170x780 image:
http://leitseite.net/photo/galleries/index74d1.html?album=misc&image=IMG_0676.JPG
p.s. it is also correctly displayed if height 780 is passed to printCustomSizedImage with no other size parameters.
Non cropped use pixels but cropped are in result px as well but what is cropped is a bit more relative since based on percent on the original size. For an more "controlled" outcome the custom image functions need to be used.
I seriously cannot remember if this ever really worked in such old versions many years ago as you will understand.
I see that it is not working on your sized image. I will use your original image to try to reproduce this.
Perhaps I am also wrong and uncropped thumbs also should internally follow the "image size" setting about width and height. Since the sized image is not working that might be the case and the same bug. Zenphoto is quite complex so I cannot remember everything in the code offhand ;-) We will take a look at this.
PS: One note about the single image page:
http://leitseite.net/photo/galleries.new/misc/IMG_0676.JPG
If you care about SEO etc. I strongely recommend to define a rewrite suffix as this page might be rejected as an script page (which it is) pretending to be an "image".
Thanks for the hint, this doesn't need to be found by search engines but I'll remember it for the future.
It's not only for search engines, some security programs may also trigger on this.
One thing I forgot to mention above: If you changed the default image sizes around, you need to manually clear the image cache on the overview page. Otherwise you stil get the former images delivered. This "can" expain that something "seems" not to work. The default size cache images all are named the same like "filename_780.jpg" for the image size. But this does not care for the other options as this applies on generation only and the cache is not updated automatically accordingly.
I just tried on my local test install with some own images and - to be sure it is not some metadata issue - your example image from above using the Basic theme
On the single image (what we call "sized image" and in this case "default sized image") it does work as expected for me with all four settings (height, width, longest and shortest side) incl. with your image.
For the thumbs it always uses the longest side if set to uncropped as in your example, too. This is probably as code, we'll look/discuss if we change that as it indeed might have gotten lost over the years and no one except you noticed…
I deleted the cache for the "misc" album, and I still got the same 780x520 image (instead of 1170x780) when it was re-generated.
I searched a lot in this forum, and I think some other people noticed and even suggested the thumbs had pixel values for cropping up to 1.3, like in the discussion called "rectangular thumbs". The users then generally just moved to using the custom functions. This does work fine simply by calling them with only the height parameter, but what can I do with the panorama gallery now? I need a custom cropped thumb there. Only way I can think of right now, outside writing code that displays thumbs with different functions depending on the gallery (with my "great" php skills), would be manually uploading a custom thumb and preventing it from being overwritten on the OS level.
Sorry, as mentioned above the sized image settings (height, width, longest and shortest side) do work for me as intended (even with one of your original images). My colleague @fretzl also tried and got the same results.
I really don't remeber all the discussions from years ago and a lot on this forum is naturally rather outdated because of changes over the years.
Those with the thumbs we can reproduce as that is as it is coded. We'll look into that though.
I don't exactly understand. The whole issue we are talking about is about non cropped thumbs and images. Custom crops are not possible if thumbs are not set to cropped anyway.
Please mind the terms to avoid confusion. "gallery" refers to the whole site actually, you are referring to one "album" (also see the glossary on our user guide please).
If you want different layouts per album you can use the multiple_layouts plugin. This again requires theme changes as you have to add theme pages for these layouts.
Best don't use the "album theme" feature to achieve this as it is not 100% sure if this feature will be kept in the future.
Strange. The other options work as intended here, just with "height" (unfortunately exactly the option I need), the image gets 780 width instead of 780 height. The custom functions cover this, though, so it's easy to work around.
Yes, I mean album.. I need a cropped thumb there (ONLY there) because with constant height, a pano thumb is very wide and destroys the layout of the index page: http://leitseite.net/photo/galleries.new/page/2/
A change to the CSS might be possible to keep the grid intact, but I rather not mess
with this.
With the old version, I did not have to use custom functions to get constant thumb height, therefore I could use a custom crop there.
I'll try the "upload 1 custom thumb into cache" workaround and then multiple_layouts if this does not work. Thanks.
Strange that the height does not work for you. One thing to check: You are sure that the image in question actually has 780 height originally? Just asking as Zenphoto by default does not upscale images on resizing unless you allow that Options > Image. That means if you request 600px widht or height and the full image (orignal image) has only 400 you would only get 400. That's nothing new though and default since forever.
We will be adding the four options to the thumbs sometime the next days as we agreed this is consistent to provide for uncropped thumbs.
The original 3:2 images are 5616 pixels wide.
In the Panorama album, the images look completely borked now, browser reports:
780px × 161px (scaled to 3,782px × 780px).
Replacing the thumbnail did not work, it gets squished into the space the layout of the page reserved for the smaller one. The problem is for such a wide image, the height is no longer constant but smaller than for the 3:2 shots. It's kind of the problem with the portrait images' thumbs in reverse..
Great to hear you'll be adding the new feature!
I cannot reproduce this. I used one of your panorama images for testing and it all worked as intended with 780px sizes plus all four options.
Again, when you change sizes it is important to clear the image cache afterwards. Otherwise some calcuations may use the new sizes but the image is still the same old size (as noted above already).
The basic theme (not your modified one which I cannot tell anything about) is made to fit around 595px in width so any image wider exceeds the layout on it (very old theme that does not get any updates anymore).
Yes, because the internal size attribute values are generated based on the settings, not on the image uploaded.
I had cleared the cache. But it seems I was confused, sorry: "height" works. What does not work is "shortest side" set to 780. Instead, the backend is applying this value to the longest side.
Sorry, I cannot reproduce this with your image ("dublin"). I get a correct 3782x780px with "shortest side" selected.
Be sure to also clear your browser cache by force. It may still show the old cached image from cache as it has the same name.
That is puzzling. The file on the server really is 780 pixels wide:
hzr1:/var/www/photo/galleries.new/cache/panorama$ file dublin_s_780.jpg
dublin_s_780.jpg: JPEG image data, JFIF standard 1.01, resolution (DPI), density 96x96, segment length 16, comment: "CREATOR: gd-jpeg v1.0 (using IJG JPEG v62), quality = 85", baseline, precision 8, 780x161, frames 3
It would be interesting to know why this happens. I am running PHP 7.0.33, the latest version available for Debian Stable. I read 7.1+ is the recommended version. That's all I can think of for now.
For some reason the width/height attributes are miscalculated on your site:
<img src="/photo/galleries.new/cache/panorama/dublin_s_780.jpg?cached=1594639794" alt="dublin_s" width="3782" height="780">.But I have no idea how this would happen except if embedded metadata is wrong so ZP uses that.
The width/height attributes are actually correct and conform to the defined 780 pixels height, that is why the browser is upscaling the cached jpeg. What is incorrect is the stored cached JPEG itself (780x161).
I cannot reproduce this, see screenshots here: https://www.zenphoto.org/test/
Since you are using a modified Basic theme try the original one from 1.5.7 just to be sure this is not an issue of your modification perhaps based on an old version.
It was modified from the current version, but I just copied the original theme from the 1.5.7 archive. Same result.
Sorry, if I cannot reproduce it I cannot fix anything.
I know.
All I could do is plug in a debug executable if you have one, and collect some data.
You could try the mark release plugin to enable some debugging modes
But if it is the image itself I would have to see it. Do you have both GD and Imagick for image processiong perhaps? If so try switching if it makes any difference (it should not, but…)
Imagick installed & enabled, same result.
I just tried on our own server's demo instal just to be sure that the local one does not behave differently: Here with 595px and height:
https://demo.zenphoto.org/test/dublin_s.jpg.html
(you might need to switch to the Basic theme on the top left if not enabled for you). Works as well as you can see.
Set installation to debug, not getting anything in the debug log though..
Ah, sorry, the plugin is not enough for image processing debugging. You have to hack a core file currently. Open zp-core/globa-definitions.php and find/set
define('DEBUG_IMAGE', false);totrue. Then you should get some info about image processing.