Just found this out:
inserting the command
print red
outputs:
Color(0.735, 0.279, 0.300, 1.000)
Which looks like RGB to me.. Even though colormode has been set to CMYK?
Printing a color always shows you the RGB values, no matter how you defined it in the first place. That's just the way they made the Color object for NB; it is still keeping track of CMYK values. You can get the individual components with red.c, red.m, red.y, red.k
Is it possible that your viewing program is using a non-default color space? This is definitely not an area that I have a lot of knowledge in, but NB's colors use NSColor, and they are using NSDeviceCMYKColorSpace, which means the colors are specific to the device they are created on. They will appear differently in different color spaces. You probably know much more about that than I do.
I've just spent a little time monkeying around with NSColorSpace and friends, and it doesn't look easy to get a generic color space. The one thing I've found that may work:
from AppKit import * colors = ximport("colors") colormode(CMYK) outputmode(CMYK) red = colors.cmyk(0, 0.9, 0.65, 0) red = red.nsColor.colorUsingColorSpace_(NSColorSpace.genericCMYKColorSpace())The first line that I added gives the script access to Cocoa objects by name, which we need to use NSColorSpace, and the last line asks red's underlying NSColor to convert itself to a device-indepent CMYK version, then re-assigns the result to red. I hope that does it.
If it doesn't, you may have to convert the output file to a different color space using your viewing program, or Photoshop, or something along those lines.
If you want to dive in to the gritty details about how Cocoa deals with color, you can read Apple's docs.
Please note that when I said "Printing a color always shows you the RGB. . ." I meant using the Python
print
statement to output a text representation of a variable. Thank you for the detailed answer! Will look into this and see if it helps..
Basically, what I've done is open the generated PDF and EPS files with Acrobat and used "output preview" to check the cmyk values - which, as i wrote, are not the same as i input in the code. Just to clarify.. The exact values are important, because I was thinking to use this in some corporate identity related print material..
Thanks, I'll tell you how it works out..
Using colorspace didnt help. Cmyk values are right inside nodebox.
Im not a programmer, but guessing the colors change somewhere in the export to pdf -phase.. Any way to export manually from code?
you can save manually from the code:
canvas.save("export.pdf")
There is, as noted by anonymous, but I don't know if it'll make a difference. I'm pretty sure that the menu item calls that same function. Take a look at the coreimage library docs.
I thought I had one other thing to try, but I can't get it to work. It was deepish hacking anyways, probably the wrong direction. I can't help feeling there's something obvious that I'm missing. Like I said, colors aren't my strong suit. Out of curiosity, do the values of:
black = colors.cmyk(0, 0, 0, 1)change?
Wish I could be more helpful.
Hi! Thanks for the help so far..
I tried what you suggested:
cyan = colors.cmyk(1, 0, 0, 0)
But that also comes out as [89%, 6%, 4%, 1%]..
the following:
canvas = coreimage.canvas(150, 150) l = canvas.append(color(1,0,0,0)) canvas.export("cyan.tif", cmyk=True, compression=True)produces a TIF where the cmyk is wrong also ([64%, 11%, 1%, 1%])..
This is unfortunate.. One of the major potentials in Nodebox for me was the ability to produce print-ready CMYK PDF-files.. Anyone know of any alternative software for this? Processing doesnt seem to be able to handle Cmyk either..
Okay, a few more things to try, if you're inclined, though I'm not hopeful.
I noticed while fooling around with HSB colors, the output was more accurate if I didn't call outputmode(HSB). It doesn't make sense, but it may be worth a stab for you to not call outputmode(CMYK). Also, although the file format may not be any use, .tiff seemed to have more accurate HSB and CMYK values.
One other thing is that you can try is bypassing NB's color (although NB just uses NSColor anyways), like this:
from AppKit import * red = NSColor.colorWithDeviceCyan_magenta_yellow_black_alpha_(0, 0.9, 0.65, 0, 1.0) # try it with and without this line? red = red.colorUsingColorSpace_(NSColorSpace.genericCMYKColorSpace()) fill(red) # etc. . .Overall, I'm pretty well stumped by this. It's possible that one of the developers can help if you email them, although I know they're pretty busy with NB2.
Good luck!
Oh, sorry, I forgot that you had already tried .tiff and it didn't come out right.
Thanks a lot for your help.
Tried your suggestion + a lot of different combinations of setting colormodes & file-formats.
Results are always off, sometimes less, sometimes more (5-10% / value).
I give up. I'll look into if theres some "post-processing" I can do in other software to correct the colors.
I think I'll mail the developers also - if they could get this + PMS-color support : ) into NB2 then it would be quite something for us working with print!
Thanks.
ouputmode(CMYK) not working?
Posted by rasnab on Jan 21, 2010Hi!
I 'm using Nodebox version 1.9.5 on Snow Leopard.
Im not able to export CMYK PDF's, EPS or even TIF's correctly.. Im using cmyk values in nodebox, and they look about right on the screen inside nodebox, but the CMYK-values in the exported files dont correspond to the values i've used in the script..
And yes, the first two lines of my script say:
colormode(CMYK)
outputmode(CMYK)
Should these commands be placed somewhere else, or does the problem lie somewhere else?
I would really like to be able to use these PDF:s directly in layouts..
A short example of what im doing:
----------
colors = ximport("colors")
colormode(CMYK)
outputmode(CMYK)
black = colors.cmyk(0, 0, 0, 1)
red = colors.cmyk(0, 0.9, 0.65, 0)
clrs = colors.list(black, red)
for i in range(100):
clr = choice(clrs)
fill(clr)
rect(0, 0, random(400), 400)
--------