#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 (27)
#2
@
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
@
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
@
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
@
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
@
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
@
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:
↓ 15
@
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
@
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
@
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
@
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
@
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.
#15
in reply to:
↑ 8
@
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
@
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.
#18
@
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
@
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
@
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.
Problem was confined to older archives, so this must have been fixed in 2.7 or 2.8.