landscape thumb of portait img distorted

breglis

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?

acrylian

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.

breglis

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?

acrylian

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

breglis

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

acrylian

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?

breglis

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?

sbillard

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....

breglis

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

sbillard

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.

breglis

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 !

acrylian

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.

breglis

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 ?

sbillard

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.

breglis

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)).

breglis

.

sbillard

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.

breglis

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/

breglis

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

breglis

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?

sbillard

Give the nightly build a try after tonight. I did change the code to make it (what I think is) correct. However I can't see the problems (nor the difference with the new code) that you have, so it needs some more testing.

breglis

thanks sbilliard for looking into this.
I am not trying to make a point here, as I said it is solved for myself so I am fine. I am just trying to help making ZP better.
I am not sure I understand you saying that the code change has no effect?
So when you create a cropped thumb out of a landscape image you do not get the zoom?
Have you had a look at the log file?
At the moment the min() function multiplies the image height with the crop ratio to calculate the crop width. $cw.

Btw I also would like to mention that most thumbs look better when $cy is calculated to be off center towards the top just like when mounting real pictures.
line 282 ....divide by 3 instead of 2...
This has to do with the law of thirds. A basic design principle most photos follow.

sbillard

What I was saying is that I have not seen the "zoom" that you did. Not sure why, but in my testing I don't see a difference between the "correct" code and the wrong code. Thus I am not sure if the problem is really fixed.

Your suggestion to use the law of thirds is a good one. Hopefully no one will object to the change in behavior.

breglis

ok, I see. I have done the calculations manually and have added them to the log file at the bottom : http://www.bregler.net/backup/log.txt
for both an 500x336 and an 233x336 crop calculation to come by a 200x113 tumb
Maybe that helps you to repeat the issue I had

I have change the $cy in my custom function to "/3" and I think it looks a lot better.
So for everybody who is not familiar with the law of thirds here is some reading:
http://www.silverlight.co.uk/tutorials/compose_expose/thirds.html
A lecturer of mine used to say that you can break every rule if you know them and know why; I am sure there is plenty of exceptions which are still great pictures but especially in framing and mounting it is almost certainly used:
http://en.wikipedia.org/wiki/Headroom_(photographic_framing)
I would vote for this go into the next release

sbillard

I guess I just had "well behaved" images. Both portrait and landscape came out well. Anyway, give the nightly build a try and report back. (Tonight's will have the rule of thirds change.)