WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 4 years ago

#7748 closed defect (bug) (fixed)

Black line on scaled thumbnail image

Reported by: nyoungman Owned by:
Milestone: 2.9 Priority: normal
Severity: normal Version: 2.6.1
Component: Media Keywords: has-patch tested
Focuses: Cc:

Description

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.

Attachments (1)

wp-includes-media.php.patch (724 bytes) - added by miqrogroove 4 years ago.
Fixes flawed cropping logic and inconsistent type juggling.

Download all attachments as: .zip

Change History (21)

comment:1 ShaneF6 years ago

  • Keywords image resize image uploading added

Very interesting... looking into this.

comment:2 ShaneF6 years ago

  • Keywords dev-feedback added

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

comment:3 DD326 years ago

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

It might not be related though..

comment:4 follow-up: DD326 years ago

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.

comment:5 nyoungman5 years ago

  • Cc nyoungman added

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.

comment:6 in reply to: ↑ 4 ; follow-up: Viper007Bond5 years ago

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.

comment:7 in reply to: ↑ 6 DD325 years ago

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.

comment:8 Denis-de-Bernardy5 years ago

  • Keywords needs-patch added; image resize image uploading dev-feedback removed
  • Milestone changed from 2.8 to Future Release

comment:9 Denis-de-Bernardy5 years ago

  • Component changed from General to Upload
  • Owner anonymous deleted

comment:10 Denis-de-Bernardy5 years ago

  • Milestone changed from Future Release to 2.9

comment:11 miqrogroove4 years ago

  • Keywords has-patch needs-testing added; needs-patch removed

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.

comment:12 miqrogroove4 years ago

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.

miqrogroove4 years ago

Fixes flawed cropping logic and inconsistent type juggling.

comment:13 miqrogroove4 years ago

  • Keywords tested added; needs-testing removed

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.

comment:14 miqrogroove4 years ago

$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 :(

comment:15 miqrogroove4 years ago

  • Component changed from Upload to Media

comment:16 azaozz4 years ago

  • Resolution set to fixed
  • Status changed from new to closed

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

comment:17 azaozz4 years ago

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

comment:18 miqrogroove4 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

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.

comment:19 miqrogroove4 years ago

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

comment:20 azaozz4 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

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

Note: See TracTickets for help on using tickets.