Symphony.

Am I right in thinking the current JIT Image Manipulation extension does nt handle CMYK colour space images?

Client sometimes gets logo’s sent to them in this format and unknowingly just upload them for processing and use in the site.

But the JIT extension does not interpret these files and results in no images being rendered in the front end.

Is it supposed to be able to convert to RGB colour space or is this an oversight on my half not to point this out from the start, that client should request RGB files from (their clients)?

I’m also interested in being able to convert a CMYK image to the RGB color space. I have a client who is asking entrants to upload a CMYK image to use in print later, and we’d like to be able to show a preview of the image that was uploaded on the confirmation screen.

Is there any thoughts or solutions for this issue upon uploading images to Symphony backend? I seem to be able to upload the image with CMYK colourspace but it won't display on the front end.. just an empty box.. does JIT not handle CMYK colour space images? or is there a means to convert to RGB on upload?

It's not that the extension chooses not to process CMYK images, it's that PHP doesn't have any tools that can; at least any that are often available.

I think it'd be possible to use the ImageMagik or GMagik extensions to do the processing instead, but I'm not sure how often these are enabled.

The mathematics behind getting a true RGB representation from a CMYK image is nearly impossible, even in image editors like Adobe Photoshop, hence the introduction of colour spaces and profiles etc. Even with these, image translations are always different. It has to do with the abilities of light creating colour, compared to pigment creating colour; RGB (light) is subtractive, ie less light, less colour, wheras CMYK (pigment) is additive, ie more pigment, less colour.

After working in Photography for print for many years (until recently), it has always been my wa to advise that all images used in digital workflows must be stored and transported in RGB. It has a larger colour space and can be a more true representation of the original. Once the image is to be printed, only then should it be converted to CMYK, and converted specifically for the printer in question.

It's a shame that the print industry never understands this.

If I were you, and this is only my opinion, the workflow needs to be changed. You won't be able to get an RGB preview from a CMYK image in PHP. Not without a lot of time and effort installing and configuring imageMagick, and even then, the results will be muddy and incorrect.

To summarise: RGB > CMYK, never CMYK > RGB

@designermonkey - this is good info. I guess the other CMS I use is using imageMagik or GDLibrary to convert the to RGB.. I do agree with you though.. the workflow should specify RGB before ingestion to the system.. but some users haven't got a means to check for colourspace before uploading.. Have instructed the requirements for files should be RGB when requesting them from clients. good to know this kinda stuff.. cos justifying it to clients is better when you have ammunition behind you :) !

Heh, I know that one!

Out of interest, which other CMSs have you seen this done in? If it can be done satisfactorily, then I would like to know how and see if it can be ported across...

http://getsymphony.com/discuss/thread/41003/#position-4

@buzzomatic, it's weird though, cos the image preview extension was able to show it within Symphony backend but the JIT did not render it on the front end of the site.. is the image preview extension tapping into something I don't know about?

@designermonkey - I've used CMS Made Simple cmsmadesimple.org in the past and the image manager module was configured to use GD I think.

For what it's worth, the JIT extension uses GD under the hood, so if GD can't do it, then JIT can't. The line in question:

if($meta->channels <= 3){ 
    $resource = @imagecreatefromjpeg($image);
}   
## Can't handle CMYK JPEG files 
else{
    throw new Exception(__('Cannot load CMYK JPG Images'));
}

I recall some newer (maybe experimental?) versions of GD that are able to load CMYK images though. Perhaps it's something extra that has to be installed or enabled at compilation time.

In this GD changelog, it says that basic CMYK support was added in 2.0.22

I might be looking in the wrong location like... but that's what a search cropped up for me.

EDIT Still doesn't deal with conversion to RGB though I guess. So in IE7 CMYK images would still not render.

If CMYK is supported for input then I wonder whether the output image from GD would retain the original type, or whether it would always be RGB after processing.

If RGB is the output format, then JIT should be updated so that instead of refusing to process an image when more than three channels exist, it should also check whether CMYK is supported (getting GD version number, or by feature detection by attempting to process).

I would love to see this work an I'm not adversed to eating my own hat after my continuous advice that it can't be done.

So wanna see you chowing down on a nice fedora hat :) hee hee..

EDIT Still doesn't deal with conversion to RGB though I guess. So in IE7 CMYK images would still not render.

If CMYK is supported for input then I wonder whether the output image from GD would retain the original type, or whether it would always be RGB after processing.

i just tested this, and cmyk images that are run through gd are automatically output as rgb.

i haven't bothered looking up what it would take to test your version of gd, but all i did to make jit handle cymk was comment out most of the lines that nick posted, ie, the conditional cmyk test (ln 78, 80-85).

woop.. good find :) - this should shut them client peoples up for a week! will test tomorrow - on dev server... cheers!

@fawx can you post which version of PHP and GD you have?

this is a very fresh install of apache and php (< 7 days), so i'm probably using whatever is most up-to-date.

PHP Version 5.3.3-1ubuntu9.3

GD Support          enabled
GD Version          2.0
FreeType Support    enabled
FreeType Linkage    with freetype
FreeType Version    2.4.2
T1Lib Support       enabled
GIF Read Support    enabled
GIF Create Support  enabled
JPEG Support        enabled
libJPEG Version     6b
PNG Support         enabled
libPNG Version      1.2.44
WBMP Support        enabled

Also, something to consider - PHP sometimes comes compiled with a custom version of GD that contains more features.

I'm not sure if it affects CMYK support at all, but it's worth noting while we're all talking about versions.

See here: http://au.php.net/manual/en/function.imagefilter.php

Note: This function is only available if PHP is compiled with the bundled version of the GD library.

i did it the easy way and just did apt-get install php-gd and ubuntu did everything from there, so it's hard to say if it was the bundled version or not.

My server seems to be running gd-2.0.34 which has CMYK support.