Make WordPress Core

Opened 15 years ago

Closed 13 years ago

Last modified 8 years ago

#11671 closed defect (bug) (duplicate)

Image Saturation Loss on Resize

Reported by: miqrogroove's profile 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 (27)

#1 @miqrogroove
15 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.

#2 @miqrogroove
15 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.

#3 @dd32
15 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

#4 @miqrogroove
15 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.

#5 @dd32
15 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

#6 @miqrogroove
15 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?

#7 @miqrogroove
15 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.

#8 follow-up: @miqrogroove
15 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.

#9 @miqrogroove
15 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?

#10 @dd32
15 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.

#11 @miqrogroove
15 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.

#12 @dd32
15 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.

#13 @miqrogroove
15 years ago

  • Milestone changed from 3.0 to 3.1

Alrighty, consider it punted!

#14 @scribu
15 years ago

  • Keywords needs-testing removed

#15 in reply to: ↑ 8 @scribu
15 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

#16 @miqrogroove
15 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.

#17 @scribu
15 years ago

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

#18 @codyph55
15 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?

#19 @markjaquith
15 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.

#20 @codyph55
15 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.

#21 @apeatling
15 years ago

  • Cc apeatling added

#24 @scribu
14 years ago

  • Milestone changed from Awaiting Triage to Future Release

#25 @sussane
14 years ago

[spam comment removed by lloydbudd]

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

#26 @scribu
13 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

#27 @kelecz
8 years ago

I know is old topic but maybe someone google it.

Just convert image(s) from CMYK to RGB. Just create action in Photoshop if you have big number of files.

Note: See TracTickets for help on using tickets.