Linux users rejoice!

[eugene_scherba]

<p>Okay, apparently it does support LUTs. Below is a quote from

README documentation:</p>

 

<p>last parameter MUST be an ICC profile containing a vcgt or

<strong>mLUT</strong> tag.</p>

[serge c]

It's supposed to load LUTs from a vcgt tag, that's what you need it for. It's just since you are loading very minor adjustments it's harder to tell how well it does the job. Sending you one of my profiles wouldn't work cause my hardware native state is different and also you wouldn't be able to compare them to Windows. All I suggested is to calibrate in Windows to 7000K, (which would look blue compared to your 5500K) without touching the monitor buttons (by indicating you only have presets, but not changing the presets either). That would require stronger LUT adjustment and it would be easier to see if the result you see in Linux is similar to what you achieve in Windows...

 

I just don't have Linux installed now, so can't check myself... You could also measure patches on Linux by connecting a colorimeter to a second machine running Windows... For instance in Basiccolor you can just Measure white point and white and black luminance and in Spyder2 Pro you can just read arbitrary RGB patches...

 

I'm just thinking of how to validate that what gets loaded corresponds to Windows output.

[eugene_scherba]

<p>Serge, check out Stefan's <a

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

file. It has detailed

descriptions on how xcalib works. It mentions somewhere that it does

interpolate complex LUTs but I am not sure to what extent and

whether this results in significant deviations from the base

input.</p>

 

<p>Attached is a README.profilers file which compares how different

calibrators embed the data in the profile.</p>

[eugene_scherba]

BTW, it's too hard for me to calibrate the monitor again to 7000K

because the monitor is heavy, is located in another room from my

Windows PC, and 'cause I'm lazy ;) Also, even if I did calibrate it

to 7000K, I wouldn't have a way to verify that it really is 7000K on

Linux, because I don't have BasiCColor.

[scott_eaton]

<I>They are not the hackerly coding samurai of the previous generation. </i><P>That's because you can't pay a mortgage writing 'freeware', and this new generation of coders *is* competing with developers in India and elsewhere who *are* working for "pig droppings". <P>I'm also seeing a cooling of the 'anti-establishment' attitude of the Open Source warriors who usually just need the motivation of knowing they're hurting some big corporate entity like MS, or Apple etc. Just not as much fun trying to 'stick it to Adobe', etc.

[eugene_scherba]

Scott, let's keep your sarcasm elsewhere.

[Richard Williams]

Krita is worth a look:

 

http://www.koffice.org/krita

[serge c]

"BTW, it's too hard for me to calibrate the monitor again to 7000K because the monitor is heavy, is located in another room from my Windows PC, and 'cause I'm lazy ;)"

 

I don't quite understand... It has to be connected to the same computer you've ran your calibration on. Cause during profiling the software measures the combination of the monitor and the videocard output. You can't take a profile with a monitor to another machine... I mean you can but it won't be an accurate profile anymore... (even if you don't use LUTs - especially if it's an analog monitor).

 

Oh well. I'll check myself in a couple of days - need to get a wired keyboard to install Linux (to replace the one I spilled beer on).

 

I agree Linux has usability issues especially for graphics work (that's why I'm not using it) but overall it's a very good thing to have it around. And it's good to know how to manage color on it.

[don_e]

Eugene,

 

I have Picture Window Pro and recollect discussions on its forum about running it under WINE, but I hadn't followed up due to the lack of cm in Linux. That appears to be changing. I've put a Linux partition on an i386 running PWP and with a calibrated moniter. Since PWP is my main image editor (at least until the final release of Lightroom), I'm looking forward to pulling the pieces together. I'll post the results here.

 

Regards,

 

Don E

[eugene_scherba]

<p>Serge, I agree with everything you said, but like I said, I'm

lazy.</p>

 

<p>The point for me wasn't getting a 99.9% accurate monitor

profile -- the point was to check whether xcalib is at least

approximately working as advertised (and getting a half-assed,

95%-good profile along the way as a bonus).</p>

 

<p>Because my Linux machine is a server that should preferably have

NO downtime at all, and because all of its disks have been

partitioned for JFS filesystem, it would be a huge pain for me to

install Windows on it on a separate partition. It would also be a

pain in the ass to have the machine down just to take out the

graphics card in order to use if for calibration on a separate

PC.</p>

 

<p>So instead of playing videocard poker, I just switched the

monitors and then copied the profile. Yeah, it is not 99.9%

accurate, but I don't do any critical imaging work on my Linux

server (as there is no Photoshop anyway).</p>

 

<p>Sometimes it is better to just trust me on how I am running my

boxes, heh.</p>

[serge c]

That's cool. I believe from what you describe it all should work. I read the documentation on Xcalib site some time ago and it seemed exactly like a type of loader one would need to use profiles generated on Windows (or OS X for that matter).

[kelly_flanigan1]

Interesting stuff, here tonight I'm printing 2007 calendars. The workhorse box I use has 2 gigs of ram, win 2000, an old P4 2.5Ghz, with a decade plus diamond stealth PCI card.

[vincent_j_m]

Scott Eaton wrote:

<p>

"<i>That's because you can't pay a mortgage writing 'freeware', and this new generation of coders *is* competing with developers in India and elsewhere who *are* working for "pig droppings".</i>"

<p>

<p>

Scott that is quite juvenile. Are you feeling threatened by those chaps in underdeveloped countries who work for pig droppings? The west was and is responsible for bringing the free market system to those countries like India, China etc, and that includes competition both ways. That is the reality today. If you can't deal with it, take your sarcasm elsewhere.

[serge c]

Well, since I really like Bibble I went and read their discussion on Linux.

 

Surprizingly they recommend not to load LUTs via Xcalib since, apparently, Bibble does it by itself in Linux. It's still an ongoing discussion over there.

 

Good news for Xrite users is that newer Argyllcms is supposed to support DTP-94. That way you could do native calibration on Linux.

 

Another interesting question raised is that Xcalib uses 8 bit LUTs while most modern calibration software uses 16 bits...

 

http://support.bibblelabs.com/webboard/viewtopic.php?t=5201

[eugene_scherba]

Thanks Serge, I'll read into that discussion later on.

[serge c]

Never mind. Bibble does not load LUTs. Eric Hyman (the author of Bibble) is just mistaken about what loading LUTs does. To be fair from his perspective it does not matter. He only needs to be concerned with correct gamut conversion.

[serge c]

As I continue reading on the subgect it turns out Argyll CMS has it's own LUT loader - dispwin.

 

In addition Argyll can natively run calibration under Linux using certain Xrite colorimeters, like DTP-92 and DTP-94

 

http://www.argyllcms.com/doc/dispwin.html

 

http://linux.softpedia.com/get/Programming/Libraries/Argyll-Color-Management-System-4795.shtml

[eugene_scherba]

So is dispwin 16- or 8-bit? Does it matter anyways, since all

display output from the operating system is 8-bit?

[eugene_scherba]

<p>Serge, I just read the discussion at the Bibble forum, and was

surprised Eric wasn't aware about LUTs and VCGTs. I myself learned a

few things from you here, so big thanks for participating in the

discussion.</p>

 

<p>I just upgraded my installation of Argyll CMS (I had version 0.52

before) with 0.60, and indeed dispwin does exactly the same thing

xcalib does. After playing around with the two, I found the two

utilities to be interchangeable (can load VCGT with xcalib, then

cancel it with dispwin, and vice versa) and noninteracting, so I

guess they work the same way.</p>

 

<p>A quote from xcalib documentation: <i>Under Linux we cannot set

the video-LUT itself but a X-server gamma ramp (which does

practically the same)</i>. I wonder if there is any

quality/performance

difference between loading the VCGT contents into videocard LUT as

opposed to loading it into X-server, and also how the whole 16-bit

vs 8-bit vs 10-bit thing comes into play here.</p>

[serge c]

Allright. I finally got it working. Couldn't launch it via xinitrc for some reason.I'm using Ubuntu... I launched it on Gnome startup (System/Preferences/Sessions - Startup Programs). Anyway, when I have some free time I'll take some measurments...

[serge c]

So ... I tested how it works. I swear I don't normally work that hard. Bottom line - it works.

 

I created a profile using Spyder2 Pro with 5000K/2.2 targets (natively my monitors ar close to 6100K or so, so significant LUTs adjustments were used).

 

I used Colorvision's Spyder2 Pro's "Colorimeter" utility that essentially measures any patch you want. I ran that utility on my secondary computer while booting my main PC to XP and later to Ubuntu... In XP the profile was loaded using the Color Applet and it's LUT loader. In Ubuntu LUTs were loaded on Gnome startup. Ubuntu had Nvidia drivers loaded. Dell 2001FP, native 1600x1200 resolution, DVI.

 

To create patches I used non-colormanaged Gimp and Windows Paint. The patches were measured from the second computer with the Spyder2 Colorimeter. I measured 5 greyscale patches (0, 64, 128, 194 and 255), then R, G, B and also 3 arbitrary patches close to C, M and Y.

 

I had to use Bruce Lindbloom's calculator to convert measurments to Lab

http://www.brucelindbloom.com/index.html?ColorCalculator.html

and Delta E calculator to compare the measurments

http://www.colorspan.com/support/tools/deltae.asp

 

Delta E is the difference between 2 colors, in this case the same RGB values displayed in non-colormanaged Windows and Linux applications. Overall Delta E is in an acceptable range. It varies between 0.3 and 5. On average it's close to 3.5, which is barely distinguishable by a human observer. Considering that it's taken on different operating systems at a different time it's a very good result.

 

I would say loading LUTs via Xcalib works really well for Linux color management.

 

So like... I went ahead and created an entry in Wikipedia, modestly named "Linux Color Management". It's a bit disorganised. Go ahead and contribute. Cause I hardly know anything about Linux.

 

http://en.wikipedia.org/wiki/Linux_color_management

[serge c]

"...In Ubuntu LUTs were loaded on Gnome startup..." - via Xcalib. The profile itself had to be transferred to Linux using my mp3 player cause it's a FAT32 drive. I suppose there's a better way of doing it.

[eugene_scherba]

You Da Man Serge. I am editing the Wiki right now.

[serge c]

Thanks man. Just 3 weeks ago I thought Linux was hopelessly uncolormanaged. Now I see that there's a reasonably easy way to set up a colormanaged workflow. The main problem is that there are very few colormanaged Linux applications.

 

For me to have Bibble Pro in the colormanaged apps list is a huge advantage. Once you have Bibble and Noise Ninja working you are on a very solid ground professionally.