Color shift processing an eps file

Questions and postings pertaining to the development of ImageMagick, feature enhancements, and ImageMagick internals. ImageMagick source code and algorithms are discussed here. Usage questions which are too arcane for the normal user list should also be posted here.
Post Reply
graemeNPS
Posts: 64
Joined: 2009-01-12T14:25:55-07:00

Color shift processing an eps file

Post by graemeNPS »

We use IM to process a wide variety of input formats to get preview and thumbnails for our DAM product.
A customer complains that the conversion of the file MoreLikeHer_EB.EPS alter color and loses contrast.
We are currently using ImageMagick-6.9.0-7-Q16-x86-dll.exe and ghostscript 9.15.

this snippet of the log shows our command line to IM:

03/10/2015 11:52:51 5392:5432 [DEBUG] ImageMagick IPiece:CImageMagickPieceImpl::IPAcquireFile(): Temp file is [c:\Telescope\gb_temp\NPS_IPIM_5392viewx.jpg]
03/10/2015 11:52:51 5392:5432 [DEBUG] ImageMagickAPIWrapper::AcquireFile(): Converting file [C:\Archive\admin\1425830823\03102015115217572\MoreLikeHer_EB c.eps] to [c:\Telescope\gb_temp\NPS_IPIM_5392viewx.jpg]
03/10/2015 11:52:51 5392:5432 [DEBUG] ImageMagickAPIWrapper::AcquireFile(): The wszConvFilePath is c:\Telescope\gb_temp\NPS_IPIM_5392viewx.jpg
EX argv list [convert]
EX argv list [-auto-orient]
EX argv list [-size]
EX argv list [383x576]
EX argv list [C:\Archive\admin\1425830823\03102015115217572\MoreLikeHer_EB c.eps[0]]
EX argv list [-alpha]
EX argv list [Off]
EX argv list [-resize]
EX argv list [383x512]
EX argv list [-density]
EX argv list [72x72]
EX argv list [-quality]
EX argv list [90]
EX argv list [-profile]
EX argv list [c:\TELESC~1\IPieces\ImageMagick\CMYK.icc]
EX argv list [-profile]
EX argv list [c:\TELESC~1\IPieces\ImageMagick\sRGB.icm]
EX argv list [+profile]
EX argv list ["*"]
EX argv list [c:\Telescope\gb_temp\NPS_IPIM_5392viewx.jpg]
03/10/2015 11:52:51 5392:5432 [DEBUG] ImageMagickAPIWrapper::AcquireFile(): About to generate Extended view.
03/10/2015 11:52:58 5392:5432 [DEBUG] ImageMagickAPIWrapper::AcquireFile(): Extended view generation complete.
03/10/2015 11:52:58 5392:5432 [DEBUG] ImageMagickAPIWrapper::AcquireFile(): Got file size [67441]
03/10/2015 11:52:58 5392:5432 [DEBUG] ImageMagickAPIWrapper::AcquireFile(): Successfully converted file [C:\Archive\admin\1425830823\03102015115217572\MoreLikeHer_EB c.eps] to [c:\Telescope\gb_temp\NPS_IPIM_5392viewx.jpg]

end snippet:

Any thoughts or tips on how we can get a better rendering of this image would be appreciated.

Our customer has agreed to share the file with ImageMagick for analysis.
Image is at our ftp site:
ftp.northplains.com
user:publicforum
pass:543publicforum123
dir: /imagemagick/ts-9819/
file:MoreLikeHer_EB c.eps

Thanks,
Graeme
User avatar
dlemstra
Posts: 1570
Joined: 2013-05-04T15:28:54-07:00
Authentication code: 6789
Contact:

Re: Color shift processing an eps file

Post by dlemstra »

Can you also share your CMYK.icc file?
.NET + ImageMagick = Magick.NET https://github.com/dlemstra/Magick.NET, @MagickNET, Donate
snibgo
Posts: 12159
Joined: 2010-01-23T23:01:33-07:00
Authentication code: 1151
Location: England, UK

Re: Color shift processing an eps file

Post by snibgo »

Do you have an "ideal" version, in sRGB space of what it should look like?

The eps file contains a profile, so your first "-profile" isn't needed (it converts from one CMYK space to another). Your second "-profile" converts to an sRGB colorspace. Sadly, there are a number of different sRGB profiles. When you strip the profile (with "+profile"), this loses the information about which profile was used, so display software can't use that information.

I suggest that you don't "+profile".

The other issue is about intent. When converting between profiles, you can declare one of four intents. According to the ICC profile inspector, the embedded profile is for "relative calorimetric" only. Thus, any other intent will give a result that is technically wrong, although it may be aesthetically acceptable.

So, I think the technically correct process puts "-intent Relative" before the one and only "-profile".

I say "I think" because it is possible that a different intent was intended by the author. You might create versions using all four intents, and see which one is preferred.

(In my experiments with this image, intents Saturation and Perceptual give the same result. Saturation, Relative, Absolute, or omitting intent entirely, yield four different results.)
snibgo's IM pages: im.snibgo.com
graemeNPS
Posts: 64
Joined: 2009-01-12T14:25:55-07:00

Re: Color shift processing an eps file

Post by graemeNPS »

I have added MoreLikeHer_EB+c.JPG (the converted file) and ts9819Capture.PNG, a screen capture of the original eps and the converted jpg (on right) as opened in Photoshop cs5.1. I see the eps as being glossy or snappier. The jpg looks muddy in comparison.

I hope this helps.

Thanks for the feedback. I really appreciate it.

We use the conversion string I showed earlier as a standard conversion. If you can think of anything we can read from the eps as a Magick::Image *pImage to help us modify the conversion with more or fewer parameters, that would be great.

I am assuming the version of Ghostscript has nothing to do with this. I have used gs 9.06 and 9.15 (the current one).

Thanks again,
graeme
snibgo
Posts: 12159
Joined: 2010-01-23T23:01:33-07:00
Authentication code: 1151
Location: England, UK

Re: Color shift processing an eps file

Post by snibgo »

Sorry, I don't have time to look right now, but a quick couple of points.

1. In PS, do you use dot-gain? This simulates (I think) the way that printers spread the size of ink dots. IM has no equivalent.

2. Screenshots of two images is okay for visual comparison, but screen software should apply a profile for that screen, so the captured pixel values will be different to those in the file. If you can, tell PS to save this as an sRGB PNG.

3. Remember that PS is simulating on the screen what the print will look like. It is only a simulation; printer gamuts are different to screens. PS may be applying extra tweaks, eg if it "knows" that glossy paper will be used. In theory, this is handled by the profile but in practise PS may do something more.
snibgo's IM pages: im.snibgo.com
snibgo
Posts: 12159
Joined: 2010-01-23T23:01:33-07:00
Authentication code: 1151
Location: England, UK

Re: Color shift processing an eps file

Post by snibgo »

Looking at the screenshot of the PS sRGB proof of CMYK, and the IM conversion:

1. They are different sizes. Why? This make comparisons more difficult.

2. The light tones (eg the dress) are very similar.

3. The dark tones are substantially darker in the PS version. Eg between the legs, PS has RGB values about 4% where IM has 18%. So the PS version has higher contrast.

4. The PS version has slightly higher saturation. If we increase contrast in RGB space this will automatically increase saturation.

5. The hues are pretty much the same.

"identify -verbose" shows that "MoreLikeHer_EB c.eps" has maximum K of 66%. An IM conversion has minumum RGB calues of 18%. So neither image has solid blacks. But the PS proof has created RGB values about 4%. Why? Perhaps this is dot gain. What dot gain setting have you used in PS?

In IM, we can "-auto-level". This increases contrast and saturation. In fact, the result is more contrasty and more saturated than the PS version. We can blend an auto-levelled version with non-auto-levelled.

Code: Select all

%IM%convert ^
  "MoreLikeHer_EB c.eps" ^
  -profile sRGB.icc ^
  ( +clone ^
    -auto-level ) ^
  -compose blend -define compose:args=50 -composite ^
  xb.png
This is close, visually and numerically, to the PS proof. However, the PS proof has darker shadows. If we adjust the compose:args= to match the shadows, the rest of the image is darkened too much. Hence the PS proof seems to have a non-linear darkening. More work might find an equivalent in IM.

If you want results to match what PS makes, the obvious solution is to use PS.
snibgo's IM pages: im.snibgo.com
Post Reply