Everything Else

OpenSource and Real World colour.

<announcement type="public service">

Some of you lot might have had to do with Real Colour on Real Printing Machines. Some of you might not.

Either way, this is your friendly reminder that colour calibration can be a bit of a Black Art and that most OpenSource gfx software still has issues when it comes to colour for print. Not entirely the OpenSource community's fault, but nonetheless the Scanner->GIMP->Inkscape->PDF->Real Printing Machinery workflow isn't without speedbumps.

</announcement>
:Fuel: redbox 800Mhz 4Gb V12
This is why I still work with InDesign, even though I really want to give Scribus a shot. :(
I don't work in printing, so I have no direct experience with this, but I hear frequent mention of the color issue from graphic artists commenting on GIMP, Inkscape, Scribus, etc. Are there any open source tools that handle color to industry standards?
wenp wrote: I don't work in printing, so I have no direct experience with this, but I hear frequent mention of the color issue from graphic artists commenting on GIMP, Inkscape, Scribus, etc. Are there any open source tools that handle color to industry standards?

Even before you get to the application level, you're screwed. Loonix has lcms and lcms2 which are supposed to do color management but ... the most basic step in color management is that your monitor has to match a standard. If what you are looking at is off, then it will obviously print "off".

(If you are doing the printing yourself, then you obviously also have to profile the printer. But commercial print shops are supposed to do this as a matter of course.)

Windows (and I am sure Mac) have profilometers that you drop over the monitor, then they tell the computer to display "red 3" (for example), then they compare the red 3 they see with what red 3 should be, then compensate for that with a profile that's loaded at startup.

Irix does have that but it's obscure. I'm still looking for an older profilometer that works with Irix. The 1600SW w/FPA on O2 came with that but the hardware doesn't work with any other monitor :(

But Loonix, I've never seen anything like that. If you can't even profile the monitor, where are you ? Who cares what the apps do, you're working in the dark from the very start.

One way around it would be, there are now some monitors that can profile themselves. But they are $$$$$$$$ !! That would remove operating system support from the equation, though.

btw, I've never been able to get Scribus or Inkscape to do anything except crash. My hat is off to anyone who can actually get something worthwhile out of them.
Juliet ! the dice were loaded from the start ...
hamei wrote: btw, I've never been able to get Scribus or Inkscape to do anything except crash. My hat is off to anyone who can actually get something worthwhile out of them.


I use Inkscape all the time to draw icons and suchlike. For that, it's excellent. I can even batch run it and thus get all the dpi versions of android icons updated in one stodgy go.
:Octane: halo , oct ane Image knightrider , d i g i t a l AlphaPC164, pond , soekris net6501, misc cool stuff in a rack
N.B.: I tend to talk out of my ass. Do not take it too seriously.
The opensource toolset/chain is well-suited to on-screen and non colour critical work. it's just a bit of a mess when you need colour accuracy.

@Hamei - when I get home from the Carnival I'll give Scribus and Inkscape a go see if I can get something 'worthwhile' out of them.
jimmer wrote: The opensource toolset/chain is well-suited to on-screen and non colour critical work. it's just a bit of a mess when you need colour accuracy.

The discussion of color management on Loonix sites really seems over-complex to me. There's a ton of discussion about applications using ICC profiles, &c &c. But ... why ?

The printer is the output interface to the real world. You need to know that when you tell a printer Red #3, you'll get Red #3.

The monitor is the input interface from the world. When a human looks on-screen, if he wants Red #3, then he adjusts the color he is creating to achieve that, yes ? As long as the monitor and printer both create a physical Red #3 which is the same, why add all that other crap ? The middle parts will take care of themselves.

If we were trying to achieve colors-by-the-numbers then sure. But we aren't. It's ALL decided by the human creating the graphic. So if what he sees is what he gets, the middle is incompetent, irrelevant, and immaterial.

Seems like if you could just profile the monitor in Loonix then drop in a compensation table, you'd be 90% of the way there. X-Rite, she don't wanna play with that scruffy little hooligan :(

when I get home from the Carnival I'll give Scribus and Inkscape a go see if I can get something 'worthwhile' out of them.

Oh great. Now I'm gonna have to buy a hat. Can I share it between you ?

Seriously, if you guys can make those things get as far as drawing three lines without crashing, I'm impressed. Especially Scribbles :D
Juliet ! the dice were loaded from the start ...
hamei wrote: Seriously, if you guys can make those things get as far as drawing three lines without crashing, I'm impressed. Especially Scribbles :D


This was drawn with inkscape from nekoware on IRIX, gzipped because I am not allowed to upload .svg. It's the launcher icon to one of my apps.
goldfish.svg.gz
Remember icon
(4.91 KiB) Downloaded 5 times
:Octane: halo , oct ane Image knightrider , d i g i t a l AlphaPC164, pond , soekris net6501, misc cool stuff in a rack
N.B.: I tend to talk out of my ass. Do not take it too seriously.
hamei wrote: The discussion of color management on Loonix sites really seems over-complex to me. There's a ton of discussion about applications using ICC profiles, &c &c. But ... why ?

Admittedly I haven't followed the discussion you mention so probably haven't considered some novel ways to screw it up, but your statement puzzles me. How would you propose simplifying it? It strikes me that using ICC profiles is precisely the correct way to do it.

Implemented properly, they provide a way to correctly map an input device's color space to a generic color space for processing, and then again to an output device's color space. The only way I could see to simplify it further would be cut out the generic color space and work directly in the input or output device's color space, but then once you try to use a different output device or share your file with someone else the color would break. This is the primary reason why we bother working in sRGB or other generic color spaces while processing image data on a computer.

ICC profiles are already a standard part of the workflow for anyone who cares about accurate color, i.e. professionals. They are used to deal with color management on both OS X and Windows. To not use ICC profiles would be reinventing the wheel.

The implementation probably has lots of potential for over-complication. But unless the device drivers are going to support ICC profiles directly, it will probably have to fall back to the applications to execute the mapping.
:Onyx2: 4x400MHz R12K Onyx2 IR2, 5GB RAM
:1600SW: :Indigo2IMP: R10K Indigo2 MaxIMPACT, 4 TRAMS, 768MB RAM, 2x9GB HD, CD-ROM, Phobos G160
Black Cardinal
Black Cardinal wrote: ... once you try to use a different output device or share your file with someone else the color would break.

This is where I think the error lies.

If your monitor is profiled so that red #3 is actually red #3, then whatever application you use will be creating red #3 for viewing. However the application creates it, it will be adjusted to being an actual red #3 by virtue of the human sitting in front of the screen. We are the de facto colorimeters when creating the graphic :D

Of course in real world terms it won't be Absolute Red #3 because humans can't do that. But that isn't what we want anyway. The point of color management is to get the color out that the human put in. A corrected monitor would make that happen because the human would tweak the color to get what he wants.

So if the monitor is corrected and the printer is corrected, the stuff in the middle doesn't matter. It will get adjusted to generate the color the human wants by the human at creation-time. Not an absolute numerical color measured by the frequency of the lightwave, the color that the graphic artist wants to see !

That's the point of it all.

If you use a different input or output device, it should also be corrected. If it's not, then no matter what you do it will be wrong. Same with sharing files.

Also, it's not possible no matter what you do to get the same output on everything. Shiny monitor vs matte, high-resolution vs low, inks vs light, laser vs inkjet vs dye-sub, they are all different. ICC profiles can't make a toothbrush out of a turnip. It's a waste of time to try.


Doubtless, correcting every single part would be conceptually superior. But I think of this as the difference between a Porsche and a Scat VW. The 911 engine is beautifully made but has 4,000 extra parts. While the Porsche was sitting on the bench getting its valves adjusted (6 hour job), the Scat was winning races. Lots of races.

I'm betting you can do 95% of what needs to be done with just a corrected monitor and printer. The main trouble is, for fossysoft, that X-Rite doesn't want to play with Loonies. Another guess is, the internals to the hobbyist-grade colorimeters are so simple that if the knowledge of how they work got out, there'd be five companies in China making these things for $35 each. In fact, I'm sure of it because if X-Rite sells them for $150, dollars to donuts they are buying them in China for $35. Or less. They should be afraid.
Juliet ! the dice were loaded from the start ...
As a bit of an aside I hasten to point out that your typical Hollywood-quality digital compositor (for example Shake, which I have on my Octane) has incredible color correction capability, to ensure that cgi's, from Maya or Lightwave or whatever, that are being composited into film frames don't look weirdly off... :roll:
Project:
Temporarily lost at sea...
Plan:
World domination! Or something...
hamei wrote: So if the monitor is corrected and the printer is corrected, the stuff in the middle doesn't matter. It will get adjusted to generate the color the human wants by the human at creation-time. Not an absolute numerical color measured by the frequency of the lightwave, the color that the graphic artist wants to see !

That's the point of it all.

If you use a different input or output device, it should also be corrected. If it's not, then no matter what you do it will be wrong. Same with sharing files.

Agreed. But if you don't do this correction with ICC profiles, then you still have to do it with some equivalent mapping mechanism. Why not stick with the standard? On most modern systems, when you use a spectrophotometer to measure your monitor or printer output and get correction values, what you are doing is creating a custom ICC profile for that device. Nobody who really cares about color accuracy trusts the default profiles for devices, they measure and create a custom one for each set of variables. For printers, this would include paper type, weight, print mode, etc.

Edit: I just talked with one of my company's color science experts and he said that our ICC profiles transform between L*a*b (absolute color coordinates) and the device color spaces. I had mentioned sRGB above but that is apparently used more in the video world.
:Onyx2: 4x400MHz R12K Onyx2 IR2, 5GB RAM
:1600SW: :Indigo2IMP: R10K Indigo2 MaxIMPACT, 4 TRAMS, 768MB RAM, 2x9GB HD, CD-ROM, Phobos G160
Black Cardinal
sRGB is used by consumer digital cameras and is the default colorspace for JPEG images. Most web graphics are displayed in sRGB. Video is something else again, usually YPbPr.
Lab is used as a standard because it covers all colors the eye can see. But there is nothing that prevents direct conversion between other color spaces.
When you calibrate a display, you generate curves that will be stored in the graphics color LUTs. The image data isn't converted to the display color space; instead, the display system is adjusted to correct nonlinearity in the screen. It will be calibrated to a standard illuminant like D65.
You can choose different illuminants or color temperatures: the same RGB image data will look different at D50 or D70. There is really no way to "make the screen and the printed output the same color" because one is additive and the other is subtractive. What you do is decide under what lighting the print is going to be viewed (magazines are expected to be viewed under incandescent light, or used to be anyway. photographs sometimes under indirect sunlight) and calibrate your monitor to an appropriate illuminant. When the illuminants match then the colors should appear the same.

When you transfer image files, whatever the format, they can be tagged with a color profile. That profile will be from the scanner or from the printer (never the screen profile). Then the recipient can view and print the image with its original colors.
:PI: :O2: :Indigo2IMP: :Indigo2IMP:
@Hamei: Have given up on getting scribus to work. The neko packages from current dont run on my system and the new scribus needs versions of qt that wont compile on our beloved 20 yr old machines. Oh well.
Black Cardinal wrote: Agreed. But if you don't do this correction with ICC profiles, then you still have to do it with some equivalent mapping mechanism. Why not stick with the standard?

I don't have a problem with ICC profiles :) but here is where I see the train going off the tracks ...

Real professionals already know what they are doing and they have the tools to do it with. Lustre is, what, $150,000 USD ? So we're not really talking about Lucasfilm.

A few years ago we had a lot of grief with printers, maybe similar to what jimmer started the thread over. Only worse ... in China, you can spend several days getting your stuff exactly how you want it, then you take it to the printer and the first thing they do is open CorelDraw and drag all your carefully laid out graphics into the wrong program with the wrong fonts at all the wrong sizes. Then they print that and expect you to take it with a smile. Sometimes they even 'correct' your spelling. Too bad they can't speak or spell in English. Seriously.

We didn't buy a Xerox printer that's the size of a house because we wanted to look cool.

So I went through all the online stuff about color spaces and colorimeters and spygnaphomometers and other dandy stuff and we bought a Spyder 3. Profiled the monitor. Cool ! Used the ICC profile on the printer. Cool !

Except, it kinda wasn't. To actually get things to match we had to adjust by eye. And that's probably not 'right' but now what we see on-screen is now what we get from the printer (on the Windows box, cuz the Irix box is totally different and I am NOT going to make my Octane look like a peecee, but everyone else in the world uses peecee's, so there ya have it, the flaw in userland "color correction" right off. People like their monitors to look the way they like them to look, which ain't 'standard' so how is this going to work ?) .

And that's the point.

On most modern systems, when you use a spectrophotometer to measure your monitor or printer output and get correction values, what you are doing is creating a custom ICC profile for that device. Nobody who really cares about color accuracy trusts the default profiles for devices,

EXACTLY ! Which brings up another few points ...


1) the 'standard' ICC profiles for devices ... well, they don't work. Maybe on a brand new device but even there I have my doubts. Maybe on a standard high-end Eizo or NEC, but not on runofthemill Office Depot printers and monitors.

Which is what most people use, so ...

2) the devices people are using to create these profiles ... at the time, I read up on shit, the Spyder 3 was yay ! great ! cool ! wonderful ! so much better and more reliable than the Spyder 2 and the Huey is crap and the DTP-92 is so ooold ...

Yeah, right. Marketing marketing marketing. In fact, the Spyder 3 is kind of crap, now it's the Spyder 5 that's Wonderful ! so much better ! but in a year we'll hear that oh-oh, actually you need the Spyder 9 but in fact, I've seen a few charts where Luminous Landscape tested a series of these things, once they stuck in an antique Gretag Sinaloamometer or whatever its name was, the damn thing was third-best STILL out of all their devices but they didn't say a word about this. One thing about being old is, you get to recognize the same old shyster schtick once you've seen it about thirty times.

And THEN you discover that ALL colorimeters are really no good, no matter how expensive, the filters degrade over time. But the spectrophotometers are no good in the darker, low-light regimes.

In fact, the truth is none of the cheap units are worth a shit. Something I know as a fact from making parts is, if you can't measure it reliably and your measuring tools are not calibrated at least annualy, then everything you say is nothing but a joke.

Which pretty much describes the state of user-level color correction.

I read all these guys' comments in the photo bulletin boards and have to think, unless they pay the big bucks for a measuring unit, they are just pulling their puds.

And that's pretty much where Loonix is as well. Almost no one is going to pay real money for a pro-level spectrophotometer. Almost no one is going to have their colorimeters calibrated every six months.

If you are, then you already know what you're doing. Otherwise, all this talk of 'color-managed-workflow' and getting Loonix to use ICC profiles for every program and printer they 'support' is just a giant circle jerk. It's Yet Another 68,000 Dependencies that don't do anything (except get in the way.)


btw, discovered that OptiCal had an Irix (and Loonix) binary and supports the Minolta CA-100. Those are available fairly cheap used, now we're talkin an instrument that might actually measure. After you get it recalibrated, anyhow :D


No, I'm not trying to say that color management is a fraud. But the Loonix implementation of it is a joke and from History, whatever they do next with it will be even worse, e.g. GTK3.

jimmer wrote: Have given up on getting scribus to work. The neko packages from current dont run on my system and the new scribus needs versions of qt that wont compile on our beloved 20 yr old machines. Oh well.

My experience as well :( Also tried it on Windows. Inkscape, too. If they can't make it run without a bunch of pointless toys, I'm not going to screw with it. Gtk2, gcc-isms, shithub, qt, gag me with a spoon. More of the same pointless stupid crap just because it's kewl. Fuck 'em.
Juliet ! the dice were loaded from the start ...
Black Cardinal wrote: Nobody who really cares about color accuracy trusts the default profiles for devices, they measure and create a custom one for each set of variables.

It's worse than that. Devices change as they age, and possibly with environmental conditions, so the profiles need to be updated periodically (annually? bi-annually? not sure what the actual period is, and it probably depends on how much you care about color accuracy).
nyef wrote:
Black Cardinal wrote: Nobody who really cares about color accuracy trusts the default profiles for devices, they measure and create a custom one for each set of variables.

It's worse than that. Devices change as they age, and possibly with environmental conditions, so the profiles need to be updated periodically (annually? bi-annually? not sure what the actual period is, and it probably depends on how much you care about color accuracy).

On Loonix, it's doube-triple-quadruple hopeless. I haven't looked into this for a little while, did a quick refresher. Argyll seems to have come along a ways, nice. Then I went here ...

http://dispcalgui.hoech.net/#runsource

fuck. That's all I can say, just "fuck". What a total crock of shit.

"running from source" ... gag me with a spoon, there is no source, it's an effing python script.

dispcal dipshit wrote:
Running directly from source

After satisfying all additional requirements for using the source code, you can simply run any of the included .pyw files from a terminal, e.g. python2 dispcalGUI.pyw, or install the software so you can access it via your desktop's application menu with python2 setup.py install. Run python2 setup.py --help to view available options.

One-time setup instructions for source code checked out from SVN:

Run python2 setup.py to create the version file so you don't see the update popup at launch.

If the pre-compiled extension module that is included in the sources does not work for you (in that case you'll notice that the movable measurement window's size does not closely match the size of the borderless window generated by Argyll CMS during display measurements) or you want to re-build it unconditionally, run python2 setup.py build_ext -i to re-build it from scratch (you need to satisfy the requirements for compiling the C extension module first).

It gets worse ...
moronic shitforbrains so-called developer wrote: Starting with dispcalGUI 0.2.5b, you can use standard distutils/setuptools commands with setup.py to build, install, and create packages. sudo python setup.py install will compile the extension modules and do a standard installation. Run python setup.py --help or python setup.py --help-commands for more information. A few additional commands and options which are not part of distutils or setuptools (and thus do not appear in the help) are also available:
Additional setup commands

0install
Create/update 0install feeds and create Mac OS X application bundles to run those feeds.
appdata
Create/update AppData file.
bdist_appdmg (Mac OS X only)
Creates a DMG of previously created (by the py2app or bdist_standalone commands) application bundles, or if used together with the 0install command.
bdist_deb (Linux/Debian-based)
Create an installable Debian (.deb) package, much like the standard distutils command bdist_rpm for RPM packages. Prerequisites: You first need to install alien and rpmdb, create a dummy RPM database via sudo rpmdb --initdb, then edit (or create from scratch) the setup.cfg (you can have a look at misc/setup.ubuntu9.cfg for a working example). Under Ubuntu, running utils/dist_ubuntu.sh will automatically use the correct setup.cfg. If you are using Ubuntu 11.04 or any other debian-based distribution which has Python 2.7 as default, you need to edit /usr/lib/python2.7/distutils/command/bdist_rpm.py, and change the line install_cmd = ('%s install -O1 --root=$RPM_BUILD_ROOT ' to install_cmd = ('%s install --root=$RPM_BUILD_ROOT ' by removing the -O1 flag. Also, you need to change /usr/lib/rpm/brp-compress to do nothing (e.g. change the file contents to exit 0, but don't forget to create a backup copy first) otherwise you will get errors when building.
bdist_lipa
Create a Listaller package.
bdist_pyi
An alternative to bdist_standalone, which uses PyInstaller instead of bbfreeze/py2app/py2exe.
bdist_standalone
Creates a standalone application that does not require a Python installation. Uses bbfreeze on Linux, py2app on Mac OS X and py2exe on Windows. setup.py will try and automatically download/install these packages for you if they are not yet installed and if not using the --use-distutils switch. Note: On Mac OS X, older versions of py2app (before 0.4) are not able to access files inside python “egg” files (which are basically ZIP-compressed folders). Setuptools, which is needed by py2app, will normally be installed in “egg” form, thus preventing those older py2app versions from accessing its contents. To fix this, you need to remove any installed setuptools-<version>-py<python-version>.egg files from your Python installation's site-packages directory (normally found under /Library/Frameworks/Python.framework/Versions/Current/lib). Then, run sudo python util/ez_setup.py -Z setuptools which will install setuptools unpacked, thus allowing py2app to acces all its files. This is no longer an issue with py2app 0.4 and later.
buildservice
Creates control files for openSUSE Build Service (also happens implicitly when invoking sdist).
finalize_msi (Windows only)
Adds icons and start menu shortcuts to the MSI installer previously created with bdist_msi. Successful MSI creation needs a patched msilib (additional information).
inno (Windows only)
Creates Inno Setup scripts which can be used to compile setup executables for standalone applications generated by the py2exe or bdist_standalone commands and for 0install.
purge
Removes the build and dispcalGUI.egg-info directories including their contents.
purge_dist
Removes the dist directory and its contents.
readme
Creates README.html by parsing misc/README.template.html and substituting placeholders like date and version numbers.
uninstall
Uninstalls the package. You can specify the same options as for the install command.

Additional setup options

--cfg=<name>
Use an alternate setup.cfg, e.g. tailored for a given Linux distribution. The original setup.cfg is backed up and restored afterwards. The alternate file must exist as misc/setup.<name>.cfg
-n, --dry-run
Don't actually do anything. Useful in combination with the uninstall command to see which files would be removed.
--skip-instrument-configuration-files
Skip installation of udev rules and hotplug scripts.
--skip-postinstall
Skip post-installation on Linux (an entry in the desktop menu will still be created, but may not become visible until logging out and back in or rebooting) and Windows (no shortcuts in the start menu will be created at all).
-stability=stable|testing|developer|buggy|insecure
Set the stability for the implementation that is added/updated via the 0install command.
--use-distutils
Force setup to use distutils (default) instead of setuptools. This is useful in combination with the bdist* commands, because it will avoid an artificial dependency on setuptools. This is actually a switch, use it once and the choice is remembered until you specify the --use-setuptools switch (see next paragraph).
--use-setuptools
Force setup to try and use setuptools instead of distutils. This is actually a switch, use it once and the choice is remembered until you specify the --use-distutils switch (see above).


I used to think Windows was bad. Dispyguy, please take your ridiculous horseshit play-with-yourself useless crap and go away. Far away. Off the edge of the earth would be nice.

./configure, make, make install. It works. Try it some time.

Loonix. The breakfast of imbeciles.
Juliet ! the dice were loaded from the start ...