I'm trying to convert an EPS file with an embedded TIFF that has a transparent background to a PNG using GhostScript. The problem that I am having is that the background of the TIFF image becomes white in the PNG. It looks like the following:
IncorrectPNG
When I export from Adobe Illustrator, it comes out correct:
CorrectPNG
I was reading that there is not transparency in EPS, only marked and unmarked areas. I was wondering if there was a call that I was missing that would create the PNG through Ghostscript similar to that of Illustrator? Or if there is any other alternative that doesn't just replace white with transparency through ImageMagick?
I am using Windows and have Ghostscript 9.25 installed. Here is the command (one of many) that I've tried:
-q -dQUIET -dSAFER -dBATCH -dNOPAUSE -dNOPROMPT -sDEVICE=pngalpha -r300 -dEPSCrop NamePlatePNG.png NamePlate.eps
I can get the EPS file to you if needed. Any help would be appreciated, thanks!
UPDATE:
Here is the EPS file (Hopefully this link works):
https://drive.google.com/open?id=1m4HHGLoPe0jdWkx1Oghe7ttiXPldZnJs
Also, I should have mentioned that the images I uploaded were just screenshots of the PNGs open in an image editor. The checkered portion is indeed fully transparent alpha channel. I was trying to easily accentuate the difference.
Your file doesn't look like its transparent, it looks like its masked, possibly with a stencil mask, possibly chroma-keyed. Without seeing the file I can't tell for sure.
You are correct that PostScript (and hence EPS) doesn't support transparency, but it does support several features which have somewhat similar effects.
The color space is irrelevant, and in fact the only kind of 'transparency' supported in PostScript works when the color space is CMYK, but not when its RGB (and certainly not sRGB, which isn't even a PostScript color space, you have to manufacture it from CIEBasedABC)
As far as I can see the command line you are using is correct, but as I say I can't tell much without seeing the actual EPS program.
[EDIT]
So the Ghostscript rendering is correct, that's what is in your EPS file, there is no transparency of any kind there. So how is Illustrator able to make a transparent PNG ? Well the answer is that Illustrator isn't using the PostScript part of the EPS file.
About 1/3 of the way through the EPS file you'll see a line which reads:
%AI9_PrivateDataBegin
What follows that is an Adobe Illustrator file format. When AI reads the file it finds that line, throws away the PostScript portion of the file, and reads the AI representation of the content from the portion of the file beginning with that comment.
Now stored somewhere in there will be the information that portions of the content are transparent. Although PostScript can't represent that, Illustrator's internal format can. So when you write a PNG file from Illustrator it knows that portion is transparent and writes it as such.
Ghostscript, however, is constrained by the PostScript portion of the file, it can't read the Illustrator native format, and so renders the image with a white background.
It 'might' be possible to save a different kind of EPS from Illustrator (level 3 instead of level 2 possibly, I notice this is a language level 2 EPS file) which duplicate the effect, but from what you have here, there isn't anything a standard PostScript interpreter can do which will give you the result you want.
Related
I am using ghostscript 9.25 windows.
I am trying to convert RGB pdf to CMYK preserve pdf using following command:
gswin32c.exe
-dSAFER -dBATCH -dNOPAUSE -dNOCACHE -sDEVICE=pdfwrite -sColorConversionStrategy=CMYK -dProcessColorModel=/DeviceCMYK -dAutoFilterColorImages=false -dAutoFilterGrayImages=false -sOutputFile=out.pdf input.pdf
input.pdf file here
https://www.dropbox.com/s/8jfnov526nhb9m9/blank.pdf?dl=0
output.pdf file here
https://www.dropbox.com/s/ftrmm32mmixaxqh/out.pdf?dl=0
but my output becomes light compared adobe output, expected result is it should be dark when i do in adobe CMYK preserve option, i am getting little dark compared to ghostscript output. Am I doing anything wrong?
Should I use any icc profile?
Thanks
You say you are using ImageMagick, yet you give a Ghostscript command line....
I presume that when you say CMYL you mean CMYK.
There is nothing immediately obviously wrong with your command line, but you have given no example file, nor any reason why you expect the result to be 'dark'.
If you want to control the conversion then you will need to supply at least one and possibly up to 4 ICC profiles. You will certainly need a CIE->CMYK Output profile, and you might like to supply ICC profiles for Gray->CIE, RGB->CIE and CMYK->CIE as well, in order to override the default ones Ghostscript is using.
[EDIT]
The problem is nothing to do with colour conversion. Your original file contains nothing except a very large image, which is compressed with the Flate filter (lossless). It looks like this:
You've turned off auto filtering, but you haven't told Ghostscript which compression filter to use for images, so it sticks with the default, which is JPEG (DCT). The image now looks like this:
For the nature of your original image, JPEG (lossy) compression is an outstandingly bad choice. The output image compresses less well, and it loses fidelity. You should change to using Flate compression instead of JPEG for images of this kind.
By the way, the image in your original PDF file was defined in CMYK space already.
I use gostscript to convert text to outlines with the following code :gswin32c.exe -sDEVICE=pdfwrite -sOutputFile=output.pdf -dQUIET -dNOPAUSE -dBATCH -dNoOutputFonts -f test_new.pdf,it works.But i got a very small output file from 2.5M to 70kb.Then i find the picture became blurred in pdf.
Add -dPDFSETTINGS=/default,This will have the same result.
I's better to use -dPDFSETTINGS=/printer or -dPDFSETTINGS=/prepress,but 300dpi is not enough for me(or for my boss).
Is there any way to keep the original resolution of the picture.
Or how to set a higher dpi for images in output pdf.
The test file is here.
Thanks in advance.
The answer to your question is 'yes' (but see later). Don't use PDFSETTINGS, that sets lots of things all in one go. If you want control then you need to specify each setting individually.
Rather than use this shotgun approach you need to read the documentation, decide which controls affect areas you want to change, and alter those controls only.
However, image downsampling is not your problem. If you don't use -dPDFSETTINGS then PDF file written by Ghostscript contains an image at exactly the same resolution as the image in the original file.
Your problem is that the image is being written with JPEG compression, and JPEG is a lossy compression, so you are losing fidelity. Note that in the original file the image is written uncompressed, which is why its so large.
It looks like the original image was a JPEG, and the free PDF editor you are using has realised that so it saved the image uncompressed (I may be giving it too much credit here, it may save all images uncompressed). Applying JPEG to an image which has already been quantised simply amplifies the artefacts.
Instead you need to specify that you want images compressed with Flate, which is a lossless compression. The documentation for the pdfwrite controls can be found here, you need to change AutoFilterColorImages and ColorImageFilter.
Note that by not applying JPEG quantisation (a second time) and DCT encoding, the compression is less than your first experience. For me the output file comes in at just over 600Kb (leaving the font in place, and the text as text, would be a couple of Kb smaller). However the image is identical, as expected.
Since you are clearly using Ghostscript in a commercial environment, can I just point you at the licence and ask you to check that your usage is compatible with the AGPL, bearing in mind that this covers software as a service usage as well.
I have to convert pdf files (created with jasperreports) to postscript.
I'm using ghostscript (Version 9.19) to make the conversion.
The commmand i'm using is:
gswin64c -dNOPAUSE -dBATCH -sDEVICE=ps2write -sOutputFile=file.ps file.pdf
The conversion is done without problem, but when i open the postscript file generated (using GSview 5.0), the top margin is crop by 2-3 cm, and some information to print is lost.
I have changed the device from ps2write to eps2write, used the property -g<width>x<height> with the page size in pixels, but the problem persist.
The file is to be printed in a preformated paper, so i can not use the postscript generated to print.
Can someone help?
Thanks
Its not possible to say with great certainty, but it sounds like the PDF mediaBox is larger than the media you have specified to GSView.
You can try using the -dDEVICEWIDTHPOINTS and -dDEVICEHEIGHTPOINTS along with -dFIXEDMEDIA and -dPDFFitPage, that should allow you to set up a specific media size, override the size in the PDF file and scale the result to fit the specified size.
Perhaps you could post an example PDF file, without that its very hard to comment sensibly.
I use Abbyy FineReader for ScanSnap to OCR a couple of scanned PDF files. The software claims it retains the original PDF images. The PDF file sizes pre-OCR and post-OCR are almost identical, which is good.
After the software is done, all PDF images appear anti-aliased in Acrobat X. Page navigation is much slower than before, and when I zoom in/out, the images first go to what looks like the pre-anti-aliasing version before quickly changing to anti-aliased images.
Left: Scanned PDF / Right: after OCR with Abbyy
I would like to get the original images without anti-aliasing back. Interestingly, when I open a single page from the anti-aliased PDF in Photoshop, there is no anti-aliasing and the image looks like the left one.
My limited PDF programming experience leads me to believe that Abbyy likely sets some kind of anti-alias flag for each image during OCR processing. How do I un-set this flag?
Any pointers to useful ideas would be much appreciated.
After the software is done, all PDF images appear anti-aliased in Acrobat X. Page navigation is much slower than before, and when I zoom in/out, the images first go to what looks like the pre-anti-aliasing version before quickly changing to anti-aliased images.
Actually in the original file 2013_11_15_22_51_31.pdf contains a JPEG image while the OCR'ed file 2013_11_15_22_51_31_OCR.pdf contains a JPEG2000 image.
Comparing them in third party viewers, it becomes clear that the image in the OCR'ed file is not inherently anti-alias'ed. Furthermore there is no evident flag in the PDF instructing PDF viewers to apply anti-aliasing to the JPEG2000 image. Thus, Adobe Reader seems to automatically render JPEG and JPEG2000 images differently, applying anti-aliasing to the latter but not to the former.
Comparing both images in detail, though, it becomes clear that these images are not identical but instead the image in the OCR'ed PDF is slightly rotated.
I assume Abbyy FineReader recognized that the original scanned image is not correctly oriented. Thus, it rotated it slightly to correct this orientation.
Thus, replacing the image in the OCR'ed version with the one from the original one is no option: Due to the rotation the OCR information would partially be somewhat off.
What you might want to try is to recode the JPEG2000 image to JPEG and replace the image in the OCR'ed version with this recoded one. This will mean some loss of quality but most likely you can get rid of the anti-aliasing this way.
Be aware, though, that the JPEG2000 image is slightly larger than the JPEG image to accomodate for the rotation.
PS: As #VadimR pointed out, there is indeed an /Interpolate true entry in the image dictionary of the OCR-ed version I missed when looking at the file. This does not seem to be the major issue slowing down the rendering.
There is /Interpolate true entry in image dictionary of OCR-ed version, and that's what causes 'anti-aliasing'. Whether that (and not JPEG2000 instead of JPEG compression) is a cause of slow-down, you check on large enough files.
To un-set this key, the best would be to turn it off while creating a file, and if that's not possible, to write and run a small program in suitable language.
But, since your file doesn't sport 'compressed objects' and offending key is in plain view inside a file, in the spirit of 'job done quickly' you can simply process your file e.g. like this:
perl -M-encoding -0777pe "s!/Interpolate true!' 'x17!ge" <in.pdf >out.pdf
Is it possible to check if a PDF is CMYK or RGB using GhostScript?
I am aware of the inkcov feature, but this just returns values in terms of CMYK (with silent conversion)?
Is the real check, a check for RGB colours or RGB images within the PDF? not sure if both RGB and CMYK images can exist in the same PDF?
Images aren't the only thing that can be in a PDF file, you can also have text, linework and shadings. Also transparency blending can be specified in specific colour spaces. Colour spaces are not limited to RGB or CMYK but can also include Gray and spot (Separation) colours, as well as ICCBased colour spaces and certain specific CIE colour spaces such as Lab.
All of these colour spaces can potentially be present in a PDF file simultaneously.
Ghostscript doesn't contain any tools currently to tell you what colour spaces are used in a PDF file, though the pdf_info.ps script could be modified to do so for unusual (not grey/RGB/CMYK) spaces. You could also write a small piece of PostScript which could tell you when a colour space was used, and what kind of colour it is.
The inkcov device is a CMYK device, so all colours specified in the PDF are converted to CMYK before being 'printed' to the inkcov device which counts up the coverage. It doesn't tell you anything about the original PDF file.
My understanding is that a PDF can contain both RGB and CMYK images, so you'd need to have a tool that can review all images and report on their mode.
If GhostScript doesn't include options to do so, you may have to write a script to use a PDF library for parsing the image and reporting details on the elements it contains.
For example, this Cam::PDF module in Perl says it can parse any PDF v1.5 formatted file.