WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 3 years ago

#11671 closed defect (bug) (duplicate)

Image Saturation Loss on Resize

Reported by: miqrogroove Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Media Keywords:
Focuses: Cc:

Description

I was going through some archives today, and noticed a pattern where many images have noticeably reduced color saturation in the Large or Small size image compared to the full size. When looking at the original and resized versions side by side, the resized version looks really bad.

This is happening inconsistently, with some images and not others.

I will attach some examples when I have more time to test this.

Change History (26)

comment:1 miqrogroove4 years ago

  • Milestone 3.0 deleted
  • Resolution set to invalid
  • Status changed from new to closed

Problem was confined to older archives, so this must have been fixed in 2.7 or 2.8.

comment:2 miqrogroove4 years ago

  • Milestone set to 3.0
  • Resolution invalid deleted
  • Severity changed from major to normal
  • Status changed from closed to reopened

I found the problem. It's not invalid, but by all means feel free to 'wontfix'.

Any time an image is uploaded, if that image was saved in the Adobe RGB color space, then the image does not get loaded correctly for resizing. Thumbnails are saved in the default color space, which is sRGB. By failing to perform the color conversion, and then failing to specify the non-default color space in EXIF, thumbnails are produced with colors that are noticeably different from the original.

The real annoyance here is that many programs, including web browsers, don't read the EXIF color space in the first place. In the web browser, thumbnails are rendered the same way as the original, which also appears to have the wrong colors.

On the other hand, this problem can become very obvious when surfing through the uploads directory with a program like Windows Picture and Fax Viewer, which does render the original image correctly.

comment:3 dd324 years ago

This isnt the first time i've seen this mentioned, For a visual version for others, see: http://www.darcynorman.net/2008/05/07/on-wordpress-image-resizing/

Unfortunately I dont think its possible to preserve the colour space or convert it properly using GD

comment:4 miqrogroove4 years ago

Workaround: Convert images to sRGB before uploading them.

Band-aid: WordPress could inform the user if any non-sRGB images get uploaded. (Plugin?)

Solution: If the EXIF data were maintained on thumbnails, then there would be no discrepancy with the original image.

Unfortunately I dont think its possible to preserve the colour space or convert it properly using GD

After giving it some thought, conversion would be a case of the cure being worse than the disease. Since browsers aren't color-aware, the sRGB thumbnails would look different from non-sRGB originals. I think "preserving" is the one to aim for if it's doable.

comment:5 dd324 years ago

Solution: If the EXIF data were maintained on thumbnails, then there would be no discrepancy with the original image.

EXIF cannot be written directly via GD, IPTC is available however (Pretty sure thats a separate thing?)

There are some PHP-based EXIF embedders however, such as: http://www.ozhiker.com/electronics/pjmt/index.html which is linked in the comments of http://au.php.net/manual/en/function.iptcparse.php

comment:6 miqrogroove4 years ago

p.s. I'm not 100% sure the color profile itself gets saved in EXIF, as opposed to some other JPEG header. I was looking at the "Color space" EXIF field earlier, which might be only a human-readable enumeration. Anyone already experienced with that?

comment:7 miqrogroove4 years ago

Yep, the "color profile" appears to be an independent file, like a thumbnail, that gets stored in a JPEG application header. So, we're not looking for EXIF per se, but a way to preserve EXIF-like application blobs.

comment:8 follow-up: miqrogroove4 years ago

This probably needs punting. I know the application headers can be extracted with ~20 lines of file stream goodies, but writing headers back into a new file might be re-inventing the wheel. I certainly have higher priorities anyway.

comment:9 miqrogroove4 years ago

http://www.php.net/manual/en/function.imagick-profileimage.php

Appears to be equivalent to "convert -profile", which I've used successfully to convert Adobe RGB to sRGB in a Windows command prompt. There are related functions for fetching and applying color profiles. We might be able to sidestep the problem entirely by using Imagick::resizeImage instead of GD.

Is ImageMagick prevalent enough for this to be viable?

comment:10 dd324 years ago

Is ImageMagick prevalent enough for this to be viable?

I think thats been brought up before.

Short Answer: No.

Longer answer, Was that if ImageMagik is available, theres no reason we cant use it, and fall back to it when GD isnt available.

comment:11 miqrogroove4 years ago

dd32, Thanks for the input. I'll make ya a deal. If you'd be willing to commit, and if my server has ImageMagick compiled, then I will write a patch for thumbnail generation to use ImageMagick first and GD2 as fallback. No plans for abstracting it to high heavens, but perhaps a step in that direction.

comment:12 dd324 years ago

I'd highly prefer to use GD if its available, and only use ImageMagik as a fall back..

But that being said, The time to change a large section to use ImageMagik has probably passed for 3.0 now.

comment:13 miqrogroove4 years ago

  • Milestone changed from 3.0 to 3.1

Alrighty, consider it punted!

comment:14 scribu4 years ago

  • Keywords needs-testing removed

comment:15 in reply to: ↑ 8 scribu4 years ago

Replying to miqrogroove:

This probably needs punting. I know the application headers can be extracted with ~20 lines of file stream goodies, but writing headers back into a new file might be re-inventing the wheel. I certainly have higher priorities anyway.

Look what I've found: http://code.trac.wordpress.org/browser/imagelibs/libjpeg.php

comment:16 miqrogroove4 years ago

You should be reading the comments after that one. I abandoned the header extraction idea as soon as I realized ImageMagik is already capable of proper thumbnails.

comment:17 scribu4 years ago

I did. Just thought it was an interesting piece of code.

comment:18 codyph554 years ago

Is there any fix for this yet? I am not a coder per se, but I have been struggling with this de-saturation issue for a while. Is there a place i need to put any new code?

comment:19 markjaquith4 years ago

I have the opposite problem. My photos become MORE saturated. The original file has an sRGB profile, but the WordPress-resized one has no profile.

WordPress resize on the left, original on the right. Note how there is no color profile for the WordPress one. The one on the right has: Profile Name: sRGB IEC61966-2.1

http://img689.imageshack.us/img689/6047/screenshot20100421at425.png

The best solution, from a user's perspective, would be to convert all images to sRGB (and use that profile). SmugMug does that. http://www.smugmug.com/help/srgb-versus-adobe-rgb-1998 Second best would be to preserve the profile that came with it. Stripping the profile without converting the image is the worst of all.

comment:20 codyph554 years ago

It seems to me that it is a 2-way street, and the main problem here is wordpress is not preserving the color space correctly when converting the pictures, even though they are uploaded correctly in sRGB.

comment:21 apeatling4 years ago

  • Cc apeatling added

comment:24 scribu4 years ago

  • Milestone changed from Awaiting Triage to Future Release

comment:25 sussane3 years ago

[spam comment removed by lloydbudd]

Last edited 3 years ago by lloydbudd (previous) (diff)

comment:26 scribu3 years ago

  • Milestone Future Release deleted
  • Resolution set to duplicate
  • Status changed from reopened to closed

Found a 3 year old (blessed) ticket by Matt: #6821

Note: See TracTickets for help on using tickets.