Ghostscript tiffsep creates CMYK image that is inverted in ImageMagick display?

Question

Not sure what to make of this - but let's say we work with this PDF file: https://stlab.adobe.com/wiki/index.php/File:Test.pdf, and I want to obtain separations using Ghostscript's tiffsep device:

cd /tmp
wget https://stlab.adobe.com/wiki/images/d/d3/Test.pdf
ghostscript -q -sDEVICE=tiffsep -dNOPAUSE -dBATCH -dSAFER -r72x72 -sOutputFile=testseps.tif -dFirstPage=1 -dLastPage=1 Test.pdf
eog testseps.tif & display testseps.tif

This generates five files: testseps(Black).tif, testseps(Cyan).tif, testseps(Magenta).tif, testseps.tif, testseps(Yellow).tif. I open the full-color output (testseps.tif) in both Eye of Gnome (eog), and ImageMagick's display, and this is what I get (Ubuntu 14.04, MATE desktop, ghostscript 9.10, ImageMagick 6.7.7-10 2017-03-14 Q16):

Namely, ImageMagick's display (left) shows this file with inverted colors, while Eye of Gnome (right) shows the very same file correctly?!

So how can I get this CMYK tiff to show correctly in both display and Eye of Gnome? Can I somehow convert it with ImageMagick's convert, and what would the command line be? I've already tried something like:

convert testseps.tif -colorspace CMYK -alpha off -define quantum:polarity=min-is-white -colorspace CMYK testseps2.tif

... and that file again shows the same problem.

EDIT: Also, if I try to combine the individual separations using convert:

convert \
testseps\(Cyan\).tif \
testseps\(Magenta\).tif \
testseps\(Yellow\).tif \
testseps\(Black\).tif \
-set colorspace CMYK \
-profile /usr/share/ghostscript/9.10/iccprofiles/default_cmyk.icc 
-combine 
combined.tif

... then combined.tif shows properly in ImageMagick display - but is shown as completely black in Eye of Gnome! If I add the -negate switch after -combine, then I'm back to the previous state (display shows inverted, eog shows correct)

EDIT2: Tried to use a service http://www.rgb2cmyk.org/, to obtain a CMYK tif of the RGB screenshot posted here, and that one also shows the same bug: it is inverted in display, and shown correctly in Eye of Gnome.

Just for reference, here is a bit of info about testseps.tif:

$ tiffinfo testseps.tif 
TIFF Directory at offset 0x8 (8)
  Subfile Type: multi-page document (2 = 0x2)
  Image Width: 612 Image Length: 792
  Resolution: 72, 72 pixels/inch
  Bits/Sample: 8
  Compression Scheme: LZW
  Photometric Interpretation: separated
  FillOrder: msb-to-lsb
  Orientation: row 0 top, col 0 lhs
  Samples/Pixel: 4
  Rows/Strip: 428
  Planar Configuration: single image plane
  Page Number: 0-0
  Software: GPL Ghostscript 9.10
  DateTime: 2017:04:10 12:53:45
  ICC Profile: <present>, 56412 bytes
$ identify -verbose testseps.tif 
Image: testseps.tif
  Format: TIFF (Tagged Image File Format)
  Class: DirectClass
  Geometry: 612x792+0+0
  Resolution: 72x72
  Print size: 8.5x11
  Units: PixelsPerInch
  Type: ColorSeparation
  Endianess: MSB
  Colorspace: CMYK
  Depth: 8-bit
  Channel depth:
    cyan: 8-bit
    magenta: 8-bit
    yellow: 8-bit
    black: 8-bit
  Channel statistics:
    Cyan:
      min: 0 (0)
      max: 235 (0.921569)
      mean: 5.93515 (0.0232751)
      standard deviation: 33.3466 (0.130771)
      kurtosis: 28.8423
      skewness: 5.53334
    Magenta:
      min: 0 (0)
      max: 245 (0.960784)
      mean: 2.7823 (0.010911)
      standard deviation: 18.73 (0.0734511)
      kurtosis: 68.8725
      skewness: 8.12072
    Yellow:
      min: 0 (0)
      max: 255 (1)
      mean: 5.04176 (0.0197716)
      standard deviation: 30.8529 (0.120992)
      kurtosis: 34.9211
      skewness: 6.05297
    Black:
      min: 0 (0)
      max: 226 (0.886275)
      mean: 1.06569 (0.00417917)
      standard deviation: 13.7509 (0.0539252)
      kurtosis: 227.454
      skewness: 15.0002
  Image statistics:
    Overall:
      min: 0 (0)
      max: 255 (1)
      mean: 3.70622 (0.0145342)
      standard deviation: 25.5137 (0.100054)
      kurtosis: 51.8946
      skewness: 7.28691
  Total ink density: 298%
  Rendering intent: Undefined
  Gamma: 1
  Interlace: None
  Background color: cmyk(255,255,255,0)
  Border color: cmyk(223,223,223,0)
  Matte color: cmyk(189,189,189,0)
  Transparent color: cmyk(0,0,0,0)
  Compose: Over
  Page geometry: 612x792+0+0
  Dispose: Undefined
  Iterations: 0
  Compression: LZW
  Orientation: TopLeft
  Properties:
    date:create: 2017-04-10T12:53:45+02:00
    date:modify: 2017-04-10T12:53:45+02:00
    signature: 1ad1532f697fa72492fe994d79f1b67d617a34cd927f31b41e6a12214b9bc49e
    tiff:endian: lsb
    tiff:photometric: separated
    tiff:rows-per-strip: 428
    tiff:software: GPL Ghostscript 9.10
    tiff:timestamp: 2017:04:10 12:53:45
  Profiles:
    Profile-icc: 187484 bytes
      Description: Artifex CMYK SWOP Profile
      Manufacturer: Artifex CMYK SWOP Profile
      Model: Artifex CMYK SWOP Profile
      Copyright: Copyright Artifex Software 2011
  Artifacts:
    filename: testseps.tif
    verbose: true
  Tainted: True
  Filesize: 220KB
  Number pixels: 485K
  Pixels per second: 24.24MB
  User time: 0.020u
  Elapsed time: 0:01.019
  Version: ImageMagick 6.7.7-10 2017-03-14 Q16 http://www.imagemagick.org

Answer 1

I suspect there is no actual bug here, and certainly not a Ghostscript one. The problem is with the interpretation of 0.

Your monitor can't display CMYK inks, and so the CMYK in the file need to be converted to RGB for display. Now for RGB when R=G=B=0 then the result is black, when R=G=B=1 (0r 255 for an 8-bit display) then the result is white.

RGB is an additive colour model, CMYK by contrast is a subtractive model; when you lay down multiple inks you are actually subtracting from the light reflected by the p;age, as opposed to RGB where you add light to get a colour.

So when you get C=M=Y=K=0, what does that actually mean ? The general convention is that it means white, because people generally print on white media. Of course, if your paper was, say, green, then the result of printing CMYK=0 wouldn't be 'white' it would be green.

Its understandable (if unconventional) to represent an absence of colourant in CMYK as an absence of colourant in RGB. So CMYK=0 -> RGB=0 and the result is black.

Conventionally of course, we expect CMYK=0 to be white.

I am not any kind of expert in ImageMagick, but I suspect that's what's going on, its doing a CMYK->RGB conversion and just mapping CMYK=0 to RGB=0, so you get black. Assuming that the output from using convert to combine the separations is a CMYK file you could look at the first few bytes of the raster to see how IM is writing CMYK=0. Either you will get 00 00 00 00 or you will get something else. You might also want to look at the PhotmetricInterpretation TIFF tag and see how its set in the 2 cases.

Anyway, if its a difference in how photmetricitry is interpreted, then I don't think its going to be possible to get a single file which works as you expect on both applications. One thinks that CMYK=0 is black, the other thinks its white.