Linux users rejoice!

Discussion in 'Digital Darkroom' started by eugene_scherba, Jul 20, 2006.

  1. It is now possible to fully calibrate a monitor for Linux!
    The catch is that you still need Windows to run the hardware calibrator. I am writing this in the light of the recent thread here 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 xcalib. 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.
    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.
    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).
    00HMf8-31289584.jpg
     
  2. 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).
     
  3. trw

    trw

    Gimp still can't handle colour management or 16 bit files, but CinePaint can.
     
  4. 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.
    I wish Cinepaint's development was as active as the GIMP's, then one would have a real alternative to PS.
     
  5. 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
     
  6. 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.
     
  7. Eugene,

    Your upper data sheet shows a luminance of 72 vs a target of 100. How old is your CRT monitor ?
     
  8. 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?
     
  9. 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
     
  10. 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.
     
  11. 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.
     
  12. 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?
     
  13. The lack of initiative and imagination of the Gimp developers is truely breathtaking.
    Paychecks tend to motivate developers.
     
  14. 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.
     
    1. Either download a precompiled binary from http://www.etg.e-technik.uni-erlangen.de/web/doe/xcalib/ or download and unpack the sources.

    2. Put the binary file in /usr/local/bin/. If compiling from source, simply type on the command line while in the source directory:

      make
      su
      make install
    3. Put the following lines in your /etc/X11/xinit/xinitrc file:

      # Monitor calibration loader
      /usr/local/bin/xcalib /path/to/your/monitor_profile.icc

      (just don't forget to replace "/path/to/your/monitor_profile.icc" with the full path to your ICC profile)

    4. If for whatever reason you want to undo the effect of loading a profile, type:

      xcalib -clear

    5. If everything's working, send a postcard to Stefan.
     
  15. 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?
     
  16. 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...
     
  17. "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
     
  18. ...seems to come with at least a dozen text editors, 3 or 4 of which are derivatives of VI.
    Hey, don't knock vi; I use it on a daily basis. What more could you want from a text editor! ;)
     
  19. "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
     
  20. 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...
     
  21. Take a look at this editor PIXEL:
    http://www.kanzelsberger.com/pixel/
     
  22. 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
     
  23. Picture Window can run on Linux using WINE (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.
     
  24. have you tested it with a profile that uses LUTs (without using monitor buttons) to achieve a significantly different target (like 5000K)?>
    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).
    00HN4f-31302784.jpg
     
  25. Okay, apparently it does support LUTs. Below is a quote from README documentation:
    last parameter MUST be an ICC profile containing a vcgt or mLUT tag.
     
  26. 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.
     
  27. Serge, check out Stefan's README 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.
    Attached is a README.profilers file which compares how different calibrators embed the data in the profile.
     
  28. 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.
     
  29. They are not the hackerly coding samurai of the previous generation.
    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'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.
     
  30. Scott, let's keep your sarcasm elsewhere.
     
  31. Krita is worth a look:

    http://www.koffice.org/krita
     
  32. "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.
     
  33. 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
     
  34. Serge, I agree with everything you said, but like I said, I'm lazy.
    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).
    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.
    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).
    Sometimes it is better to just trust me on how I am running my boxes, heh.
     
  35. 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).
     
  36. 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.
     
  37. Scott Eaton wrote:
    "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"."
    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.
     
  38. 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
     
  39. Thanks Serge, I'll read into that discussion later on.
     
  40. 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.
     
  41. 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
     
  42. So is dispwin 16- or 8-bit? Does it matter anyways, since all
    display output from the operating system is 8-bit?
     
  43. 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.
    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.
    A quote from xcalib documentation: Under Linux we cannot set the video-LUT itself but a X-server gamma ramp (which does practically the same). 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.
     
  44. 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...
     
  45. 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
     
  46. "...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.
     
  47. You Da Man Serge. I am editing the Wiki right now.
     
  48. 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.
     

Share This Page