I'm trying to do it using Ghostscript:
gs -sOutputFile=gray.pdf \
-sDEVICE=pdfwrite \
-sColorConversionStrategy=Gray \
-dProcessColorModel=/DeviceGray \
-dNOPAUSE -dBATCH \
-dAutoRotatePages=/None \
color.pdf
But this doesn't result in using only black ink:
gs -q -o - -sDEVICE=inkcov gray.pdf
0.15365 0.15365 0.15365 0.09419 CMYK OK
I can make the conversion successfully using Adobe products but I'd like to be able to do this in a more automatable fashion.
This is (mostly) due to the way that inkcov works.
Your PDF file contains a transparency group with a DeviceRGB blending space. Note that this does not actually create any RGB output, it merely means that any objects which are blended must be done in RGB space. So anything not in DeviceRGB (eg all the objects in Gray) must first be converted to RGB, then blended, then converted to device space for rendering.
Because inkcov is a CMYK device, this means that the blended RGB objects must then be converted to CMYK. This results in less than perfect black. The PDF file does not in fact contain anything except gray colour specifications except for specifying the blending space of the transparency as RGB.
Looking at what Acrobat appears to do, it seems the simple solution is the one to go for, change the transparency blending space into DeviceGray as well. We know from previous experience that blending in different spaces does result in differences in rendering. On the other hand, so does changing the colour space of all the colour specifications......
Given time to do some more investigation I'll probably go down ths road in the next release.
Related
I print qr.bmp into qr.pdf with 'microsoft print to pdf'.
Original qr.bmp is pure black (RGB 0,0,0), and perfect clear.
But qr.pdf is vague, not clear.
how to get clear image from pdf (or microsoft print to pdf)?
qr.bmp
zoomed qr.pdf
//////////////////////////////////////////////////////////////
I have tried to get pdf from printing job with ghoststcript, and also unclear pdf qr image, but improved pdf.
With -dGraphicsAlphaBits=1, I got more clear image, but not clear.
Can I get clear image from ghostscript?
gswin32c.exe -q -dBATCH -dNOPAUSE -dGraphicsAlphaBits=1 -sDEVICE=pdfwrite -sOutputFile=qr.pdf -
It is not always obvious if a source QRcode is good for primary use here are two good ones they can be reduced small without problems, scan to see at what distance they work.
Your camera autofocus should jump to the upper pair equally but struggle with focusing on the worst lower left one.
these two suffer some damage during reduction it may not be instantly obvious and they should still function, but perhaps at closer range.
What makes a good QRcode source ? is a good generator and here 4 different online FREE generators produce very different results and qualities when re scaling.
It is important you test the generator output by reducing the number of pixels in monochrome GIF or TIF or PNG formats as Black and white (should not be grey, except for rotation) nor castellated as seen in the lower left image. Also every black or white block should be truly square and equal the lower right is not even.
Your first image already shows that problem as the blocks are not even (you have 5s and 4s) and as soon as they are rescaled they will start causing issues in quality reading.
When you inject 1:1 or 2:1 (preferred) or print as PDF (not auto unless tested for scales), it is important that scaling is calculated to preserve monochrome squares, without degrading. Jpeg format or colour is NOT suitable for QRcodes (especially bulk processes) , unless quality assurance inspected for tolerance problems.
Your question says can GhostScript out put a crisp image and the answer is yes if the input is good and crisp as it cant correct for bad sources so here squares of one single pixel are output 100 times larger without any aberrations whatsoever
Source Probably too small to be detected until enlarged.
enlarged in PDF note the pixels are single pixels (no noise or chatter)
gswin32c -dGraphicsAlphaBits=1 -sDEVICE=pdfwrite -o qr.pdf -f in.pdf
Output (qr.pdf) copy and pasted in paint for checking. Quality in Quality out = 100% fidelity each block is exactly 100 x 100 pixels e.g. 10,000 times better! No sign of a failure.
I am trying to convert a LaTeX-generated PDF file to a PNG file with anti-aliasing and a transparent background (white text on a black background). After having read the answer to this post and one of the comments to the answer, I compared the convert function of ImageMagick against pdftoppm. So far, the highest quality anti-aliased images that I can generate are using pdftoppm (for a given DPI resolution). I use the following command:
pdftoppm -png -r 2000 text.pdf > text.png
The equivalent command (or so I think) using ImageMagick was:
convert +antialias -interpolate Nearest -density 2000 text.pdf -quality 90 -colorspace RGB text.png
However, I did not get as good-quality anti-aliasing using ImageMagick as I did with pdftoppm. In fact there hardly seems to be any anti-aliasing in the ImageMagick-generated image. See the close-ups below:
pdftoppm image:
ImageMagick image:
So where this leaves me is that I am satisfied with the anti-aliasing that pdftoppm provides. However, ImageMagick seems to have more functionality in now converting the anti-aliased image such that the black background is transparent. I have applied the approaches detailed in this post using ImageMagick, but they compromise the quality of the anti-aliasing that was previously satisfactory.
Can anyone advise me on how to solve the issue of obtaining a transparent background (which will always be black in color) while not affecting the anti-aliasing quality? Additionally, if the ImageMagick command that I used above was sub-optimal for generating a high-quality anti-aliased image, is there a way that I can achieve both anti-aliasing as well as background transparency by using ImageMagick alone? Any form of advice/tips would be much appreciated!
P.s. Since this question is partially LaTeX-related (I use LuaLaTeX to compile the PDF), I have posted a related question here regarding whether there is a much more straightforward way of directly generating the PDF file with a transparent background.
EDIT:
I've managed to fix the issue of transparency based on some comments on the question I posted on the TeX stack exchange. Now it's just about how I can improve the quality of anti-aliasing. Is there a way that I can achieve the same quality anti-aliasing that I get from pdftoppm?
The pdf file that I am converting can be found on this Dropbox link. Note that the font colour is white, and the background shows as white too (in my pdf viewer anyway), but is transparent. This is the converted PNG file.
You should use -density to increase the anti-aliasing of your PDF to PNG conversion. I note that your image is opaque white and the text is simply in the alpha channel.
convert -density 600 text.pdf -alpha extract x.png
If on Imagemagick 7, change convert to magick.
If you want to keep the transparency and keep your text white, then
convert -density 600 text.pdf y.png
The image is above, but will look completely white and blend with the white background. So you will need to download it.
If you want black text on transparency, then
convert -density 600 text.pdf -alpha extract -alpha copy -channel rgb -negate +channel z.png
I want to generate thumbnails of PDFs at a fixed width (548px wide, with the height determined by the PDF page aspect ratio). With ImageMagick, I can do this with the command:
$ convert -density 300 -resize 548x input.pdf thumbnail.png
This works for arbitrary sized PDFs, however, the larger the PDF the longer it takes. From the documentation I understand that this is because ImageMagick first has to read in the PDF and rasterize it (at 300 DPI), before scaling it down. This obviously takes longer and more memory the larger the PDF is.
My question is: Can we tell ImageMagick to rasterize the PDF to a set resolution when reading it in (something like 2 or 3 times larger than the thumbnail needs to be) before scaling it down and outputting the PDF? This should allow our conversion to run in roughly the same amount of time regardless of the PDF size.
We can do this ourselves manually by reading the PDF resolution first and then calculating the appropriate DPI to generate a rasterized PDF of the right size, but this seems like a bit of a hack and I would expect something like this built into ImageMagick.
This is not possible with the current version of ImageMagick (6.8.8-7). We found your post here and added the following feature that will be available in ImageMagick (6.8.8-8):
You can scale a PDF to a width of 548 pixels with the following command:
$ convert -define psd:fit-page=548x input.pdf thumbnail.png
If you create an image with another DPI than the default (72 DPI) you will have to resize it afterwards:
$ convert -density 300 -define psd:fit-page=548x input.pdf -resize 548x thumbnail.png
gs -o res.pdf -sDEVICE=pdfwrite -c "/osetcolor {/setcolor} bind def /setcolor {pop [0 0 0] osetcolor} def" -f input.pdf
this only changes the tables that have white borders, (which is a step in the right direction) I'd like to turn the white font to black.
These are big PDFs so pdfedit is a no. As I said, the above is a partial solution.
The font is already white, the background is white, but the default colours (it's a black colour scheme) on the machine it was made on meant that this wasn't known to the author. So a swap wont work.
I converted the document to post-script and used a function (not sure what they are called) to turn everything black, it worked, I wrote about it in an answer to a different question of mine with a similar title.
convert input.png -extent 100x100 -gravity center -background white output.png
If the input is 50x50 the surrounding background is white. Can I somehow set this to transparent without declaring any color within input as transparent?
Use this instead:
convert \
input.png \
-background none \
-gravity center \
-extent 100x100 \
output.png
Note well: The order of the parameters is significant! (To convince yourself, just put -background none at the end of the parameters instead of the start...)
Updated: Thanks to #jesmith who noticed that the commandline I originally provided does no longer work as intended. More recent versions of convert additionally require that the -gravity center is called before -extent 100x100. (This was one of the changes introduced to one ImageMagick's most recent versions [at the time of originally writing this answer]).
Kurt's note is ironically spot on, order matters greatly. Kurt's command results in gravity not being applied to the extent, so the transparent 'border' will all be to the bottom and/or right of the image.
Moving gravity before extent will correctly create equal transparent 'borders' on all applicable sides.
convert input.jpg -background none -gravity Center -extent 100x50
output.png