Round-trip ICC conversion

[spongemonkey]

Hopefully this will be an interesting one...

We have an image in CMYK (with ICC profile), with a limited number of colours having special, fixed values in each of the 4 channels, (e.g. C=0%, M=0%, Y=100%, K=100% as well as C=100%, M=100%, Y=100%, K=100%). We need to be able to convert this to sRGB and then back again (after a little processing that requires sRGB*) so that the final CMYK image will contain exactly the same colours.

For example: ordinarily the CMYK colour for something funky like (Q16 here) cmyk(65535,65535,0,65535) converts to srgb(100,0,0) then back to cmyk(47364,44355,44035,56149). We would like a way of getting it to convert back to cmyk(65535,65535,0,65535).

Given we have only a few colours in the original CMYK image, my naive, brute force approach was to create a lookup table in C++ that will store key/value pairs for each of the colours (srgb(100,0,0) being a key with value cmyk(65535,65535,0,65535) in the example above), then iterate over the sRGB image's pixels replacing the keys with their values from the lookup table.

Is there a better way to achieve what we want? If not, are there any wizards that could offer some guidance in coding up my above approach in an IM compliant way (ideally leveraging multiple cores, and implementing IM's progress reporting pattern)?

Any input greatly appreciated.


*the processing won't introduce any new colours into the image

[snibgo]

As you have only a limited range (but large number?) of colours and (I assume) a well-defined algorithm for both directions, you might find the quickest solution (for both programming time and execution time) is to create your own ICC profiles. Then you can use any off-the-shelf tool, such as IM, to do the conversions.

If you have a small number of colours, solutions that are simpler for programming but more expensive at execution are possible, eg:

1. Find the first CMYK "red" pixel.
2. Flood-fill from there to the RGB "red" colour.
3. Find the next CMYK "red" pixel and repeat from (2).
4. Repeat from (1) for the next colour.

[spongemonkey]

If g mapped the original CMYK image to sRGB then the desired map f would be defined by



for each colour i.

I think the ICC profile sounds like the way to go. This would mean the ICC profile would be a function of the original image, so I would need to generate the profile programatically. I know this is venturing beyond the realms of IM now, but do you or anyone else happen to know how I would go about producing such a file? Literature at color.org seems quite intimidating to a novice such as myself. Is it only "quick" if you're an expert? I'm currently working my way through a bunch of pdfs

Thanks for your help

[snibgo]

A couple of years ago I used the "ICC Profile Inspector" from http://www.color.org/profileinspector.xalter to create my own profiles for various weird purposes. There's a fair bit of learning involved with generating profiles.

As you probably know, profile processing is based on curves (and matrices) that are defined by nodes. I expect that an exact round-trip conversion would need you to define the nodes where you need the exact conversions. You can supply these as text, imported to IPI, so you don't need to worry about the binary format of ICC files.

The process is very quick, in the same sense that as completing a self-assessment tax form is very quick -- once you have the data and understand where it goes, it's a doddle.