I see extrem colour changes on tif files converted to jpg/png.
Try this:
http://files2.hanser.de/Files/Article/ARTK_CT1_9783446247246_0001.tif?scale=both&format=jpg&decoder=freeimage&quality=80&height=2000
for a the wrong Colour, it appears green while the tiff itself is tourquise.
You can download the original tif from the same address.
I tried with all kinds of Settings, ignoreicc, with and without freeimage Decoder, jpg vs. png, etc. - no Change of appearance.
What to do ?
Thanks.
I looked into your situation and found several CMYK related bugs in old patch notes for the freeimage decoder. The TIF you are providing has a CMYK color profile. They have since been fixed. Removing the freeimage decode tag produced the desired result. Is your imageresizer core and freeimage plugin up to date?
http://files2.hanser.de/Files/Article/ARTK_CT1_9783446247246_0001.tif?scale=both&format=jpg&quality=80&height=2000
Produces
A resulting JPG with the correct colors
You can reduce color shift when converting CMYK to RGB if your server's display profile is set to sRGB.
.NET's System.Drawing is designed exclusively for display purposes, and targets your server's current ICC profile, which is not always sRGB.
We hope (assuming sufficient funding), to eliminate both FreeImage and System.Drawing in a future version of ImageResizer, which will give us the control required to have perfectly accurate colorspace conversions.
https://github.com/imazen/imageflow
Related
I want to convert a CMYK-PDF into a rgb-PNG using ghostscript.
This is what I use so far:
gs -sDEVICE=pngalpha -dBATCH -dNOPAUSE -dCompatibilityLevel=1.4 -dColorConversionStrategy=/sRGB -dProcessColorModel=/DeviceRGB -dUseCIEColor=true -sOutputFile=out.png -r300 pdf/input.pdf
The issue is however that the color is not converted accurately. I'm using a Mac OS Catalina MacBook and when I look at the original PDF in the built in preview tool the color is not as saturated as the converted color.
So my question is what am I doing wrong with this? I'm not an expert with color management.
Thanks!
Well, clearly the colours cannot be the 'same' because one is expressed in a subtractive 4 colour model, and the other in an additive 3 colour model.
Firstly you are using three command line switches which are not going to have any effect at all:
-dCompatibilityLevel is only used for the pdfwrite device to set the maximum version of PDF support, it has no effect on any other device and certainly won't affect the PNG output devices.
-sColorConversionStrategy only works with the pdfwrite device, which is capable of handling nearly the full range of colour models. Most devices, such as PNG only support a single colour model, so you don't need to specify the colour conversion, it all has to be converted to that colour space.
You should never set -dProcessColorModel. That has to remain correct for the device; in the case of high level devices it is ignored, or set appropriately to the same as ColorConversionStrategy.
Finally and most importantly; you have set -dUseCIEColor. This is an ancient PostScript colour management control; it causes all colours to be converted into CIE spaces, either CIEBasedA, CIEBasedABC, CIEBasedDEF or CIEBasedDEFG. From there the colour is converted to the destination space. Using this will pretty much break the ICC profile colour management in Ghostscript.
So drop all four of those and try again. Note that when you compare the PNG result with the PDF you are comparing the colour conversion performed by Ghostscript with the colour conversion (CMYK->RGB) performed by the PDF consumer, presumably the built-in Mac Quartz code. I'd have to express some reservations about the quality of that conversion.
It is entirely possible for you to control the colour management performed by Ghostscript. There are default RGB and CMYK profiles which are used to convert the CMYK components into the CIE XYZ calibrated space, and then from there to RGB. Each of these uses on ICC profile. If you don't like the default ones you can substitute another one of your choosing for either or both. The ICC profiles can be found in the ghostpdl/iccprofiles directory, you can use -sDefaultCMYKProfile=<...path...> to specify a different profile to use to convert CMYK into CIE-XYZ and -sOutputICCProfile=<...path...> to specify a different ICC profile to use for the final space (RGB in your case).
For properly colour managed workflow you should know the characteristics of the specified input colour model (eg SWOP CMYK) and use the correct ICC profile to map from CMYK to CIE-XYZ and you should know the characteristics of the output colour model (eg Sony Trinitron, to use an old monitor example) to create the closest matching output colour.
You may have an ICC profile for your monitor, I doubt you know what the CMYK values in the original PDF file represent. To match whatever PDF consumer you are using you would need to know what CMYK and RGB output profiles it is using and use the same ones in the Ghostscript rendering process.
NB all the above assumes that the original PDF, which is not supplied, actually specifies the colours in CMYK, and not in an ICCBased colour space, or other similar device-independent colour space.
Edit
From the comment:
Following your argumentation it should be identical
No. In the case of the PDF consumer it is doing a CMYK->RGB conversion in order to display the content. When rendering to PNG Ghostscript is also doing a CMYK->RGB conversion. Actually because you are using -dUseCIEColor it's doing a CMYK->CIEBasedDEFG->RGB conversion, but lets assume you dropped that so it's just doing CMYK->RGB.
Now, if the two conversions are fully colour managed, lets assume for now ICC profiles as the colour management technique, and the two conversions are using the same ICC profiles, that is assuming the same characterised space, then yes the result will be identical.
Without seeing your PDF file I can't tell how the colours are actually specified within it. You say they are 'CMYK' but CMYK is not a characterised space. There are many different CMYK inks and they are printed to many different kinds of paper with different reflectivity and absorbency. So SWOP and Euroscale are both CMYK printing processes, but their characteristics are different.
So if we treat your CMYK values as SWOP and convert them to an RGB space we should expect different RGB values than when those same CMYK values as if they were Euroscale. That's because the same CMYK quad printed to a SWOP process would be different to the appearance on a Euroscale process.
Similarly when it comes to creating the RGB values. RGB is also not a characterised space, there are many different RGB output devices and they differ in how they display a given RGB triplet.
Now I don't know how your PDF consumer does the CMYK->RGB conversion. I'd like to think it uses ICC profiles to characterise the spaces but it might not. There's a long standing (quick and dirty) conversion method from the PostScript Language Reference which it might use instead.
However, a modern colour managed workflow would use ICC profiles.
When dealing with an uncharacterised space such as 'CMYK' or 'RGB' the only thing Ghostscript can do is use a generic profile. It uses a general purpose CMYK profile to convert the incoming CMYK into the CIE XYZ space (which is device-independent) and then a generic RGB profile to convert the CIE XYZ components into RGB. You can change the assumptions about the input and output colour spaces.
In effect you can say 'I happen to know that the CMYK values were intended for an HP Indigo, so use the HP Indigo ICC profile' and that will then map the CMYK into XYZ as the original creator intended. Similarly you can say 'I'm using a Sony wide gamut RGB monitor, so use that ICC profile' and that will give the best possible representation of the XYZ colours on that device.
But if tomorrow you viewed it on a low end Iiyama monitor you could tell it to use a different appropriate profile, and you would see (as far as possible) the same colours as on the expensive device.
So to try and summarise; the problem is that you are using uncharacterised spaces. The two consumers are not set up to use the same default colour management paths, so you can expect to see differences. To avoid this you need to use the same profiles on both PDF consumers (preview and Ghostscript).
I can't remember if PNG allows you to save an ICC profile in the file. If it does then you can carry the PNG to another computer with a different monitor and it will still look the same. If it doesn't (and I think it doesn't) then viewing the RGB output on different monitors will look different.
I have an image of a website which I'm trying to convert to PDF. I have the image in several formats: PSD, PNG, JPG, TIFF, all saved losslessly.
I'm using the following command to convert the image to PDF:
convert -density 93 foo.jpg bar.pdf
Here is part of the original image:
And here is the same part, after converting to PDF:
As you can see, the second one is ever so slightly hazy. What's causing this, and how can I eliminate it? I've seen PDFs with crisp graphics, so I know it's possible.
If you are seeing the same results with multiple input types. The fuzziness is likely being caused by the anti-aliasing feature of your PDF Viewer. If using Acrobat, you can turn off image anti-aliasing by doing the following:
Go to Edit-->Preferences-->Page Display
Untick the option "Smooth Images" and hit "OK".
The crisp graphics you are seeing on other PDFs are likely due to the fact that they are vectorized graphics. Imagemagick is creating a PDF and embedding your image inside of it which may be subject to compression.
Also:
When using jpeg as input, add the "-quality 100" to your Imagemagick call to retain the highest quality possible.
Use a higher value for the "-density" parameter (I would recommend at least 150) to generate a higher resolution PDF.
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 trying to convert PDFs to PCL (using ghostscript, but I'd love to hear alternative suggestions), and every driver (ghostscript device), including all of the built-ins and gutenprint generate PCL files many times larger than the input PDF. (This is the problem - I need my PCL to be about as small as the input).
Given that the text doesn't show up in the PCL file, I guess that Ghostscript is rasterizing the text. Is there a way to prevent GS generally, or just gutenprint, from doing that? I'd rather either have it embed the fonts, or not even embed the fonts (leave it to the printer to render the fonts)?
Unfortunately, there doesn't seem to be any documentation on this point.
There are 3 (I think) types of font in PCL. There are rendered bitmaps, TrueType fonts (in later versions) and the HPGL stick font.
PDF and PostScript Have type 1, 2 (CFF), 3 and 42 (TrueType, but not the same as PCL) and CIDFonts based on any of the preceding types.
The only font type the two have in common is TrueType, so in order to retain text, any font which was not TrueType would have top be converted into TrueType. This is not a simple task. So Ghostscript simply renders the text, which is guaranteed to work.
PDF is, in general, a much richer format than PCL< there are many PDF constructs (fonts, shading, stroke/fill in a single operation, transparency) which cannot be represented in PCL. So its entirely possible that the increase in size is nothing to do with text and fonts.
In fact, I believe that the PXL drivers in Ghostscript simply render the entire page to a bitmap at the required resolution, and then wrap that up with enough PCL to be successfully sent to a printer. (I could be mistaken on this point though)
Basically, you are not going to get PCL of a similar size to your PDF out of Ghostscript.
Here is a way to 'prevent Ghostscript from rasterizing text'. But its output will be PostScript. You may however succeed convert this PostScript to a PCL5e in an additional step.
The method will convert all glyphs into outline shapes for its PostScript output, and it does not work for its PDF or PCL output. The key here is the -dNOCACHE parameter:
gs -o somepdf.ps -dNOCACHE -sDEVICE=pswrite somepdf.pdf
Of course, converting font glyphs to outlines will take more space than keeping the original fonts embedded, because "fonts" are a space-optimized concept to store, retrieve and render glyph shapes.
Once you have this PostScript, you may be able to convert it to PCL5e with the help of either of the methods you tried before for PDF input (including {Apache?} FOP).
However, I have no idea if the output will be much smaller than versions with rasterized fonts (or even wholesome rasterized pages). But it may be worth a test.
Now vote down this answer too...
Update
Apparently, from version 9.15 (to be released during September/October 2014), Ghostscript will support a new command line parameter:
-dNoOutputFonts
which will cause the output devices pdfwrite, ps2write and eps2write to "to 'flatten' glyphs into 'basic' marking operations (rather than writing fonts to the output)".
That means that the above command should be replaced by this:
gs -o somepdf.ps -dNoOutputFonts -sDEVICE=ps2write somepdf.pdf
Caveats: I've tested this with a few input files using a self-compiled Ghostscript based on current Git sources. It worked flawlessly in each case.
I put images on our website that were very nice in Firefox and little red x's in IE. I understand that IE wants only RGB and I could convert my images. In fact I tried it out. The issue is that the images get dulled down, look dead in RGB. I'm hoping that there is some way to say, IE load these images in RGB, but Firefox load these other images in CMYK. Any ideas?
I do not believe you can get IE to render CMYK encoded images. To avoid manually changing them, you could put a filter on the site to automatically convert them but I would assume that the quality would suffer.
CMYK encoding is typcally used for print, which as quality requirements that are overkill for the web. With a decent quality photo editing tool, such as photoshop, you should be able to get decent, web quality, versions of these photos using RGB encidong.
As far as I have been able to find, it's not currently possible to get IE to use a CMYK format (perhaps with an add-on?).
Your conversion process may not be saving the most optimal color setting. Perhaps using a different conversion mechanism (i.e. a different tool) from CMYK to RGB would help.
Link: http://www.webmasterworld.com/html/3885754.htm