Black line on scaled thumbnail image

[nyoungman]

WordPress scales images down for thumbnails, but for some reason, in this case there is a black border on the top edge. See the bottom of this page:
​http://www.globalaid.net/projects/haiti-hurricane-relief-2008/

This is part of the image, not a style (try viewing the thumbnail):
​http://www.globalaid.net/wordpress/wp-content/uploads/2008/09/flooded-homes-1-240x240.jpg

And it is not part of the full image.

[ShaneF]

Very interesting... looking into this.

[ShaneF]

Seems to not do it on the 2.7.x version. Do you have any image plugins?

[DD32]

What version of PHP & GD are you using? The GD information from the phpinfo() page would be good..

It might not be related though..

[DD32]

I can confirm it happens when "Crop thumbnail to exact dimensions (normally thumbnails are proportional)" is disabled under trunk. (I used ​http://www.globalaid.net/wordpress/wp-content/uploads/2008/09/flooded-homes-1.jpg as a source image)

It appears to probably be caused by a rounding error or not enough precision somewhere.

[nyoungman]

Sorry for taking so long to come back to this.

@DD32 GD is bundled (2.0.34 compatible), all enaled with freetype 2.2.1 running on 5.2.8-0.dotdeb.1.

This is still a 2.6.5 installation of WordPress, I have not had the opportunity to test it in 2.7.x yet.

[Viper007Bond]

Replying to DD32:

I can confirm it happens when "Crop thumbnail to exact dimensions (normally thumbnails are proportional)" is disabled under trunk.

I think you mean enabled.

[DD32]

Replying to Viper007Bond:

Replying to DD32:

I can confirm it happens when "Crop thumbnail to exact dimensions (normally thumbnails are proportional)" is disabled under trunk.

I think you mean enabled.

Too long ago to know what i meant now.. But Enabled would make sense.

[miqrogroove]

This bug is fairly obvious at wp-includes/media.php::image_resize_dimensions()

If you take an image of size 1025 and resize to 100, the size ratio is 0.09756. Dividing that ratio into 100 gives ceil(1025.01) == 1026. So even at first glance, the cropping rectangle of 1026 is larger than the original image.

[miqrogroove]

hmmm This might need more testing because on my version of PHP I couldn't reproduce the rounding error unless I set the original dimensions to something like 1025.001.

[miqrogroove]

Fixes flawed cropping logic and inconsistent type juggling.

[miqrogroove]

Ah I was right. I was able to reproduce using OP's corner case:

$new_h = 240;
$orig_h = 416;
$size_ratio = $new_h / $orig_h;
$crop_h = round($new_h / $size_ratio);
var_dump($crop_h);
// float(417)

I tested and confirmed my patch will return int(416) instead of float(417) in that case.

[miqrogroove]

$new_h = 240;
$orig_h = 416;
$size_ratio = $new_h / $orig_h;
$crop_h = ceil($new_h / $size_ratio);
var_dump($crop_h);
// float(417)

ugh I hate this thing not having an edit button :(

[azaozz]

(In [12280]) Avoid a rare case of black line in cropped thumbnails, props miqrogroove, fixes #7748

[azaozz]

Don't think type casting is needed there. If it is, we should do it in the return array.

[miqrogroove]

Output still does not match function description, "Returned array matches parameters for imagecopyresampled() PHP function." If type casting is asking too much then at least correct the description to say the function returns an array of floats.

[miqrogroove]

Bump! The data type mismatch needs to be fixed, documented, or wontfix.

[azaozz]

(In [12381]) Typecast to int the return of image_resize_dimensions(), fixes #7748