Make WordPress Core

Opened 4 years ago

Closed 10 months ago

#47840 closed enhancement (wontfix)

Weird colors when users upload CMYK JPG images

Reported by: lexo_ch's profile lexo_ch Owned by:
Milestone: Priority: normal
Severity: minor Version: 5.2.2
Component: Media Keywords:
Focuses: ui Cc:

Description (last modified by SergeyBiryukov)

When a user uploads an image which uses the CMYK color spectrum and WordPress applies its magic to the image the colors become very much mixed up.

It would be nice if WordPress would recognize the image format and perhaps convert the CMYK image to an RGB before applying the image optimizations.

How to reproduce the problem?

  1. Go to Gallery (media)
  2. Upload a JPG image which uses the CMYK color spectrum
  3. Watch how e.g. the color green becomes yellow ;)

Attachments (1)

Test CMYK image.jpg (1.5 MB) - added by lexo_ch 4 years ago.
Test CMYK file

Download all attachments as: .zip

Change History (9)

#1 @SergeyBiryukov
4 years ago

  • Component changed from Gallery to Media
  • Description modified (diff)

#2 @Otto42
4 years ago

WordPress doesn't actually have any code to do images on that level, it uses the available libraries already installed on the host, like GD or ImageMagick, to do that grunt work.

So, if something is wrong there, then you need to identify specifically which versions of which libraries are causing the issue. Workarounds might be found, but you'd need to identify them and provide example images that can reproduce the problem.

@lexo_ch
4 years ago

Test CMYK file

#3 @lexo_ch
4 years ago

I uploaded the test image file to multiple wordpress instances on different servers / providers - it always bugs out. Sometimes the guys' shirt is yellow, sometimes the image becomes extremely dark.

#4 @olivM
2 years ago

Imagick has a setColorSpace method that can address this issue

so we could add this in WP_Image_Editor_Imagick class

<?php

class WP_Image_Editor_Imagick extends WP_Image_Editor {

[...]

    /**
     * Sets Image Color Space
     *
     *
     * @param int $colorSpace Color Space
     * @return true|WP_Error True if set successfully; WP_Error on failure.
     */
    public function set_color_space($colorSpace = null)
    {
        if ('image/jpeg' === $this->mime_type) {
            try {
                $this->image->setColorSpace($colorSpace);
            } catch (Exception $e) {
                return new WP_Error('image_color_space_error', $e->getMessage());
            }
        }

        return true;
    }

#5 follow-up: @desrosj
10 months ago

  • Keywords close added; needs-patch removed

I'm leaning towards closing this out as a duplicate of #36684, but would like a bit more information first.

@lexo_ch do you recall which browser you were using when you observed these strange colors? If it was Edge/IE, then it does indeed seem to be a duplicate.

If the issue was visible in multiple browsers, it is likely an issue with the version of ImageMagick/Imagick installed on your server. Could you check in Site Health and share the versions being used when you are able to reproduce this?

If you are still able to reproduce this, it could strengthen the argument to enforce RGB color models on all generated images as described in ticket:36684#comment:8.

#6 @desrosj
10 months ago

  • Keywords reporter-feedback added

#7 in reply to: ↑ 5 @lexo_ch
10 months ago

Replying to desrosj:

@lexo_ch do you recall which browser you were using when you observed these strange colors? If it was Edge/IE, then it does indeed seem to be a duplicate.

All browsers. Since the image was generated like that. Downloading the image and opening it locally showed the same wrong color space.

If the issue was visible in multiple browsers, it is likely an issue with the version of ImageMagick/Imagick installed on your server. Could you check in Site Health and share the versions being used when you are able to reproduce this?

It's been 3 years. We work with WebP now. It would take us too much time to reproduce this. With WebP and newest WP versions there's no issues anymore. In our opinion this issue can be closed. Could have been a compatibility issue with Imagick back then. Have not noticed this behaviour anymore in the past ~1.5 years.

Thank you for looking into this once more.

#8 @desrosj
10 months ago

  • Keywords close reporter-feedback removed
  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Thanks for the follow up @lexo_ch!

Let's close this one out. If someone else is still dealing with this issue and can provide more context, this can be reopened.

Note: See TracTickets for help on using tickets.