[gdal-dev] Tiff file with CMYK colors that appears much worse with GDAL than in Windows Photo Viewer

Wed Jan 29 06:00:11 PST 2020

Thanks for the advice about ImageMagick, Lars. 

I found it hard to learn to use ImageMagick, though. But a co-worker suggested Krita which was easier to use, and it could convert my CMYK file to RGB in a nice way. 

I now believe my CMYK file lacks a CMYK color profile, so I suppose GDAL and other software cannot be blamed for bad results when they have to guess a CMYK profile for rendering on a screen. Maybe Windows Photo Viewer was just lucky that its default CMYK profile happens to work well with this particular image. At least I have learned that color management is even more horribly complex than I thought, and that CMYK profiles are very printer-specific so that CMYK should be avoided for general image storage.

Some of the gory details (if anyone else has a similar problem and is curious): the ImageMagick viewer, IMDisplay, also shows the file in the bad colors (too bright and saturated and cyan-ish). 
The command
        magick identify -verbose filename.tif
said (among a lot of other things):

    Colorspace: CMYK
    Type: ColorSeparation
    Rendering intent: Perceptual
    Gamma: 0.454545
    Chromaticity:
        red primary: (0.64,0.33)
        green primary: (0.3,0.6)
        blue primary: (0.15,0.06)
        white point: (0.3127,0.329)
    Matte color: grey74
    Background color: white
    Border color: srgb(223,223,223)
    Transparent color: none

I don't understand what the Chromaticity numbers mean: if they define the CMYK profile in some way, it is strange that IMDisplay showed the colors badly. (And the Chromaticity values do not appear in the output from gdalinfo.)

Krita displayed the image in a nice way at the first attempt. Krita's Image -> Properties dialog said

    Model: CMYK/Alpha
    Depth: 8-bit integer/channel
    Profile: Chemical proof (Default)

So I suppose both Krita and Windows Photo Viewer uses "Chemical proof" as the default CMYK profile, and it just happens to work well for this file. There is a dropdown list of CMYK profiles in Krita, but it contains only "Chemical proof" and "Agfa : Swop Standard", so if you need some other CMYK profile, it seems you have to load it from an .icc or .icm file (if you have such a file).

Cheers,  

Mikael Rittri
Carmenta Geospatial Technologies
www.carmenta.com

-----Original Message-----
From: gdal-dev [mailto:gdal-dev-bounces at lists.osgeo.org] On Behalf Of Lars Schylberg
Sent: den 21 januari 2020 18:45
To: gdal-dev at lists.osgeo.org
Subject: Re: [gdal-dev] Tiff file with CMYK colors that appears much worse with GDAL than in Windows Photo Viewer

Hi,

When I have more advanced needs in tiff-processing I usally use ImageMagick "convert" command.

It has more options to do advanced things with images.

Convert will complain that it doesn't understand the geotiff tags, but that is something You could ignore, it is just warnings.

Use the the tifflib utilities to reapply the the geo information to the tif-file when You are done.

     listgeo -no_norm original.tif > original.geo

     geotifcp -g original.geo modified.tif modified_geotiff.tif

The ImageMagick identify command could also be a useful tool.

Hope this will help You in the right direction

/Lars Schylberg, Saab

Den 2020-01-21 kl. 15:28, skrev Mikael Rittri:
> Hello, list. I need some advice.
>
> We have a customer with some Tiff files with CMYK colors. It is a 
> rasterized vector map, not an orthophoto, so the assigned colors are somewhat arbitrary, of course.
>
> The file colors look pleasant enough when opened with Windows Photo 
> Viewer, and these are the correct colors according to the customer. 
> When I open them with QGIS or Carmenta Engine, I get worse colors (but identical in QGIS and Carmenta Engine).
> Another GIS program I tried displays even worse colors.
>
> The bad colors appear lighter and more saturated, almost fluorescent, 
> and some hues are clearly different. For example, the original has 
> fairly dark, blue (and slightly green) texts in water, while the water 
> areas are a very light blue. In QGIS and Carmenta Engine, the texts in 
> water become saturated cyan and the water areas become a nearly white 
> cyan. The third GIS program I tried shows the same saturated cyan for texts in water but an almost-saturated cyan for water areas, which gives very bad contrast.
>
> I understand that to convert from CMYK to RGB one needs to know the 
> CMYK color profile (and the RGB color profile too, I guess).
>
> Window Properties says that the these Tiff files have "Color Representation: Uncalibrated".
>
> gdalinfo says, among other things, that
>
>    TIFFTAG_SOFTWARE=Adobe Photoshop CC (Windows)
>    SOURCE_COLOR_SPACE=CMYK
>
> and that the bands are Red/Green/Blue/Alpha. But I guess these band 
> colors mean after automatic color conversion to RGB, since gdalinfo 
> with "GTIFF_RAW:" prefixed to the file name says that bands are Cyan/Magenta/Yellow/Black.
>
> tiffinfo gives, among other things, a long XML text, x:xmpmeta, but 
> the only color information I could find in it was
>
>      <photoshop:ColorMode>4</photoshop:ColorMode>
>
> Finally, I noticed a section about "Color Profile Metadata" at 
> https://gdal.org/drivers/raster/gtiff.html,
> but I didn't understand how to use it.
>
> I guess my first question should be: how one would make the GDAL API 
> respect the Color Profile Metadata in our tiff files? It seems the 
> default setting does not respect some embedded CMYK profile that at 
> least Windows Photo Viewer can find? Or is the problem that Windows 
> Photo Viewer can pick up enough information from the XML line about photoshop:ColorMode = 4, while GDAL cannot find the CMYK profile from this kind of format?
>
> My understanding of color spaces is perhaps only halfway along 
> https://xkcd.com/1882, so I probably need some pretty basic hints on where to learn more!
>
> Regards,
>
> Mikael Rittri
> Carmenta Geospatial Technologies
> www.carmenta.com
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
gdal-dev at lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev