On Tuesday 25 May 2004 02:28, Kai-Uwe Behrmann wrote: > Am 24.05.04, 10:58 -0700 schrieb Troy Wu: > > > Unfortunately, being able to measure output values only solves half the > > problem. For a full color-correction workflow, I need to be able to > > soft-proof, which requires that my monitor is profiled and calibrated. > > To do so requires a colorimeter--or spectrophotometer--which can be used > > by Linux. > > It seems to be the only possiblity at the moment to use the wine emulator, for running calibration applications.
This is true but you also need every part of the work flow to be color aware or at the very least have software that implements the various manipulations needed. For example in Windows I am using the SilverFast software for my film scanner front end. In SilverFast there is a color management dialog in Preferences that allows me to specify my CM workflow for scanner operations. So I can specify my scanner device profile, my working space profile and other information about my workflow. Then when I scan an image the result is a file that has been scanned, then characterized with the scanner profile and then tranformed to my working space profile. What I get in PhotoShop is a correctly characterized scan already converted to my working color space. So once this is setup I don't even have to think about it. LCMS will let me do the characterization and transformation steps but it does require additional steps on my part for every image I scan. If your scanner is supported by VueScan, one of my is and one is not, then you can have similar facilities in Linux. But as nice as VueScan is it is not open source. In Windows the CM workflow is fragmented and in order to implement a working CM workflow the user must enter configuration information in a number of different places. For each input device front end, in the image editing software and in the printer driver for each paper/ink/resolution. This fragmentation makes this a difficult task for many users mostly because it is difficult to pull up configuration information for the workflow in one location and it is therefore difficult for the user to visualize the overall process. For the user with color management experience who understands how this works and where all of the pieces are it is manageable. But the learning curve is significant and learning about color management and how to configure it at the same time has a very steep learning curve. This ignores the additional problems involved in characterization of the devices used in the workflow - cameras, scanners, displays and printers. At least in Windows the software and hardware to do the characterization of these devices exists. But even with these characterization facilities this can be an expensive and difficult task. Display and print systems are particularly difficult to characterize. Characterization of scanners and cameras is a relatively simple task in Windows and should be in Linux as well. > It seems to be the only possiblity at the moment to use the wine emulator, for running calibration applications. One other point about the characterization process. This process REQUIRES that every part of the chain involved be EXACTLY the same when doing the characterization as it will be in actual use. For example when profiling a printer you must so everything exactly the same when printing your target as you will during your normal workflow other than selecting a printer profile ie there is no transformation between color spaces. So everything matters; driver settings (resolution, paper type, dithering...), paper, ink - everything. So using wine will work for the characterization of scanners, cameras and printers since the normal Linux workflow can be used to capture/print the target and the Windows software is only being used to generate the profile from the captured data. But LCMS will handle this so there is no need for wine to profile cameras, scanners and printers (maybe not printers). But I have serious reservations about doing this with displays because there will be an added Windows software layer in the display chain during the capture of the raw characterization data that could, very likely does, alter how colors are displayed. This will result in the generated profile being incorrect or more to the point only correct for software running under wine. The GIMP only needs slight changes to make it a usable, not ideal but usable, part of a CM workflow. It currently has a color proof display filter that allows the user to select a ICC profile for soft proofing. I belive that they have used LCMS to implement this feature. All it needs is the same feature for a display color space profile, the ability to use the images embedded profile and the ability to apply a user selected profile to an image on its way to a printer. These changes would make The GIMP usable in the short term until a more comprehensive open source system wide CM system is in place. I like Bob Friedenhahn's idea of having one place that contains all of the CM configuration data. However, I think the correct generalization would be to allow sections for multiple display devices, multiple input devices and multiple printers/output devices. After all how many of you only have one scanner/camera or one printer. Bob's spec handles multiple display devices. The names of the sections would be the same as those used by the software that controls the device. So the display section names would be the same as the display names in FX86config. The config software for each device would read/update this file in it's color management dialog and the driver/editing software would read this file to implement it's color management processes. In addition this config file could/should contain CM workflow related information not just characterization information. This is a significant and logical extension of Bob's idea. But it is also non-trivial and might better be left as a "phase 2" item. Since having all the system CM characterization configuration data in one place is a huge step forward and is a significant improvement over Windows. Anyone here worked with CM on the Mac? How is this handled there? Perhaps there are best practices and things to avoid that can be learned from the Mac that should be applied to the open source world. As to the performance of LCMS. I personally am not concerned that it might be a little slow. What matters at this point is that it has a well designed api and that it works. Performance issues can be corrected over time. On my list of things that need to be done for CM on open source platforms this is near the bottom of the list. First get things working then make them perform better. LCMS works we need to get the other parts of CM working. -- Hal V. Engel
pgpTUmjX2K1CQ.pgp
Description: signature
