I have a jpeg image where the EXIF Orientation flag = 6, or "Rotate 90 CW". Here's the pertinent data from exiftool:
---- ExifTool ----
ExifTool Version Number : 12.44
---- File ----
File Name : orig.jpg
Image Width : 4032
Image Height : 3024
---- EXIF ----
Orientation : Rotate 90 CW
Exif Image Width : 4032
Exif Image Height : 3024
---- Composite ----
Image Size : 4032x3024
Here's how IrfanView presents the image, with auto-rotate turned off:
Using the plupload "Getting Started" script from here, with preserve_headers = false, I get an image without EXIF headers - as expected - but rotated 180 degrees, which is unexpected. Again, the view with IrfanView:
Here's the "resize" snippet from the code:
resize: {
width: 5000,
height: 5000,
preserve_headers: false
}
Is there something I'm doing wrong? I would have expected a 90 CW rotation on upload with the EXIF stripped.
Dan
Edit: I'm using plupload V2.3.9
BUMP
I'm getting the exact same result with plupload using these exif samples on github. I chose landscape_6, because it's Orientation is the same as my example ("Rotate 90 CW", or Orientation tag value 6). Here's the before and after upload views using IrfanView with no autorotate, preserve_headers = false:
Aren't these canonical examples for demonstrating exif properties? Unless I'm missing some fundamental point, plupload is busted. I'd much rather it be the former, and someone can tell me the error of my ways.
I am trying to get the RGB value of pixels from the TIFF image. So, what I did is:
import tifffile as tiff
a = tiff.imread("a.tif")
print (a.shape) #returns (1295, 1364, 4)
print(a) #returns [[[205 269 172 264]...[230 357 304 515]][[206 270 174 270] ... [140 208 183 286]]]
But since we know pixel color ranges from (0,255) for RGB. So, I don't understand what are these array returning, as some values are bigger than 255 and why are there 4 values?
By the way array size is 1295*1364 i.e size of image.
The normal reasons for a TIFF (or any other image) to be 4-bands are that it is:
RGBA, i.e. it contains Red, Green and Blue channels plus an alpha/transparency channel, or
CMYK, i.e. it contains Cyan, Magenta, Yellow and Black channels - this is most common in the print industry where "separations" are used in 4-colour printing, see here, or
that it is multi-band imagery, such as satellite images with Red, Green, Blue and Near Infra-red bands, e.g. Landsat MSS (Multi Spectral Scanner) or somesuch.
Note that some folks use TIFF files for topographic information, bathymetric information, microscopy and other purposes.
The likely reason for the values to be greater than 256, is that it is 16-bit data. Though it could be 10-bit, 12-bit, 32-bit, floats, doubles or something else.
Without access to your image, it is not possible to say much more. With access to your image, you could use ImageMagick at the command-line to find out more:
magick identify -verbose YourImage.TIF
Sample Output
Image: YourImage.TIF
Format: TIFF (Tagged Image File Format)
Mime type: image/tiff
Class: DirectClass
Geometry: 1024x768+0+0
Units: PixelsPerInch
Colorspace: CMYK <--- check this field
Type: ColorSeparation <--- ... and this one
Endianess: LSB
Depth: 16-bit
Channel depth:
Cyan: 16-bit <--- ... and this
Magenta: 1-bit <--- ... this
Yellow: 16-bit <--- ... and this
Black: 16-bit
Channel statistics:
...
...
You can scale the values like this:
from tifffile import imread
import numpy as np
# Open image
img = imread('image.tif')
# Convert to numpy array
npimg = np.array(img,dtype=np.float)
npimg[:,:,0]/=256
npimg[:,:,1]/=256
npimg[:,:,2]/=256
npimg[:,:,3]/=65535
print(np.mean(npimg[:,:,0]))
print(np.mean(npimg[:,:,1]))
print(np.mean(npimg[:,:,2]))
print(np.mean(npimg[:,:,3]))
i have a 2 list of png images, list _c and list _v. I want to paste _v on _c using a code like:
from PIL import Image
background = [Image.open(path, 'r') for path in glob.glob(list_c_path)]
foreground = [Image.open(path, 'r') for path in glob.glob(list_v_path)]
for im in range(len(background)):
pasted = background[im].paste(foreground[im], (0, 0), foreground[im])
This code won't work but it will give you and idea of what i want. I also need to have the images read in grayscale format before they are pasted.
Here's a sample of a background image:
Here's a sample of a foreground image:
And this is the desired result:
I pasted this images using this code:
background = Image.open('1000_c.png')
foreground = Image.open('1000_v.png')
background.paste(foreground, (0, 0), foreground)
background.save('example.png')
How can i achieve this??
Thanks in advance
Mmmm... your result images are identical to your foreground images because although the foreground images have an alpha/transparency layer, they are fully opaque and completely conceal your backgrounds. You need to have a rethink!
You can use ImageMagick in the Terminal to inspect your images. So, let's look at your foreground image:
identify -verbose fg.png
Sample Output
Image: fg.png
Format: PNG (Portable Network Graphics)
Mime type: image/png
Class: DirectClass
Geometry: 118x128+0+0
Units: Undefined
Colorspace: sRGB
Type: PaletteAlpha <--- Image does have alpha/transparency layer
Base type: Undefined
Endianess: Undefined
Depth: 8-bit
Channel depth:
Red: 8-bit
Green: 8-bit
Blue: 8-bit
Alpha: 1-bit
Channel statistics:
Pixels: 15104
Red:
min: 30 (0.117647)
...
...
Alpha:
min: 255 (1) <--- ... but alpha layer is fully opaque
max: 255 (1)
mean: 255 (1)
standard deviation: 0 (0)
kurtosis: 8.192e+51
skewness: 1e+36
entropy: 0
So there is no point pasting a fully opaque image over a background as it will fully conceal it.
If we punch a transparent hole in your foreground image with ImageMagick:
convert fg.png -region 100x100+9+14 -alpha transparent fg.png
It now looks like this:
And if we then run your code:
#!/usr/local/bin/python3
from PIL import Image
background = Image.open('bg.png')
foreground = Image.open('fg.png')
background.paste(foreground, (0, 0), foreground)
background.save('result.png')
It works:
So the moral of the story is that your foreground image either needs some transparency to allow the background to show through, or you need to use some blending mode to choose one or the other of the foreground and background images at each location, or to choose some combination - e.g. the average of the two, or the brighter of the two.
If you want to average the two images, or in fact, do any other blending mode, you could consider using Pillow's ImageChops module - documentation here. So, an average would look like this:
#!/usr/local/bin/python3
from PIL import Image, ImageChops
bg = Image.open('bg.png')
fg = Image.open('fg.png')
# Average the two images, i.e. add and divide by 2
result = ImageChops.add(bg, fg, scale=2.0)
result.save('result.png')
I have 16 jpg files which are around 920x1200 pixels (the widths slightly differ but heights are all 1200). I'm trying to join them into a pdf with:
convert *.jpg foo.pdf
But the resulting paper size is 1.53x2 inches. If I pass the arguments -page Letter, the page size ends up being a bewildering 1.02x1.32 inches. What is going wrong here? All of the information I can find suggests that this should work. I just want a document that consists of 16 letter-size pages.
This question is pretty old, but I had a similar problem and I think I found the solution.
The documentation for the -page option says "This option is used in concert with -density", but the relationship between the options seems a little unclear, possibly because the documentation is geared towards raster images.
From experimenting with the settings, I found that the pdf page size can be controlled by combining -page -density and -units. The documentation for -page shows that letter is the same as entering 612 x 792. Combining -density 72 with -units pixelsperinch will give you (612px /72px) * 1in = 8.5in.
convert *.jpg -units pixelsperinch -density 72 -page letter foo.pdf should do what the original poster wanted.
I just succeeded with
convert file.mng -page letter file.pdf
For Letter, you need to specify the size as 792x612 PostScript points. Therefor try this command:
convert \
in1.jpg \
in2.jpg \
in3.jpg \
in4.jpg \
in5.jpg \
-gravity center \
-resize 792x612\! \
letter.pdf
Works for me with ImageMagick version 6.7.8-3 2012-07-19 Q16 on Mac OS X:
identify -format "%f[%s] : %W x %H\n" letter.pdf
letter.pdf[0] : 792 x 612
letter.pdf[1] : 792 x 612
letter.pdf[2] : 792 x 612
letter.pdf[3] : 792 x 612
letter.pdf[4] : 792 x 612
Or
pdfinfo -f 1 -l 5 letter.pdf
Title: _
Producer: ImageMagick 6.7.8-3 2012-07-19 Q16 http://www.imagemagick.org
CreationDate: Fri Jul 27 22:28:00 2012
ModDate: Fri Jul 27 22:28:00 2012
Tagged: no
Form: none
Pages: 5
Encrypted: no
Page 1 size: 792 x 612 pts (letter)
Page 1 rot: 0
Page 2 size: 792 x 612 pts (letter)
Page 2 rot: 0
Page 3 size: 792 x 612 pts (letter)
Page 3 rot: 0
Page 4 size: 792 x 612 pts (letter)
Page 4 rot: 0
Page 5 size: 792 x 612 pts (letter)
Page 5 rot: 0
File size: 178642 bytes
Optimized: no
PDF version: 1.3
According to this, 72 dpi is the default density => one dot per pixel (for a computer screen).
So you just need to specify -units pixelsperinch.
You can type the following command :
$ convert *.jpg -units pixelsperinch -page letter foo.pdf
BTW : If you want to use a non standard page size such as A4R for example, you must first determine the page size in dots (or pixels given at 72dpi) :
$ paperconf -s -p A4
595.276 841.89
Then the -page argument for A4R will be 842x595
I am having much trouble to get ImageMagick's identify to, well, identify a PDF as CMYK.
Essentially, let's say I'm building this file, test.tex, with pdflatex:
\documentclass[a4paper,12pt]{article}
%% https://tex.stackexchange.com/questions/13071
\pdfcompresslevel=0
%% http://compgroups.net/comp.text.tex/Making-a-cmyk-PDF
%% ln -s /usr/share/color/icc/sRGB.icm .
% \immediate\pdfobj stream attr{/N 4} file{sRGB.icm}
% \pdfcatalog{%
% /OutputIntents [ <<
% /Type /OutputIntent
% /S/GTS_PDFA1
% /DestOutputProfile \the\pdflastobj\space 0 R
% /OutputConditionIdentifier (sRGB IEC61966-2.1)
% /Info(sRGB IEC61966-2.1)
% >> ]
% }
%% http://latex-my.blogspot.com/2010/02/cmyk-output-for-commercial-printing.html
%% https://tex.stackexchange.com/questions/9961
\usepackage[cmyk]{xcolor}
\begin{document}
Some text here...
\end{document}
If I then try to identify the resulting test.pdf file, I get it as RGB, no matter what options I've tried (at least according to the links in the source) - and yet, the colors in it would be saved as CMYK; for the source above:
$ grep -ia 'cmyk\|rgb\| k' test.pdf
0 0 0 1 k 0 0 0 1 K
0 0 0 1 k 0 0 0 1 K
0 0 0 1 k 0 0 0 1 K
0 0 0 1 k 0 0 0 1 K
FontDirectory/CMR12 known{/CMR12 findfont dup/UniqueID known{dup
/PTEX.Fullbanner (This is pdfTeX, Version 3.1415926-1.40.11-2.2 (TeX Live 2010) kpathsea version 6.0.0)
$ identify -verbose 'test.pdf[0]'
...
Type: Palette
Endianess: Undefined
Colorspace: RGB
Depth: 16/8-bit
Channel depth:
red: 8-bit
green: 8-bit
blue: 8-bit
Channel statistics:
Red:
...
Green:
...
Blue:
...
Histogram:
5: (12593,11565,11822) #31312D2D2E2E rgb(49,45,46)
4: (16448,15420,15677) #40403C3C3D3D rgb(64,60,61)
9: (20303,19275,19532) #4F4F4B4B4C4C rgb(79,75,76)
25: (23901,23130,23387) #5D5D5A5A5B5B rgb(93,90,91)
...
The same pretty much happens if I also uncomment that \immediate\pdfobj stream ...
part; and yet, if there is only one color (black) in the document, I don't see where does identify come up with a histogram of RGB values (although, arguably, all of them close to gray) ?!
So nevermind this, then I though I'd better try to use ghostscript to convert the test.pdf into a new pdf, which would be recognized as CMYK by identify - but no luck even there:
$ gs -dNOPAUSE -dBATCH -dSAFER -sDEVICE=pdfwrite -sOutputFile=test-gs.pdf -dUseCIEColor -sProcessColorModel=DeviceRGB -dProcessColorModel=/DeviceCMYK -sColorConversionStrategy=/CMYK test.pdf
GPL Ghostscript 9.01 (2011-02-07)
Copyright (C) 2010 Artifex Software, Inc. All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Processing pages 1 through 1.
Page 1
$ identify -verbose 'test-gs.pdf[0]'
...
Type: Grayscale
Base type: Grayscale
Endianess: Undefined
Colorspace: RGB
Depth: 16/8-bit
...
So the only thing that identify perceived as a change, is Type: Grayscale (from previous Type: Palette); but otherwise it still sees an RGB colorspace!
Along with this, note that identify is capable of correctly reporting a CMYK pdf - see CMYK poster example: fitting pdf page size to (bitmap) image size? #17843 - TeX - LaTeX - Stack Exchange for a command line example of generating such a PDF file using convert and gs. In fact, we can execute:
convert test.pdf -depth 8 -colorspace cmyk -alpha Off test-c.pdf
... and this will result with a PDF that will be identifyed as CMYK - however, the PDF will also be rasterized (default at 72 dpi).
EDIT: I have just discovered, that if I create an .odp presentation in OpenOffice, and export it to PDF; that PDF will by default be RGB, however, the following command (from ghostscript Examples | Production Monkeys):
# Color PDF to CMYK:
gs -dSAFER -dBATCH -dNOPAUSE -dNOCACHE -sDEVICE=pdfwrite \
-sColorConversionStrategy=CMYK -dProcessColorModel=/DeviceCMYK \
-sOutputFile=output.pdf input.pdf
... actually will produce a CMYK pdf, reported as such by identify (although, the black will be rich, not plain - on all four channels); however, this command will work only when the slide has an added image (apparently, it is the one triggering the color conversion?!)! Funnily, I cannot get the same effect from a pdflatex PDF.
So I guess my question can be asked two ways:
Are there any command-line conversion methods in Linux, that will convert an RGB pdf into a CMYK pdf while preserving vectors, which is recognized as such in identify (and will consequently build a correct histogram of CMYK colors)
Are there any other command-line Linux tools similar to identify, which would recognize use of CMYK colors correctly even in the original test.pdf from pdflatex (and possibly build a color histogram, based on an arbitrarily chosen PDF page, like identify is supposed to)?
Thanks in advance for any answers,
Cheers!
Some references:
adobe - Script (or some other means) to convert RGB to CMYK in PDF? - Stack Overflow
color - PDF colour model and LaTeX - TeX - LaTeX - Stack Exchange
color - Option cmyk for xcolor package does not produce a CMYK PDF - TeX - LaTeX - Stack Exchange
Making a cmyk PDF - comp.text.tex | Computer Group
colormanagement with ghostscript ? - Rhinocerus:
Is it for instance specified as "0 0 0
1 setcmykcolor"? Or possibly rather as "0 0 0 setrgbcolor"? In the
latter case you would end up with a rich black for text, if DeviceRGB is
remapped to a CIE-based color space in order to get RGB images color
managed.
sdaau, the command you used for trying to convert your PDF to CMYK was not correct. Try this one instead:
gs \
-o test-cmyk.pdf \
-sDEVICE=pdfwrite \
-sProcessColorModel=DeviceCMYK \
-sColorConversionStrategy=CMYK \
-sColorConversionStrategyForImages=CMYK \
test.pdf
Update
If color conversion does not work as desired and if you see a message like "Unable to convert color space to Gray, reverting strategy to LeaveColorUnchanged" then...
your Ghostscript probably is a newer release from the 9.x version series, and
your source PDF likely uses an embedded ICC color profile
In this case add -dOverrideICC to the command line and see if it changes the result as desired.
Update 2
To avoid JPEG artifacts appearing in the images (where there were none before), add:
-dEncodeColorImages=false
into the command line.
(This is true for almost all GS PDF->PDF processing, not just for this case. Because GS by default creates a completely new file with newly constructed objects and a new file structure when asked to produce PDF output -- it doesn't simply re-use the previous objects, as a more "dumb" PDF processor like pdftk does {pdftk has other advantages though, don't misunderstand my statement!}. GS applies JPEG compression by default -- look at the current Ps2pdf documentation and search for "ColorImageFilter" to learn about more details...)
I have an unrelated problem but I am also struggling with CMYK PDFs currently.
I wrote this little script here (it's called pdf2pdfx):
#!/bin/bash
gs \
-dPDFX \
-dBATCH \
-dNOPAUSE \
-dNOOUTERSAVE \
-sDEVICE=pdfwrite \
-sColorConversionStrategy=CMYK \
-dProcessColorModel=/DeviceCMYK \
-dPDFSETTINGS=/prepress \
-sOutputFile="${1%%.pdf}_X-3.pdf" \
PDFX_def.ps \
"$1"
and my PDFX_def.ps contains the following (I removed the ICC profile and defined FOGRA39, this should be OK):
%!
% $Id$
% This is a sample prefix file for creating a PDF/X-3 document.
% Feel free to modify entries marked with "Customize".
% This assumes an ICC profile to reside in the file (ISO Coated sb.icc),
% unless the user modifies the corresponding line below.
systemdict /ProcessColorModel known {
systemdict /ProcessColorModel get dup /DeviceGray ne exch /DeviceCMYK ne and
} {
true
} ifelse
{ (ERROR: ProcessColorModel must be /DeviceGray or DeviceCMYK.)=
/ProcessColorModel cvx /rangecheck signalerror
} if
% Define entries to the document Info dictionary :
% /ICCProfile (/usr/share/color/icc/ISOcoated_v2_300_eci.icc) def % Customize or remove.
[ /GTS_PDFXVersion (PDF/X-3:2002) % Must be so (the standard requires).
/Title (Title) % Customize.
/Trapped /False % Must be so (Ghostscript doesn't provide other).
/DOCINFO pdfmark
% Define an ICC profile :
currentdict /ICCProfile known {
[/_objdef {icc_PDFX} /type /stream /OBJ pdfmark
[{icc_PDFX} <</N systemdict /ProcessColorModel get /DeviceGray eq {1} {4} ifelse >> /PUT pdfmark
[{icc_PDFX} ICCProfile (r) file /PUT pdfmark
} if
% Define the output intent dictionary :
[/_objdef {OutputIntent_PDFX} /type /dict /OBJ pdfmark
[{OutputIntent_PDFX} <<
/Type /OutputIntent % Must be so (the standard requires).
/S /GTS_PDFX % Must be so (the standard requires).
/OutputCondition (Commercial and specialty printing) % Customize
/Info (none) % Customize
/OutputConditionIdentifier (FOGRA39) % Customize
/RegistryName (http://www.color.org) % Must be so (the standard requires).
currentdict /ICCProfile known {
/DestOutputProfile {icc_PDFX} % Must be so (see above).
} if
>> /PUT pdfmark
[{Catalog} <</OutputIntents [ {OutputIntent_PDFX} ]>> /PUT pdfmark
Identify then correctly reports CMYK colorspace.
Before:
tbart#blackknight ~/orpheus/werbung/action $ identify -verbose action_schulungsvideo_v3_print.pdf
Image: action_schulungsvideo_v3_print.pdf
Format: PDF (Portable Document Format)
Class: DirectClass
Geometry: 612x859+0+0
Resolution: 72x72
Print size: 8.5x11.9306
Units: Undefined
Type: TrueColor
Endianess: Undefined
Colorspace: RGB
Depth: 16/8-bit
Channel depth:
red: 8-bit
green: 8-bit
blue: 8-bit
Channel statistics:
Red:
min: 0 (0)
max: 65535 (1)
mean: 53873.6 (0.822058)
standard deviation: 19276.7 (0.294144)
kurtosis: 1.854
skewness: -1.82565
Green:
min: 0 (0)
max: 65535 (1)
mean: 55385.6 (0.84513)
standard deviation: 19274.6 (0.294112)
kurtosis: 2.09868
skewness: -1.91651
Blue:
min: 0 (0)
max: 65535 (1)
mean: 51020 (0.778516)
standard deviation: 20077.7 (0.306367)
kurtosis: 0.860627
skewness: -1.52344
Image statistics:
Overall:
min: 0 (0)
max: 65535 (1)
mean: 53426.4 (0.815235)
standard deviation: 19546.7 (0.298263)
kurtosis: 1.59453
skewness: -1.75701
Rendering intent: Undefined
Interlace: None
Background color: white
Border color: rgb(223,223,223)
Matte color: grey74
Transparent color: black
Compose: Over
Page geometry: 612x859+0+0
Dispose: Undefined
Iterations: 0
Compression: Undefined
Orientation: Undefined
Properties:
date:create: 2011-09-14T15:38:57+02:00
date:modify: 2011-09-14T15:38:57+02:00
pdf:HiResBoundingBox: 612.283x858.898+0+0
pdf:Version: PDF-1.5
signature: 210bfc9cf90e3b9505385f8b2267da1665b5c2de28bb5223311afba01718bbeb
Artifacts:
verbose: true
Tainted: False
Filesize: 1.577MBB
Number pixels: 526KB
Pixels per second: 52.57MB
User time: 0.020u
Elapsed time: 0:01.009
Version: ImageMagick 6.6.5-6 2011-04-08 Q16 http://www.imagemagick.org
after:
tbart#blackknight ~/orpheus/werbung/action $ pdf2pdfx action_schulungsvideo_v3_print.pdf
GPL Ghostscript 9.04 (2011-08-05)
Copyright (C) 2011 Artifex Software, Inc. All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Processing pages 1 through 1.
Page 1
tbart#blackknight ~/orpheus/werbung/action $ identify -verbose action_schulungsvideo_v3_print_X-3.pdf
Image: action_schulungsvideo_v3_print_X-3.pdf
Format: PDF (Portable Document Format)
Class: DirectClass
Geometry: 612x859+0+0
Resolution: 72x72
Print size: 8.5x11.9306
Units: Undefined
Type: ColorSeparation
Base type: ColorSeparation
Endianess: Undefined
Colorspace: CMYK
Depth: 16/8-bit
Channel depth:
cyan: 8-bit
magenta: 8-bit
yellow: 8-bit
black: 8-bit
Channel statistics:
Cyan:
min: 0 (0)
max: 65535 (1)
mean: 8331.78 (0.127135)
standard deviation: 14902.2 (0.227392)
kurtosis: 1.62171
skewness: 1.7799
Magenta:
min: 0 (0)
max: 62194 (0.94902)
mean: 6739.34 (0.102836)
standard deviation: 14517.5 (0.221523)
kurtosis: 2.08183
skewness: 1.93276
Yellow:
min: 0 (0)
max: 65535 (1)
mean: 13310.1 (0.203098)
standard deviation: 17022.5 (0.259746)
kurtosis: 0.991135
skewness: 1.45216
Black:
min: 0 (0)
max: 56540 (0.862745)
mean: 7117.47 (0.108606)
standard deviation: 16803.7 (0.256408)
kurtosis: 3.02752
skewness: 2.16554
Image statistics:
Overall:
min: 0 (0)
max: 65535 (1)
mean: 8874.66 (0.135419)
standard deviation: 15850.6 (0.241864)
kurtosis: 2.17614
skewness: 1.88139
Total ink density: 292%
Rendering intent: Undefined
Interlace: None
Background color: white
Border color: cmyk(223,223,223,0)
Matte color: grey74
Transparent color: black
Compose: Over
Page geometry: 612x859+0+0
Dispose: Undefined
Iterations: 0
Compression: Undefined
Orientation: Undefined
Properties:
date:create: 2011-09-14T15:39:30+02:00
date:modify: 2011-09-14T15:39:30+02:00
pdf:HiResBoundingBox: 612.28x858.9+0+0
pdf:Version: PDF-1.3
signature: 0416db7487ea147b974ece5748bc4284e82bfc3fb7cd07a4de050421ba112076
Artifacts:
verbose: true
Tainted: False
Filesize: 2.103MBB
Number pixels: 526KB
Pixels per second: 5.25708PB
User time: 0.000u
Elapsed time: 0:01.000
Version: ImageMagick 6.6.5-6 2011-04-08 Q16 http://www.imagemagick.org
This is on 64bit Gentoo with gs 9.04
Maybe that helps?
Source PDF stems from inkscape pdf export, colors were restricted to those covered in ECI ISO coated v2.
I use this as a workaround for the lacking CMYK export of inkscape and the lacking prepress-ready PDF/X output...
Ok, here is something, at least...
Originally, I need this as a way to make sure that my PDF files are in CMYK, and have the text as "plain black" C:0, M:0, Y:0, K:100 - since I've had problems with printers previously, where they would complain about my Latex PDFs containing "rich black" for text (which thus cost more). And I usually go for identify since it seems to be the only tool that can parse PDFs and colors (and it is also relatively easy to remember).
Well, I read through Tech Tip: Using Ghostscript to Convert and Combine Files | Linux Journal; where it is recommended to use the tiffsep device of gs to obtain separations. And this for me fulfills the same role as identify; I can just do:
$ gs -sDEVICE=tiffsep -dNOPAUSE -dBATCH -dSAFER -r150x150 -sOutputFile=p%08d.tif test.pdf
$ ls p*
p00000001.Black.tif p00000001.Magenta.tif p00000001.Yellow.tif p00000001.Cyan.tif p00000001.tif
$ eog p00000001.tif
... and then I can just 'iterate' through the separation images using left/right arrow - and it is immediately obvious if it is 'plain black' or 'rich black'.
So this shows that, regardless of what identify shows, the test.pdf from pdflatex actually has 'plain black' as text color, as it is supposed to (the other separations are blank) - however, doing something like:
# do a conversion of original PDF
$ gs -dPDFA -dBATCH -dNOPAUSE -dNOOUTERSAVE -dUseCIEColor -sProcessColorModel=DeviceCMYK -sDEVICE=pdfwrite -sOutputFile=out_pdfa.pdf test.pdf
# do a separation on the converted pdf
$ gs -sDEVICE=tiffsep -dNOPAUSE -dBATCH -dSAFER -r150x150 \
-dFirstPage=1 -dLastPage=1 -sOutputFile=p%08d.tif out_pdfa.pdf
# view
$ eog p00000001.tif
... will reveal that the particular out_pdfa.pdf actually has 'rich black' - i.e. ink for text goes over all four separations! (identify also shows this one as RGB, too).
So, I hope that this gs/tiffsep technique is more reliable than identify :)
Note: I'm using Ubuntu Natty, which ships GhostScript 9.01 - however, that one has a nasty bug with tiffsep: Bug 691857 – tiffsep crashes in Version 9 (missing lab.icc). That has been fixed for 9.02 - and 9.02 has been released as ghostscript in oneiric. To use 9.02 under Natty, I followed how to update a single package using apt-get? - Ubuntu Forums:
sudo nano /etc/apt/sources.list # add deb http://archive.ubuntu.com/ubuntu/ oneiric main restricted
sudo apt-get update
sudo apt-get install ghostscript # this upgrades only gs and dependencies
sudo nano /etc/apt/sources.list # remove/comment oneiric repo
sudo apt-get update && sudo apt-get upgrade # should be back to normal here
Note that with the buggy 9.01 version, even this command would fail:
$ GS_LIB=/usr/share/ghostscript/9.01/iccprofiles/ gs -sICCProfilesDir=/usr/share/ghostscript/9.01/iccprofiles/ -sDEVICE=tiffsep -dNOPAUSE -dBATCH -dSAFER -sOutputFile=p%08d.tif out_pdfa.pdf
...
sfopen: gs_parse_file_name failed.
sfopen: gs_parse_file_name failed.
... gsicc_open_search(): Could not find lab.icc ...
.. and with 9.02, there is no need to specify sICCProfilesDir explicitly.
I am also being driven insane by this. I tried #tbart's example exactly, but it only works for some input pdfs (seemingly containing images already, rgb or not?), and not others. Specifically, let's take this super simple ps file:
%!PS
/Times-Roman findfont 30 scalefont setfont
72 680 moveto
0.81 0.72 0 0 setcmykcolor
(This is text!) show
showpage
If I call this test1.ps, and then run this command (on windows, gs 9.14):
gswin64c -dEmbedAllFonts=true -dPDFX -dBATCH -dNOPAUSE -dNOOUTERSAVE -sDEVICE=pdfwrite -dProcessColorModel=/DeviceCMYK -sOutputICCProfile=CoatedGRACoL2006.icc -sColorConversionStrategy=CMYK -sColorConversionStrategyForImages=CMYK -sOutputFile=test1.pdf PDFX_def.ps test1.ps
Replace gswin64c with gs if you're on linux/cygwin.
The CMYK ICC I'm using is in the PDFX_def.ps and in the command above. You can get it from here, but it's just a random ICC that moo wants for their cards, it doesn't seem special: http://www.adobe.com/support/downloads/thankyou.jsp?ftpID=4075&fileID=3790
The test1.pdf output from this loads as a CMYK pdf in Illustrator, but identify -verbose says it's sRGB. If I do #sdaau's tiffsep thing it writes out the separations and they have the right values.
So, I dunno.
Can anybody get this ps file to convert to a CMYK pdf that identify recognizes?
Chris
Edit: whoa. I may have figured this out and fixed it. It looks like identify is just looking for a /ColorSpace /DeviceCMYK in the PDF file, so if I hack the PDFX_def.ps to output it, identify will call it CMYK. So, looking through the pdfs that worked, I found that if they had this line identify worked, and if not, they were incorrectly flagged as sRGB.
At the end of PDFX_def.ps, add the /ColorSpace /DeviceCMYK line:
[/_objdef {OutputIntent_PDFX} /type /dict /OBJ pdfmark
[{OutputIntent_PDFX} <<
/ColorSpace /DeviceCMYK % convince ImageMagick's identify that it's CMYK
/Type /OutputIntent % Must be so (the standard requires).
/S /GTS_PDFX % Must be so (the standard requires).
/OutputCondition (Commercial and specialty printing) % Customize
/Info (none) % Customize
/OutputConditionIdentifier (CGATS TR 003) % Customize
/RegistryName (http://www.color.org) % Must be so (the standard requires).
currentdict /ICCProfile known {
/DestOutputProfile {icc_PDFX} % Must be so (see above).
} if
>> /PUT pdfmark
[{Catalog} <</OutputIntents [ {OutputIntent_PDFX} ]>> /PUT pdfmark
Boom. I hope this doesn't do anything weird with compatibility or anything.
Revisiting the CMYK conversion with PDF/X-3 again as I have another print job in the queue made me find out the following:
If you only need CMYK, avoid X-3.
It does not support transparency (https://en.wikipedia.org/wiki/PDF/X) and the cyan tinted image you will get is neither satisfying nor will it actually conform to any standard. If you have alpha, opacity, gradients do not convert to PDF/X-3 if not absolutely needed by your print shop.
If you do need pdf/X you will need to rasterize and go for X-3. There is no X-4 on Linux / free software products that I know of in the "well known tool chain" (imagemagick, inkscape, gimp etc. )
I am however still fighting with defined rich black, f.ex. 60%C, 60%M, 40%Y, 100%K - a rather typical standard for print shops here. Whenever I set this in inkscape it will be gone as soon as export (to RGB; a cairo limitation)
Still, this is what seems to get me close to what they'd expect:
#!/bin/bash
# possibly ps2ps2 for keeping fonts?
pdf2ps -sOutputFile=- "$1" | gs \
-dPDFX \
-dBATCH \
-dNOPAUSE \
-dNOOUTERSAVE \
-dPDFSETTINGS=/prepress \
-dCompatibilityLevel=1.4 \
-sDEVICE=pdfwrite \
-sColorConversionStrategy=CMYK \
-sProcessColorModel=DeviceCMYK \
-dHaveTransparency=false \
-sOutputFile="${1%%.pdf}_X-3.pdf" \
PDFX_def.ps \
-
Any insights on a true CMYK creation to CMYK-PDF output workflow are still very welcome. Scribus is no real solution as it has lots of problems importing inkscape SVGs correctly.. Other than that, scribus does a decent job creating CMYK-PDFs.
I found the command line for ghostscript to be quite confusing, and googling around for this gave a lot of similar, sometimes conflicting suggestions, most of which didn't work for me.
In my case, I'm starting with a purely black or white SVG (all vectors + text). Converting that to PDF with CairoSVG makes an RGB PDF.
The minimum ghostscript (version 9.50) command I found to perform the conversion to CMYK (or "single-plate" black only) is:
gs -q -sDEVICE=pdfwrite -sColorConversionStrategy=CMYK -o <output.pdf> <intput.pdf>
Notes:
-sColorConversionStrategy=Gray will make a "single-plate", black-only file (which is actually what I wanted in my case).
-o to set the output file is not the same as the -sOutputFile switch.
<input_file.pdf> cannot be the same file as <output_file.pdf>; you'll get a blank PDF if you do that.
In my case, I did not want to keep the intermediate RGB PDF that CairoSVG produced, so I did this: cairosvg <input_file.svg> -f pdf | gs -q -sDEVICE=pdfwrite -sColorConversionStrategy=Gray -o <output_file.pdf> -; the - at the end of the ghostcript command tells it to take input from standard out.
To verify that I ended up with the PDF file I desired, I used Adobe Acrobat's Preflight check, as suggested here, for conversion to PDF/X format, which does not support RGB colors.