Linux users rejoice!

<p>It is now possible to fully calibrate a monitor for Linux!</p>

 

<p>The catch is that you still need Windows to run the hardware calibrator. I

am writing this in the light of the <a

href="http://www.photo.net/bboard/q-and-a-fetch-msg?msg_id=00HHra">recent

thread here</a> which was concerned with monitor calibration on UNIX. Don E

there suggested (thanks Don!) that I run Gretag Macbeth's EyeOne Match on

Windows, and then

load the resulting profile on Linux with <a

href="http://www.etg.e-technik.uni-erlangen.de/web/doe/xcalib/">xcalib</a>.

Today I did just that, and it worked magnificently! Xcalib is "postcardware,"

so

I am just about to send a postcard to Stefan Doehla who wrote the program.</p>

 

<p>Current versions of Xcalib may not work with all ATI card/driver

combinations (I used an NVIDIA card and everything went fine). But even if

Xcalib does not work on your machine, it is still useful to run the monitor

through the hardware calibration procedure, because it will ensure your

monitor is set to the desired temperature, has the desired gamma, and has more

or

less proper gray tone reproduction. Also, Cinepaint and some other programs

(Bibble, UFRaw, and Scribus come to mind) which support color management on

Linux will be able to use the produced profile.</p>

 

<p>With my Philips aperture-grill CRT, I almost didn't need a profile at all

after the EyeOne calibration, as can be seen from the upper data sheet below.

With LCDs things are a bit more tricky. On the bottom, for a comparison, is a

Dell 1703FP (Samsung PVA panel) data sheet. Notice how the color reproduction

curves diverge on the bottom (LCD) data sheet -- if I fiddled even more with

the on-screen buttons I probably could have have gotten the curves a bit

closer together, but I'm too lazy for that. With the CRT I didn't need to

adjust the color controls at all, and just used a "Photoretouching" preset

(~5800K, although described as 5500K).</p><div></div>

Excellent news! Forgive me because I am a bit out of touch with the current state of the Gimp: can it deal with color managed files and 16-bit? I seem to remember that at least not so long ago it couldn't do either of those, which makes it a deal breaker for me (even though I'd much rather do my image processing on Linux).

Gimp still can't handle colour management or 16 bit files, but <b><a href="http://www.cinepaint.org">CinePaint</a> can</b>.

<p>Chad, not as of yet. There is a lot of talk on GIMP development

forums about color management, and there is a plugin that can apply

ICC profiles, but no 16-bit yet. I take it GIMP was never intended

to be a high-end photo-editing program.</p>

 

<p>I wish Cinepaint's development was as active as the GIMP's, then

one would have a real alternative to PS.</p>

AFAIK gimp developers are clueless regarding color management and 16bit depth, thereby rendering the application irrelevant for any professional use. They are, however, hot on the trail of JPEG 2000 support for all two people who want it. The lack of initiative and imagination of the Gimp developers is truely breathtaking. JPEG 2000 support? Sheesh.

 

Cinepaint remains buggy, at least in any distribution I've installed. When it works, it works well, though. Faint praise, I know.

 

Eugene, good work. Congrats.

 

--

 

Don E

The problem with Cinepaint is that their development is very slow,

and instead of fixing up the bugs in their existing program, they

decided to transition to a whole new model called Glasgow, which

will arrive when the pigs grow wings.

Eugene,

 

Your upper data sheet shows a luminance of 72 vs a target of 100. How old is your CRT monitor ?

Alistair, the monitor was not at its full brightness. This is

because, after I ran the "Set Brightness" part of EyeOne Match, it

told me to set the brightness to 69% which is what it's at right

now. Because I asked EyeOne Match initially to give me 100cd/m2, I

though (naturally) that 69% gives 100cd/m2. However, after the

calibration had completed, it told me I have 72cd/m2. What's wrong?

Eugene,

 

I believe Google has released a linux version of Picasa (probably incorporating WINE or requiring it separately) for i386. Isn't Picasa color-aware? I run AMD64, so I'd have to set up a dchroot to run it. If you're on i386 , you might give it a try and let us know.

 

Regards

 

Don E

Eugene - I have the same luminance problem with my Samsung 997 CRT. The EyeOne has me set the brightness at about 35%, but the luminance always ends up at ~90 instead of the requested 100. I've never really worried about it (the monitor is plenty bright), but it's interesting to hear that I'm not the only one experiencing this glitch.

Don, I just installed Picasa, and I don't see any option to

associate a display profile. It's a very basic application. For all

my 16-bit needs on Linux, I use Cinepaint, which as of 0.21 version

has had the nastiest bugs fixed, although it sorely lacks the

smoothness of Photoshop or even GIMP.

Excellent news, Eugene. Could you write a short "how-to" for novice Linux users on how to get Xcalib working and perhaps automatically launcinh on startup?

<I>The lack of initiative and imagination of the Gimp developers is truely breathtaking. </i><P>Paychecks tend to motivate developers.

And hobbyist developers tend to have a special myopia where they only see the features they use themselves as relevant. Thus web development programmers only see use for an image editor for web graphics and finer points like color matching and fixing color from negative scans tend to elude them. I think that's part of why your average linux distribution seems to come with at least a dozen text editors, 3 or 4 of which are derivatives of VI.

<p>

<ol>

<li>Either download a precompiled binary from <a

href="http://www.etg.e-technik.uni-erlangen.de/web/doe/xcalib/">http://www.etg.e-technik.uni-erlangen.de/web/doe/xcalib/</a>

or download and unpack the sources.<br><br></li>

<li>Put the binary file in <strong>/usr/local/bin/</strong>. If

compiling from source,

simply type on the command line while in the source directory:

<br><br><strong>

make<br>

su<br>

make install<br><br></strong>

</li>

<li>Put the following lines in your

<strong>/etc/X11/xinit/xinitrc</strong>

file:<br><br><strong>

# Monitor calibration loader<br>

/usr/local/bin/xcalib /path/to/your/monitor_profile.icc<br><br></strong>

(just don't forget to replace "/path/to/your/monitor_profile.icc"

with

the full path to your ICC profile)<br><br>

</li>

<li>If for whatever reason you want to undo the effect of loading a

profile,

type:<br><br>

<strong>xcalib -clear</strong><br><br></li>

<li>If everything's working, send a postcard to Stefan.</li>

</ol>

</p>

Just in case, have you tested it with a profile that uses LUTs (without using monitor buttons) to achieve a significantly different target (like 5000K)?

 

It sounds great... Really great. Bibble is 75% of what you need for RAW photography... BTW, does Linux version have Noise Ninja?

Ahem... Since for some reason you use 5500K (hey - who am I to tell you what looks white?) then 7000 would be a significantly different target...

"The lack of initiative and imagination of the Gimp developers is truely breathtaking.

 

Paychecks tend to motivate developers."

 

Scott,

 

Yah, they're all slaving away for pig droppings...it's not that. The free sw developers I know can pull in a paycheck that would make my eyes pop.

 

One problem is so many of them are comfortable. Their real commitment is usually to private and arcane projects of no value to either a Linux distribution or anything else. Whatever paychecks they decide to collect goes to support their coding habit. To develop applications for Linux often means developing for Gnome or KDE, subjects of minor, if any, interest to them.

 

What I think has been happening is the most creative developers are participating much less in mainstream open source projects. They are moving on, leaving the field to lesser talents who are able to endure, perhaps even get excited about, the big rollout of support for JPEG 2000. They are looking more and more like corporate vb coders and with the same attitudes, slavishly following the lead of MS and Apple. They are not the hackerly coding samurai of the previous generation.

 

Too bad.

 

--

 

Don E

<I>...seems to come with at least a dozen text editors, 3 or 4 of which are derivatives of VI.</I>

 

<P>Hey, don't knock vi; I use it on a daily basis. What more could you want from a text editor! ;)

"Bibble is 75% of what you need for RAW photography... BTW, does Linux version have Noise Ninja?"

 

Serge,

 

NN makes a linux version of the standalone. I believe there is Vuescan for linux as well. There's probably more, too. In fact, there's everything you need -- except color management and 16bit depth support (Cinepaint doesn't count until "Glasgow", I guess).

 

I expect to see a Linux version of Lightroom before I see The Gimp with such capabilities, which is to say probably never.

 

So, the big big hole in the workflow is the image editor, which is the only piece of the puzzle that is open source -- The Gimp, which is now surrounded by proprietary applications on its own turf, and not from vast corporate entities either. Well, what's there to say about an image editor that doesn't have even an image filebrowser, but with a related application (gthumb) that doesn't support the Gimp's file format? In fact, does any Linux thumbnailer/browser/viewer support xcf?

 

No initiative plus no imagination gets you all comfy in your rut, which is where open source seems to be these days.

 

 

--

 

Don E

I know what you're saying. But after you make Linux reasonably colormanaged (thanks to apple it mostly means loading LUTs from a vcgt tag) it makes sense to buy commercial applications that work on it. The lack of clear color management held back serious users from considering Linux as a viable option.

 

Now - I agree about image editors. I also think that for many photographers image editing is not the main element of their work, provided they have a robust RAW converter. Or at least it does not have to be. It obviously depends on your workflow.

 

At least now you know you CAN have a colormanaged workflow in Linux as a photographer... And then do pixel pushing in windows or OS X...

Take a look at this editor PIXEL:

http://www.kanzelsberger.com/pixel/

Serge,

 

Taking a higher level view of the issue -- I find it odd that a core concept of unix, workflow, never made it to applications on Linux desktops. The applications may be feature-rich, but they are not often task-oriented. They don't have workflow. 'Usability' and 'configurability' haunt the Linux forums, but not 'workflow'.

 

Consider the possible workflows for a text file in a shell, then for an image file on the desktop. Aside from the color management and bit depth issues, the workflow has gotten easier on other platforms, while Linux development in this area, it seems, has not even noticed there's an issue. And that is why I am not optimistic.

 

Regards,

 

 

Don E

<a href="http://www.dl-c.com/">Picture Window</a> can run <a

href="http://www.salgarelli.com/technical/ldd/editing.php" />on

Linux using WINE</a> (in the same way Picasa does). Picture Window

is specifically designed for photographers and supports both 16-bit

and color management. I haven't tested it yet on Linux though, but

on Windows it is a nice editor for files that come out of a RAW

converter.

<p><i>have you tested it with a profile that uses LUTs (without

using monitor buttons) to achieve a significantly different target

(like 5000K)?></i></p>

 

<p>Serge, do you have any such profiles? If you do, send them in. I

take it that xcalib will use any profile that has a vcgt tag (Video

Card Gamma Table). Below is a graph of what gets loaded on my

monitor (darker tones become slightly darker when I load the

profile).</p><div></div>