Bug 689512 - Differences in rgb vs cmyk output (tiff24nc vs. tiff32nc)
Summary: Differences in rgb vs cmyk output (tiff24nc vs. tiff32nc)
Status: NOTIFIED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Color (show other bugs)
Version: master
Hardware: PC Linux
: P2 normal
Assignee: Michael Vrhel
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-10-15 15:29 UTC by Marcos H. Woehrmann
Modified: 2011-09-18 21:47 UTC (History)
0 users

See Also:
Customer: 190
Word Size: ---


Attachments
t8.pdf (47.79 KB, application/pdf)
2009-09-18 07:05 UTC, Masaki Ushizaka
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marcos H. Woehrmann 2007-10-15 15:29:00 UTC
The customer reports and I've verified that the file MalliPDF-Ocelle.pdf renders very differently when 
output to a RGB device vs. a CMYK device using gs8.60 and gshead (r8285).  The file is large, so it's on 
casper:/home/support/689512/MalliPDF-Ocelle.pdf

The difference does appear on all computers/operating systems, but does happen on both peeves and 
casper.

The command lines I used for testing:

  bin/gs -sDEVICE=tiff24nc -sOutputFile=rgb.tif -r30 ./MalliPDF-Ocelle.pdf

and

  bin/gs -sDEVICE=tiff32nc -sOutputFile=cmyk.tif -r30 ./MalliPDF-Ocelle.pdf
Comment 1 Marcos H. Woehrmann 2007-10-15 15:29:36 UTC
That should be:

The difference does NOT appear on all computers/operating systems, but does happen on both peeves 
and 
casper
Comment 2 Ray Johnston 2007-11-09 10:19:01 UTC
This appears to be a transparency problem, probably related to the way GS uses
the Device native colorspace as the blending color space (instead of using the
/CS colorspace given in the transparency group attributes).

I will attempt to trim this file down to a small example that still shows the
problem. In the meantime, I will attach the complete customer file.
Comment 3 Ray Johnston 2007-11-09 10:21:36 UTC
Created attachment 3535 [details]
MalliPDF-Ocelle.pdf
Comment 4 Ralph Giles 2008-04-01 10:41:28 UTC
FWIW, I can't see a difference between those two command lines on x86_64 linux
or x86_32 MacOS.
Comment 5 Marcos H. Woehrmann 2008-04-09 12:54:14 UTC
Please try running the file on casper:

bin/gs -sDEVICE=tiff24.nc -o test24.tif ./MalliPDF-Ocelle.pdf
bin/gs -sDEVICE=tiff32.nc -o test32.tif ./MalliPDF-Ocelle.pdf


See screenshot.png attached.
Comment 6 Marcos H. Woehrmann 2008-04-09 12:54:31 UTC
Created attachment 3928 [details]
screenshot.png
Comment 7 Ralph Giles 2008-05-20 16:42:41 UTC
transferring to Michael.
Comment 8 Michael Vrhel 2009-02-16 20:21:53 UTC
This renders properly with the softmask branch
Comment 9 Marcos H. Woehrmann 2009-06-09 11:03:17 UTC
This issue is not resolved with the soft mask branch.  Head (r9784) still
produces different output on casper.
Comment 10 Masaki Ushizaka 2009-08-10 05:42:30 UTC
Tried with r9948.

Mac OS X 10.5.7 + Xcode 3.1.2: Reproduced.
Windows XP Pro SP3 + VS2008 Express SP1: Not reproduced.
Windows 2000 Pro SP4 + VS6 SP6: Reproduced.

I don't know it relates, but when I tried to open this pdf file with Illustrator CS4, it complained that it 
found unknown type of fill.  This (autocad-generated?) pdf file may contain its own flaws.
Comment 11 Masaki Ushizaka 2009-09-18 07:05:41 UTC
Created attachment 5392 [details]
t8.pdf

First, let me correct previous comment #10.  This does reproduce on Windows XP
Pro SP3 + VS2008 Express SP1 (or not, see below).  The thing is this problem
doesn't show up using GIMP.
Attached is a PDF file created using Illustrator.  It is a 10pt by 10pt size
document and filled with a color (rgb=115,166,125) with 70% transparency.  This
is a imitation of color used in 'MalliPDF-Ocelle.pdf' named 'Erikoispinnoite'.
I ripped this with following command.

$ bin/gs -DBATCH -sDEVICE=tiff24nc -o t8r.tiff t8.pdf
$ bin/gs -DBATCH -sDEVICE=tiff32nc -o t8c.tiff t8.pdf 

Resulted tiff files show same difference when using Apple preview 4.2 and Adobe
PhotoShop CS4, but looks same when using GIMP 2.6.  t8r.tif (rgb) has color
value <9d c1 a4> and t8c.tif (cmyk) has color value <62 3e 5b 00>.  Where
9d+62=ff, c1+3e=ff, a4+5b=ff.  I don't think this is any problem of
ghostscript, but an user error introduced by modern image viewing software's
fancy color conversion.
Comment 12 Michael Vrhel 2010-02-03 09:08:34 UTC
Verified by customer that problem was solved.
Comment 13 Marcos H. Woehrmann 2011-09-18 21:47:12 UTC
Changing customer bugs that have been resolved more than a year ago to closed.