The ImageMagick (IM) result of this command
convert myRGB.png -colorspace cmyk cmyk.pdf <br>
is not as bright or as close to the screen colors as a Photoshop produced CMYK PDF. myRGB.png is a PNG file produced using GIMP.
I don't own Photoshop, and would like to stick with open source tools.
The current Ubuntu release of of IM is 6.7.7. That IM version produces very dark, totally unusable, CMYK PDF.
I built 7.0.2-6 Q16 from source on Ubuntu 14.0.4, after also building LCMS package from source, and the above command works better, but the CMYK PDF as stated above is less bright and less close to the screen colors than the similar Photoshop output. E.g. blacks are not totally black; the sky color is dull blue instead of bright blue/cyan.
I've tried using ICC files downloaded from Adobe as in the following
convert myRGB.png -colorspace cmyk -profile WebCoatedSWOP2006Grade5.icc cmyk.pdf
I've tried this command with all 14 Adobe ICC files and there is no difference in any of them. Although, I admit I do not understand under what circumstances the ICC comes into play or if it is appropriate to this problem at all.
The simple question is why does IM convert tool not match the Photoshop results for CMYK?
The second question is, if IM can't be made to do it: is there any open source tool or tools that can match the Photoshop results for producing a CMYK PDF from and RGB PNG?
There are two applications involved, as you presumably know since you tagged this with Ghostscript. You haven't said which version of Ghostscript you have installed but the first thing I would do is remove ImageMagick from the equation.
Find out whether IM is having Ghostscript produce RGB or CMYK output, my bet is that it is getting RGB from GS. You'll need to find out what Ghostscript command line IM is using and I can't tell you how to do that. Assuming that the Ghostscript output is RGB then this would explain why altering the IM settings makes no difference.
Proceeding on the assumption that the above is correct, use the png16m device in Ghostscript to produce RGB PNG files directly, this reduces the scope of the problem:
gs -sDEVICE=png16m -o out.png input.pdf
Now, you don't say what version of Ghostscript you have installed, but assuming its relatively recent you can look in the /ghostpdl/doc directory and find considerable information on using colour management in Ghostscript, the document GS9_Color_Management.pdf may be helpful. It will certainly give you a myriad of opportunities to alter the output.
Related
I'm using ImageMagick to convert the following PDF to an PNG file.
Click here to download the PDF from IMSLP (Permalink if the direct download is broken)
In a PDF viewer it looks nice:
but when converting with convert -density 300 -background white -alpha off -alpha remove file.pdf /tmp/file.png
the image gets a large white margin:
I do not want to trim the image afterwards, I just want ImageMagick to somehow respect the view-port or however that viewing information is being encoded in the PDF. Does anyone know which command-line parameter might enable this behavior?
Edit 10.03.2022: I'm using ImageMagick 7.1.0.16 with Ghostscript 9.55.0 inside an Alpine Linux docker image.
I do not get your extra margin in ImageMagick 6.9.12-42 using Ghostscript 9.54. But changing the density does not seem to have any effect.
convert -density 300 -background white file.pdf[1] x2.png
The issues may be a malformed PDF. How was it created? Also what version of Ghostscript are you using? It could be a GS version issue.
If this was a scanned PDF that is a raster image in a vector PDF shell, then you could just use pdfimages to extract the raster files. See https://manpages.debian.org/testing/poppler-utils/pdfimages.1.en.html
The hint from KenS was exactly what I was looking for - the PDF defines a CropBox that ImageMagick 7.1.0 was not using by default. The solution therefore is to modify the command to include the following -define information:
convert -define pdf:use-cropbox=true file.pdf /tmp/file.png
Thank you all for your help!
I'm using Ghostcript to convert some PDF files to JPG. All is working when converting the program consider the resolution of 600dpi when converting and output jpeg quality is good.
Here is my code :
gs -sDEVICE=jpegcmyk -dTextAlphaBits=4 -r600 -dSAFER -dBATCH -dNOPAUSE -o my_output_file.jpg my_input_file.pdf
But when I open the file in Photoshop, the properties contains 72dpi instead of 600dpi I expected :
When I try with RGB profile for output, it is ok, I have got 600dpi.
So what I want is CMYK + 600dpi in image properties.
As can be seen from your screenshots, both images are of the same dimensions, 6803 by 709 pixels.
And that is all that matters.
Also, the size of the CMYK version is bigger by about 33% compared to the RGB version -- as is to be expected for an image with 4 color channels instead of 3.
Ghostscript used the -r600 CLI parameter to correctly expand the number of pixels when converting the PDF file.
Ghostscript does not add any EXIF metadata to its output when converting a PDF to raster.
The DPI or PPI information would be an internal metadata hint to tell any compliant viewers how big to render the image on screen. It would not change anything substantial in the image information itself.
Why Photoshop does think it should use 72 dpi for one, but 600 dpi for the other, you may ask Adobe about.
I bet Photoshop also renders the 72dpi file about 7 times larger on screen than the other. Is that the case?
P.S.: See also "What DPI do web images need to be?"
i am trying to us Ghostpcl to convert pcl files to pdf on linux. In the main, this is working well and the majority of documents are converting well. However, some documents have boxes and shading and these are not rendering well at all. The resolution is very poor and as a result any text on top of the shading is almost unreadable. Additionally some alignment is slightly out down the right hand margin.
i have also used visual software pcl2pdf which does a good job on the shading but unfortunately does not substitute all of the fonts correctly.
the pcl file can be found here
https://dl.dropboxusercontent.com/u/86110783/20170215102450_65702421.pcl
the ghostpcl converted pdf
https://dl.dropboxusercontent.com/u/86110783/ghostpcl20170215102450_65702421.pdf
the pcl2pdf pdf
The command i am using for converting the pcl to pdf is
/opt/ghostpcl/gs -sDEVICE=pdfwrite -sFONTPATH=/opt/fonts -dBATCH -dNOPAG
EPROMPT -dNOPAUSE -dQUIET -sOutputFile=$1.pdf $1.pcl
i have tried various different switches to no avail.
Any ideas would be greatly appreciated
If the pdfwrite device can't handle a graphic primitive 'as is' it will render it to an image. The default resolution is 720 dpi which is ordinarily good for most purposes, but you can alter it with the -r switch.
Note that for PCL its probably important to set the resolution to 300 or 600 dpi, as that is the only resolution PCL is defined for. The 'shading' you are talking about is, I think, a pattern, and that will only repeat properly at the precise resolution (or integer multiples thereof) for which its intended.
Even if you run at 600 dpi its probably going to look odd as you zoom in and out of the PDF file.
I'm not sure what exactly you are complaining about regarding alignment, do you mean the fact that the text doesn't fit in the box ? That will be because its using a substitute for the missing font, and the substitute has different metrics to the original.
I don't see a link to the pcl2pdf file.
I'm converting pdf (created with adobe illustrator) into transparent png file, with following command:
gs -q -sDEVICE=pngalpha -r300 -o target.png -f source.pdf
However, there's undesired white boxes in the resulting PNG, looks like it's auto generated by ghostscript, some bounding box. (see attached image)
Tryied both gs-9.05 and gs-9.10, same bad result.
I've tried to export to PNG file from Illustrator or Inkscape manually, the result is good.
What does Inkscape do to render it correct, and
How could I eliminate those white boxes using ghostscript?
Try mudraw of latest (1.3) muPDF, as far as I checked it creates nice PNGs from PDF files with 1.4 transparency:
mudraw -o out.png -c rgba in.pdf
"rgba" being, as you understand, RGB + alpha
In the general case, you can't. PDF does support transparency, but the underlying media is always assumed to be white and opaque. So anywhere that marks are made on the medium is no longer transparent, its white.
You don't say which version of Ghostscript you are using, but if its earlier than 9.10 you could try upgrading.
I have an RGB PDF which I've preflighted in Adobe Acrobat pro to a PDF x1a compliant PDF in US Web Coated SWOP v2.
The PDF now has 4 plates (C/M/Y/K)
C plate is empty
M plate has 100% of a red image
Y plate has 100% of the same red image
K plate has 100% of black text on page (text is not on any other plate)
I'm now trying to convert that PDF into a PS using ghostscript
I've tried:
gs -dNOPAUSE -dBATCH -sDEVICE=ps2write -sProcessColorModel=DeviceCMYK -sOutputFile=output.ps input.pdf
But then when I distill this PS back to a PDF the text is on all the plates and not just the K plate.
I've used this online tool:
http://pdf.my-addr.com/free-online-pdf-to-ps-convert.php
To also do the conversion and the distilled version of the PS generated by that preserves the plate breakdown. They are also using Ghostscript to create the PS.
So I'm assuming there is some setting I am missing.
Does anyone know?
Update 1
Trying in pdftops too and again it is taking my K plate and spreading it across all CMYK plates.
What secret magic are they doing on that web site to preserve plates?!
Update 2
Only main difference I can see is I'm using
%%Creator: GPL Ghostscript 905 (pswrite)
and that website is using
%%Creator: GPL Ghostscript 871 (pswrite)
Could it be a version thing, or are they doing something I'm not?
Ghostscript 9 and above use much better colour management than previous versions, but you have to get the ICC profiles correct. I'd guess you are using the default profiles and I think the first thing I'd suggest is that you use the current version of Ghostscript which is 9.07, I think there were a few changes made to the default profiles.
Its also possible that the PDF file now has an input RGB profile associated with it, which Ghostscript is now using whereas previously it didn't. I'd need to see the file to be able to tell better what is going on, but I have a sneaky suspicion that your 'pre-flight' conversion is causing the problem. What happens if you use the original PDF file ?
I very much doubt if the PDF file actually contains CMYK colour components, I would imagine all that has happened is that different profiles have been inserted into the file that control the conversion from RGB to CIE and from CIE to CMYK.
In passing, don't use pswrite. Its a terrible low-level output that converts much of the content into images. It produces large PostScript that processes very slowly and doesn't scale well (ie if the printer is a different resolution). Use the ps2write device instead.
By the way, since you've already used Acrobat, why don't you just use 'Save As' PostScript from there ?