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:[email protected]] On Behalf Of Lars
Schylberg
Sent: den 21 januari 2020 18:45
To: [email protected]
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
> [email protected]
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
