hi,
When i try and create a thumb with printCustomAlbumThumbImage to be landscape from a portrait image the resulting thumb is distorted.

To me the function should always shrink any image to fit the width of the thumb and then cut off from the height to match the height
I am trying to create a 200x113 thumb of a 800x600 image without cropping on the width

Is there a quick solution for this?

You need to experiment a little with the additional parameter of the crop functions (width and height need to be set to crop) and best also clear the image cache. Please do a forum search we had a lengthly thread about that some time ago as far as I remember. Also look at the i.php file and the comments within it.

thanks for the reply. I had a good read through other threads but I have not come to an conclusion yet on how to work round the problem and I always look at the images directly to rule out CSS
Giving width,height,cropw,croph to the custom albumthumb function does not distorted but it also does zoom into the picture.
Have a look at this example:
www.bregler.net/backup/view.php

I also discovered it to be a general problem with both landscape and portrait pictures

Ideas anyone?

Try setting the cropwidth and height bigger than the width and height.

no, that didnt work. I tried varies things including setting cropwidth and cropheight to getWidth().

I am sorry I have no idea. Did you try to create a custom thumb using the crop tool and then assign that as an album thumb?

i am trying to analyse propsize and cacheimage function as I am convinced that these functions are not working right to cut landscape thumbs out of portrait images.

How do i activate DEBUG_IMAGE for logging?

You change the define.

If you didn't think of doing a search on that identifier, maybe you should consider if you will be able to understand the rest of the code....

thanks for the reply even though I could take less of your ego...
I did a full text search. xp must have missed it. I will try again. Thanks

Not so much ego as frustration with people who don't even attempt to answer their own questions. I could take MUCH less of that.

the frustration is understandable as a ZP alumni, but instead to affront
people who show interest in your creation you could as well write something
positive like just answer the (daft) question:

define('DEBUG_IMAGE', false); -> functions-basic.php l 17

so that it can be found through the search function

I really appreciate your work !

Well, as we all know sometimes written text comes out differently as meant. I agree that we probably should have a troubleshooting entry on how to enable the debug logs.

with the help of the DEBUG I got to the bottom of the thumbnail issue and have identified a bug.
It all boils down into the cacheImage function in functions-image.php.
The bug sits in the cropping logic after line 238.

The distortion is the result of incorrectly calculated $cw & $ch in there.

This bug can somehow be worked arround by setting the cropping width&height equal to the thumb width&height. But this then results into the described 'zoom' effect through the way the native php function 'imagecopyresampled' works.
..the disproportinal measure of the source & destination rectangle leads to this.

My question know is why the cropwidth & cropheight are handed into the core function from ZP at all? In my eyes it would make more sense to calculate the cropwidth & cropheight required on the fly instead by simply comparing image dimensions to desired thumb dimension and calculate the best fitting thumb that way ?

Is there a specific reason cacheImage works this way for other uses ?
Is the 'zoomed' thumb image considered a feature ?
Would anyone be interested in me rewriting the cacheImage function to minimize crop loss ?
or may this even be a specific behaviour of my GD lib (v2.0.34) on my webserver ?

My question know is why the cropwidth & cropheight are handed into the core function from ZP at all? In my eyes it would make more sense to calculate the cropwidth & cropheight required on the fly instead by simply comparing image dimensions to desired thumb dimension and calculate the best fitting thumb that way ?

I'm not really sure what you are saying here. Probably a terminology problem. But ALL image handling is done by the core functions. In fact, except for themes and plugins, there is nothing but core functions.

What do you mean by "on the fly" calcualtions? I would take this to mean as the script loads, which is exactly what happens.

Anyway, maybe you should share your trace information and how you are setting up the image. Then perhaps we can see what is going wrong.

using
printCustomAlbumThumbImage($gallery_title,'','200','113','200','113',Null,Null,'','');

on 500x336 landscape image creates an overly cropped but portrait pictures are not distorted. However the portrait pictures 336x210 get distorted if I use

printCustomAlbumThumbImage($gallery_title,'','200','113','','',Null,Null,'','');
needless to say that I want 200x113 thumb no matter the real underlying image
Is there a way to achieve this through tis function without touching the code ?

check these example: http://www.bregler.net/backup/view.php

What I mean with on the fly is why the $cropw, $croph are there at all ?
the only thing it leads to in my eyes is distortion. I think they should be calculated
automatically ($cw = round($w*$ir)).

.

What I mean with on the fly is why the $cropw, $croph are there at all ?
the only thing it leads to in my eyes is distortion. I think they should be calculated
automatically ($cw = round($w*$ir)).

So you would deny anyone setting those to their desired values?

Seems what you desire is pretty much what is done by the Efferevescence+ theme:
`printCustomAlbumThumbImage($annotate, null, 180, null, 180, 80);`

i'm not certain why your first call overly cropped the image. Have to look into that. The second one, though said "create a 200x113 image from the original" (no cropping). Naturally that would be a distorted image.

here is the extract of the really extreme cases of bad thumbs:

www.bregler.net/backup/log.txt

I quickly configured the examples here : http://www.dev.bregler.net/gallery/

yeah I tested the null,200,null,200,113 combination,
but still I get the over cropped result.

compare: http://www.dev.bregler.net/gallery/2000/Wolf_und_Hilal__Hamburg__2000__pbh.jpg.php
to the thumb at http://www.dev.bregler.net/gallery/

the problem is exactly the same as decribed in my debug log
$cw=368, $ch=208 are wrong !
it should be $cw=500, $ch=282; ($ch=500*113/200)

Which is a bug I believe to be in the cacheImage function

for now I have duplicated the cacheImage in a custom function
for myself, but I put this forward to go in as a bug-fix as it adds flexability

the current code is not ready to create portrait thumbs from landscape images and vice versa

to do this

$cr = min($w, $h)/$ts; (line 135)

has to be replaced with

if ($neww > $newh) $cr=$w/$ts; else $cr=$h/$ts;

What do the local developer heros say?