I have a GretagMacbeth eye-one display2 monitor calibrator.
Can LPROF operate calibrator devices?
I've made my LCD's ICC profile on Windows2000, and applied it with xcalib on Linux. But it's immediately broken by opening the tab of KDE's kcontrol-display.
Is there any information for the firm environment of X's colormanagement?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
LProf currently does not have direct support for any color measurement devices. I am however working with GMB on making the interface code for the EyeOne devices available for Linux and other POSIX environments (Unix, *BSD). The code already exists internally but has never been made available to anyone outside of GMB. I should add that so far the progress has been painfully slow and I don't have a time table at this point.
Although I do expect this to take a while to filter down to users I should have the interface code for the development work sometime soon and I have a EyeOne Display LT (same hardware as the Display 2 but with less features in the MGB software) that I will be using to develop the support modules for the EyeOne. The device was purchased in part with funds that were donated to the project by a supporter. The resulting code should work for any and all EyeOne devices (diskplay 1, 2, LT and Pro). So the simplified answer is not now but it is coming.
The second question is not so easy to answer. There is work underway on incorporating color management into X and other OSS applications (GIMP, Gutenprint, Hugin and CUPS) and some OSS applications already have fairly extensive color management support (CinePaint, Scribus, Krita, GraphicMagick, ImageMagick and enblend).
With respect to X this is still in the very early stages and the major thing that is slowing this down is the lack of people working on various parts of the effort. For the most part this work is being done by single individuals working alone. There are specifications for some significant parts of this and a number of projects are underway. The best place to find information is http://www.freedesktop.org/wiki/OpenIcc . Probably the single most relevent project in this regard (X specific) is Oyranos which is linked from the above web page. Also if you are interested you should subscribe to the OpenICC email list. Activity there runs hot and cold and you may want to also have a look at the archives.
With regard to using profiles generated in Windows on Linux. My feeling is that this may be better than not using anything but that over all you will not get the correct results. Remember that when you calibrate and profile a device you are characterizing (profiling) the whole processing chain of that device. This includes any software in that processing chain such as the display drivers which are different on Windows and Linux. That being said I do think that the display calibration where you set the monitor gain (contrast), black point (brightness) and white point (color temperature) in Windows using the EyeOne (or any device) is also good for the same machine booted to Linux since it brings the monitors base characteristics into a known and correct calibrated state.
You should open a bug report with the KDE folks about the issue with kcontrol-display resetting the video card gamma. It should not do this or it should have a dialog (tab?) that allows users to control how it does this. But I suspect that what it is doing is looking that the default gamma correction for X and resetting your card to the values that correspond to that setting.
What you should take away from this is that there is lots of work being done but that much more remains to be done and things are not moving as fast as any of us would like. If you or anyone reading this would like to help with this effort in any way please volunteer for one of these projects. Any of these projects (including LProf) can use just about any type of help including programmers, subject matter experts, documentation writers, usability experts, translators, testers and a whole lot of other skills. So you don't need to be technical to help with this effort.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>So the simplified answer is not now but it is coming.
I hope ,if available, all the matter goes faster. GMB marged with US.Xlite. So I'm afraid of their product lineups confusion. But it's nice to me or other users that the driver already exists and works on hardware actually.
It's the rare case, and I fear it's the only one chance the colormeter driver was made for Linux.
In the circumstances of Japanese market, compact digicams market crossed a ridge last year. The manufacturers sift to DSLR, struggling to escape from the market shrink. I don't know GMB came just in time.
So far as I know, DCraw and UFraw can handle ICC profile well. I haven't gotten a good result from Cinepaint. But I didn't know the other softwares. thanks for your information.
>This includes any software in that processing chain such as the display drivers which are different on Windows and Linux.
I felt subtle differences of color in spite of the same manufacturer's driver,it's Nvidia.
It's difficult to explain without the digital measurement. I don't have scanners. also Canon doesn't provide CUPS driver for my IP90 mobile printer (some other models available).
>I suspect that what it is doing is looking that the default gamma correction for X and resetting your card to the values that correspond to that setting.
Maybe. KDE developers may deny the bug report. I may try to demand improvements of the issues.
Forgive me for the repeat,I wish you approach GMB to quicken the release of *nix driver.
Since GMB leaves Huey sales to the dealer in Japan, I(We) cannot hope for any helps for Linux.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No the LT is not the same as the Huey. At this time there is no *nix interface/driver for the Huey. I don't know if it will ever exist or even if they are working on it. If this ever does exist I will add support to LProf. The EyeOne Display LT is EXACTLY the same hardware as the Display 2 except that the profiling software from GMB gets the model information from the device and works with a reduced set of features if it sees an LT instead of a 1 or 2.
3rd party software is able to implement any set of features that work on a Display 2 on the LT. Also the same interface/driver will work for any EyeOne model including the Display 1, 2. LT and Pro. The Pro will have more features because it is a true spectrophotometer and does both emissive and reflective measurements. The Display 1, 2 and LT will all have the same feature set availble to 3rd party software such as LProf.
The merger is not yet finalized at this time and we do not yet know what will happen to the model lines of these vendors. If anything X-Rite is more open to OSS projects than is GMB and things have been moving alone a little better since the merger was announced. I was some what surprised by this.
Also I suspect that at least the Huey will live on after the merger since it is at a price point that is well below (65% lower) anything in the X-Rite line up and therefore opens up a whole new and untapped market segment. Even the EyeOne LT is significantly less costly (about 40% cheaper) than anything that X-Rite offers and I have seen these advertised for as little as $100 here in the US. But these are more typically in the $130 to $140 range in the US. List is $169.
I don't think DCRAW has direct support for ICC profiles. UFRAW does and it has a basic but well thought out and functional interface for using ICC profiles. In the help files for LProf there is a fairly detailed tutorial on how to create profiles for UFRAW.
Even though the display drivers on Windows and Linux are both from nVidia (I also have an nVidia card) they are different if for no other reason then that they are designed to work with different window managers and OS's. I found that getting the monitor setting correct using the LT and GMB software on Windows did improve things in Linux simply because the white point, black point and gain of the monitor hardware were now (much closer to) correct. Even at that there are differences in how the diplay drivers render things in Windows and Linux. In both environments I have my screen background set to a true gray color (R=G=B) and both are very neutal now. The main differnce is that I am now using the new Windows Color Control panel applet that (finally) allows me to setup different profiles for each display in my dual screen setup and as a result both screen are a closer match than they are on Linux. If you have a multi-screen setup on Windows this applet is a must have.
I am pushing GMB as hard as I can. I think that one issue is that there are lawyers involved in the process on their end. Only a few weeks ago I finally got a verbial commitment from someone near the top of the food chain at GMB to make the EyeOne *nix interface/driver availble but I know that they have a lot of details to work out. Some of these are technical, some are legal and I suspect that there are concerns about support and marketing as well. This is hugely different from supporting interfaces/drivers for closed systems like Windows or the Mac and I suspect that they are struggling with a bunch of issues that are new to them.
Also I encourage those interested in using any of the EyeOne devices to contact GMB support so that they know there are folks interested in the *nix interface/drivers.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Most of camera users in Japan make efforts to be blind to the US price, since sometimes they go insane after they see it. I don't want to say how much I paied for my display2...sigh.
>I suspect that they are struggling with a bunch of issues that are new to them.
I see. To say the truth, I've not have much idea.
They would like to avoid labor because of the market volume...so The marger was the correct answer...
maybe it's an easy way to unveil the API to volunteers. The sensor precision is secret?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think this is true for many countries besides Japan. I know that in Australia Display 2s are $300 to $500 US (round numbers) depending on the retailer. I suspect that there are a number of factors. First the US is a much larger and more competitive market. And I think an even bigger factor is that the US has lower taxes than much of the rest of the world which has a direct impact on retail prices (and the level of liberty). As an interesting side note I know that the wholesale cost of Display 2s in Australia (US $178) is about 30% below US retail (US $249). So I don't think I understand why prices there are so high. How much of this mark up is taxes?
Both companies involved in the merger are very profitable. Their press release about the merger said that they expected that the combined company would has a net profit margin of around 60%. The company that I am retired from had a net profit margin of about 10% most years and most companies, at least in the US, operate on margins in the 10% to 20% range. So 60% is very high.
I suspect that the issues are more around licensing, distribution and support. For example currently to get the header files needed to build an application that uses the EyeOne API you must go through the process to get the SDK. This takes several weeks and requires a signed agreement. Not very practical for OSS software like LProf since each person building it (most users) would have to go through this process. Again I have verbal assurances that this will be changed and that the header files will be made publicly available. The SDK also contains the interface and driver binaries (not sure why since these come with the device and can be downloaded separately) and some documentation. Since Linux users will also need the interface/driver binaries they will need to make these publicly available for a number of different architectures. Therefor after the public release of the header files and the Linux binaries the only thing that is unique to the SDK will be the documentation. If I were doing this I would unbundle the SDK into three separate sets of downloads. One would be for the interface libraries (by OS and arch). Second would be the header files and then a third download area for the SDK documentation. But I don't know how GMB will structure all of this.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
LProf from CVS does not have scons-local. The README has this documented but most users seems to miss this. Normally we would expect that those using CVS will be developers but the changes that are in CVS are ones that users are very much interested in. Unfortunately there is a lot of work that needs to be done before these will be released in a tarball and I expect that many users will be building from CVS until this is far enough along that it is ready for release.
You can get a copy of scons-local from the scons web site. Just untar the scons-local tarball in the root of the lprof source tree. As long as you has python install (all modern linux distros do) you can then follow the build instructions in the README. This build has been tested with a number of scons versions including 0.97 (latest from scons site). There are some versions of scons that do NOT work these are documented in the README.
There are a number of SuSE users that I know have built LProf so if you have scons installed and it is a know good version. The you don't need to use:
python scons.pt ...
Rather just invoke scons like this:
scons PREFIX=/usr ....
For most users all you need to do is set the PREFIX which defaults to /usr/local
from the build directory you can run it like this
build/linux/lprof
before installing it on your system. To install lprof:
scons install
to remove the installed lprof
scons -c install
There are also some specific instructions in the README for building this on a SuSE machine.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm sorry that I changed my PC system in June to SMP and VM formation in order to use film scanner,photo printer and eye-one.(and to escape from noisy circumstances by TDP45W CPU)
I have tried using a EyeOne Display the other way around. That is running it in a virtual (VMWare) Windows session on a Linux machine using the vendors software. It did not work but it got farther than you are getting. It would get to the point where it tried to save the profile and it would crash. I am not too optimistic about getting this working in a visualized session. On the Linux side do you have authority to access the USB ports? Also did you install the vendors Windows drivers for the EyeOne? If you did then this would likely be an issue for the virtual session.
Since you are on a supported OS why not run LProf natively? Our Google Summer of Code student is using a Windows machine and has put a MSVS 2005 Express solution in CVS that should only need minor tweaks for others to get this to build. But as far as I know no one else has tested this so it could be a difficult slog to get it to work since you also have to build a bunch of other software to get LProf to build and link. This has not been documented yet which is another complication. He has been focused on things other than the meter related code* and there is currently no documentation for setting up a USB color meter on Windows which is more difficult than on newer *nix machines. This is also untested at this time on Windows but it should run once it is setup. I should add that I have found this MUCH more difficult to build on Windows than on a *nix box. I expect that we will start making Windows binaries of CVS snapshots available in a few weeks for selected users to start testing.
One of our other developers is likely going to work on getting the scons build working on Windows sometime soon. When this is in place users will be able to build this with mingw and I think it will be a little easier build for users than using the microsoft tools.
I guess that I should make it clear that LProf does NOT use the vendors EyeOne drivers/interface libraries as they have refused to make these available for any OS's other than Windows and OS/X. In addition, there are licensing restrictions in the SDK agreement that effectively preclude making calls to the vendors interface libraries in any open source software by placing distribution restrictions on the calling code. About a year ago (May 13, 2006 to be exact) I was told by their management that this was inadvertent and that they would remove the clause in the agreement that was causing this issue but this has not happened yet. LProf is using the ArgyllCMS meter libraries which work on *nix, OS/X and Windows.
PS: I will be traveling over the next two weeks and will have limited access to the net during that time.
* The GSoC student just pushed some changes into CVS to support the HutchColor target (HCT) (tm). Over the next month or so he should be getting support for ColorChecker SG (tm) and ColorChecker DC (tm) targets in place as well. The current code base supports the ColorChecker (tm) 24 patch targets. So LProf now supports five of the seven available profiling targets and should support all of them soon.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Idon't know why.
1.Windows starts.
2.VirtualBox starts without physical connection of eye-one.
3.connect eye-one and load on VB as a new USB device.
4.command lsusb...there's eye-one present.
5.LProf starts and recognizes eye-one.
6.calibration starts ...and LProf crashes...
I could calibrated my display with LProf with root permission.
I made one more profile that was darker(gumma 1.5) than the first correct one,
and applied it with xcalib...nothing happened.
I expected my display window was darkened.
It seems Virtual video card of VirtualBox is not independent of Windows driver control.
Of course,I know it'll be enough that I can see the same color in the Linux box as Windows vista shows.
Since I can proof the retouched photos profiles on such device profile made in Windows vista.
I think I can use Lprof for matching scanner or printer.
Windows vista said "it has no tags related to Nividia 6200" (in japanese) as I would apply the trial profile above. What is lucking for? xcalib doesn't discriminate.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have not worked with Vista at all so I don't know what it wants as this relates to setting the video card gamma table. I do know that the video drivers are way different than they were for XP because of the DRM (Digital Restriction Management) stuff. But I am not sure that this has anything to do with the "..no tags.." error message.
Regardless of how LProf is being run you should be able to use it to create scanner and camera profiles since these are completely independent from the OS unlike video related stuff (calibration being the main issue). That is a scanner profile created by LProf running on Linux (for example) or a virtual Linux session that is for a Windows connected scanner will work as long as the same work flow and software that were used to capture the profiling target are used when the profile is applied.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have a GretagMacbeth eye-one display2 monitor calibrator.
Can LPROF operate calibrator devices?
I've made my LCD's ICC profile on Windows2000, and applied it with xcalib on Linux. But it's immediately broken by opening the tab of KDE's kcontrol-display.
Is there any information for the firm environment of X's colormanagement?
LProf currently does not have direct support for any color measurement devices. I am however working with GMB on making the interface code for the EyeOne devices available for Linux and other POSIX environments (Unix, *BSD). The code already exists internally but has never been made available to anyone outside of GMB. I should add that so far the progress has been painfully slow and I don't have a time table at this point.
Although I do expect this to take a while to filter down to users I should have the interface code for the development work sometime soon and I have a EyeOne Display LT (same hardware as the Display 2 but with less features in the MGB software) that I will be using to develop the support modules for the EyeOne. The device was purchased in part with funds that were donated to the project by a supporter. The resulting code should work for any and all EyeOne devices (diskplay 1, 2, LT and Pro). So the simplified answer is not now but it is coming.
The second question is not so easy to answer. There is work underway on incorporating color management into X and other OSS applications (GIMP, Gutenprint, Hugin and CUPS) and some OSS applications already have fairly extensive color management support (CinePaint, Scribus, Krita, GraphicMagick, ImageMagick and enblend).
With respect to X this is still in the very early stages and the major thing that is slowing this down is the lack of people working on various parts of the effort. For the most part this work is being done by single individuals working alone. There are specifications for some significant parts of this and a number of projects are underway. The best place to find information is http://www.freedesktop.org/wiki/OpenIcc . Probably the single most relevent project in this regard (X specific) is Oyranos which is linked from the above web page. Also if you are interested you should subscribe to the OpenICC email list. Activity there runs hot and cold and you may want to also have a look at the archives.
With regard to using profiles generated in Windows on Linux. My feeling is that this may be better than not using anything but that over all you will not get the correct results. Remember that when you calibrate and profile a device you are characterizing (profiling) the whole processing chain of that device. This includes any software in that processing chain such as the display drivers which are different on Windows and Linux. That being said I do think that the display calibration where you set the monitor gain (contrast), black point (brightness) and white point (color temperature) in Windows using the EyeOne (or any device) is also good for the same machine booted to Linux since it brings the monitors base characteristics into a known and correct calibrated state.
You should open a bug report with the KDE folks about the issue with kcontrol-display resetting the video card gamma. It should not do this or it should have a dialog (tab?) that allows users to control how it does this. But I suspect that what it is doing is looking that the default gamma correction for X and resetting your card to the values that correspond to that setting.
What you should take away from this is that there is lots of work being done but that much more remains to be done and things are not moving as fast as any of us would like. If you or anyone reading this would like to help with this effort in any way please volunteer for one of these projects. Any of these projects (including LProf) can use just about any type of help including programmers, subject matter experts, documentation writers, usability experts, translators, testers and a whole lot of other skills. So you don't need to be technical to help with this effort.
Thanks a lot for your very kindly explanation.
Your model LT is the same to this?
http://www.koyoshagraphics.com/huey/
This was cast in the market of Japan just a month ago.
>So the simplified answer is not now but it is coming.
I hope ,if available, all the matter goes faster. GMB marged with US.Xlite. So I'm afraid of their product lineups confusion. But it's nice to me or other users that the driver already exists and works on hardware actually.
It's the rare case, and I fear it's the only one chance the colormeter driver was made for Linux.
In the circumstances of Japanese market, compact digicams market crossed a ridge last year. The manufacturers sift to DSLR, struggling to escape from the market shrink. I don't know GMB came just in time.
So far as I know, DCraw and UFraw can handle ICC profile well. I haven't gotten a good result from Cinepaint. But I didn't know the other softwares. thanks for your information.
>This includes any software in that processing chain such as the display drivers which are different on Windows and Linux.
I felt subtle differences of color in spite of the same manufacturer's driver,it's Nvidia.
It's difficult to explain without the digital measurement. I don't have scanners. also Canon doesn't provide CUPS driver for my IP90 mobile printer (some other models available).
>I suspect that what it is doing is looking that the default gamma correction for X and resetting your card to the values that correspond to that setting.
Maybe. KDE developers may deny the bug report. I may try to demand improvements of the issues.
Forgive me for the repeat,I wish you approach GMB to quicken the release of *nix driver.
Since GMB leaves Huey sales to the dealer in Japan, I(We) cannot hope for any helps for Linux.
No the LT is not the same as the Huey. At this time there is no *nix interface/driver for the Huey. I don't know if it will ever exist or even if they are working on it. If this ever does exist I will add support to LProf. The EyeOne Display LT is EXACTLY the same hardware as the Display 2 except that the profiling software from GMB gets the model information from the device and works with a reduced set of features if it sees an LT instead of a 1 or 2.
3rd party software is able to implement any set of features that work on a Display 2 on the LT. Also the same interface/driver will work for any EyeOne model including the Display 1, 2. LT and Pro. The Pro will have more features because it is a true spectrophotometer and does both emissive and reflective measurements. The Display 1, 2 and LT will all have the same feature set availble to 3rd party software such as LProf.
The merger is not yet finalized at this time and we do not yet know what will happen to the model lines of these vendors. If anything X-Rite is more open to OSS projects than is GMB and things have been moving alone a little better since the merger was announced. I was some what surprised by this.
Also I suspect that at least the Huey will live on after the merger since it is at a price point that is well below (65% lower) anything in the X-Rite line up and therefore opens up a whole new and untapped market segment. Even the EyeOne LT is significantly less costly (about 40% cheaper) than anything that X-Rite offers and I have seen these advertised for as little as $100 here in the US. But these are more typically in the $130 to $140 range in the US. List is $169.
I don't think DCRAW has direct support for ICC profiles. UFRAW does and it has a basic but well thought out and functional interface for using ICC profiles. In the help files for LProf there is a fairly detailed tutorial on how to create profiles for UFRAW.
Even though the display drivers on Windows and Linux are both from nVidia (I also have an nVidia card) they are different if for no other reason then that they are designed to work with different window managers and OS's. I found that getting the monitor setting correct using the LT and GMB software on Windows did improve things in Linux simply because the white point, black point and gain of the monitor hardware were now (much closer to) correct. Even at that there are differences in how the diplay drivers render things in Windows and Linux. In both environments I have my screen background set to a true gray color (R=G=B) and both are very neutal now. The main differnce is that I am now using the new Windows Color Control panel applet that (finally) allows me to setup different profiles for each display in my dual screen setup and as a result both screen are a closer match than they are on Linux. If you have a multi-screen setup on Windows this applet is a must have.
I am pushing GMB as hard as I can. I think that one issue is that there are lawyers involved in the process on their end. Only a few weeks ago I finally got a verbial commitment from someone near the top of the food chain at GMB to make the EyeOne *nix interface/driver availble but I know that they have a lot of details to work out. Some of these are technical, some are legal and I suspect that there are concerns about support and marketing as well. This is hugely different from supporting interfaces/drivers for closed systems like Windows or the Mac and I suspect that they are struggling with a bunch of issues that are new to them.
Also I encourage those interested in using any of the EyeOne devices to contact GMB support so that they know there are folks interested in the *nix interface/drivers.
Most of camera users in Japan make efforts to be blind to the US price, since sometimes they go insane after they see it. I don't want to say how much I paied for my display2...sigh.
>I suspect that they are struggling with a bunch of issues that are new to them.
I see. To say the truth, I've not have much idea.
They would like to avoid labor because of the market volume...so The marger was the correct answer...
maybe it's an easy way to unveil the API to volunteers. The sensor precision is secret?
I think this is true for many countries besides Japan. I know that in Australia Display 2s are $300 to $500 US (round numbers) depending on the retailer. I suspect that there are a number of factors. First the US is a much larger and more competitive market. And I think an even bigger factor is that the US has lower taxes than much of the rest of the world which has a direct impact on retail prices (and the level of liberty). As an interesting side note I know that the wholesale cost of Display 2s in Australia (US $178) is about 30% below US retail (US $249). So I don't think I understand why prices there are so high. How much of this mark up is taxes?
Both companies involved in the merger are very profitable. Their press release about the merger said that they expected that the combined company would has a net profit margin of around 60%. The company that I am retired from had a net profit margin of about 10% most years and most companies, at least in the US, operate on margins in the 10% to 20% range. So 60% is very high.
I suspect that the issues are more around licensing, distribution and support. For example currently to get the header files needed to build an application that uses the EyeOne API you must go through the process to get the SDK. This takes several weeks and requires a signed agreement. Not very practical for OSS software like LProf since each person building it (most users) would have to go through this process. Again I have verbal assurances that this will be changed and that the header files will be made publicly available. The SDK also contains the interface and driver binaries (not sure why since these come with the device and can be downloaded separately) and some documentation. Since Linux users will also need the interface/driver binaries they will need to make these publicly available for a number of different architectures. Therefor after the public release of the header files and the Linux binaries the only thing that is unique to the SDK will be the documentation. If I were doing this I would unbundle the SDK into three separate sets of downloads. One would be for the interface libraries (by OS and arch). Second would be the header files and then a third download area for the SDK documentation. But I don't know how GMB will structure all of this.
Just a quick update. LProf CVS now has support for the EyeOne meters (all of them).
Thank you for your information.
I read README.
But I cannot find scons.py or scons-local from either openSuse scons rpmPKG or lprof CVS copies.
>pine@pine-Linux:~/xx_data/xx_app/LProf/lprof> python scons.py -c install
>python: can't open file 'scons.py': [Errno 2] No such file or directory
LProf from CVS does not have scons-local. The README has this documented but most users seems to miss this. Normally we would expect that those using CVS will be developers but the changes that are in CVS are ones that users are very much interested in. Unfortunately there is a lot of work that needs to be done before these will be released in a tarball and I expect that many users will be building from CVS until this is far enough along that it is ready for release.
You can get a copy of scons-local from the scons web site. Just untar the scons-local tarball in the root of the lprof source tree. As long as you has python install (all modern linux distros do) you can then follow the build instructions in the README. This build has been tested with a number of scons versions including 0.97 (latest from scons site). There are some versions of scons that do NOT work these are documented in the README.
There are a number of SuSE users that I know have built LProf so if you have scons installed and it is a know good version. The you don't need to use:
python scons.pt ...
Rather just invoke scons like this:
scons PREFIX=/usr ....
For most users all you need to do is set the PREFIX which defaults to /usr/local
from the build directory you can run it like this
build/linux/lprof
before installing it on your system. To install lprof:
scons install
to remove the installed lprof
scons -c install
There are also some specific instructions in the README for building this on a SuSE machine.
I'm sorry that I changed my PC system in June to SMP and VM formation in order to use film scanner,photo printer and eye-one.(and to escape from noisy circumstances by TDP45W CPU)
Virtual machine cannot connect eye-one to the guest Linux system.
http://www.pine-kz.com/_test/snapshot3.png
I asked a question...
http://forums.virtualbox.org/viewtopic.php?t=700
I have tried using a EyeOne Display the other way around. That is running it in a virtual (VMWare) Windows session on a Linux machine using the vendors software. It did not work but it got farther than you are getting. It would get to the point where it tried to save the profile and it would crash. I am not too optimistic about getting this working in a visualized session. On the Linux side do you have authority to access the USB ports? Also did you install the vendors Windows drivers for the EyeOne? If you did then this would likely be an issue for the virtual session.
Since you are on a supported OS why not run LProf natively? Our Google Summer of Code student is using a Windows machine and has put a MSVS 2005 Express solution in CVS that should only need minor tweaks for others to get this to build. But as far as I know no one else has tested this so it could be a difficult slog to get it to work since you also have to build a bunch of other software to get LProf to build and link. This has not been documented yet which is another complication. He has been focused on things other than the meter related code* and there is currently no documentation for setting up a USB color meter on Windows which is more difficult than on newer *nix machines. This is also untested at this time on Windows but it should run once it is setup. I should add that I have found this MUCH more difficult to build on Windows than on a *nix box. I expect that we will start making Windows binaries of CVS snapshots available in a few weeks for selected users to start testing.
One of our other developers is likely going to work on getting the scons build working on Windows sometime soon. When this is in place users will be able to build this with mingw and I think it will be a little easier build for users than using the microsoft tools.
I guess that I should make it clear that LProf does NOT use the vendors EyeOne drivers/interface libraries as they have refused to make these available for any OS's other than Windows and OS/X. In addition, there are licensing restrictions in the SDK agreement that effectively preclude making calls to the vendors interface libraries in any open source software by placing distribution restrictions on the calling code. About a year ago (May 13, 2006 to be exact) I was told by their management that this was inadvertent and that they would remove the clause in the agreement that was causing this issue but this has not happened yet. LProf is using the ArgyllCMS meter libraries which work on *nix, OS/X and Windows.
PS: I will be traveling over the next two weeks and will have limited access to the net during that time.
* The GSoC student just pushed some changes into CVS to support the HutchColor target (HCT) (tm). Over the next month or so he should be getting support for ColorChecker SG (tm) and ColorChecker DC (tm) targets in place as well. The current code base supports the ColorChecker (tm) 24 patch targets. So LProf now supports five of the seven available profiling targets and should support all of them soon.
Today I took a step foword.
http://www.pine-kz.com/_test/snapshot4.png
Idon't know why.
1.Windows starts.
2.VirtualBox starts without physical connection of eye-one.
3.connect eye-one and load on VB as a new USB device.
4.command lsusb...there's eye-one present.
5.LProf starts and recognizes eye-one.
6.calibration starts ...and LProf crashes...
http://www.pine-kz.com/_test/snapshot5.png
I could calibrated my display with LProf with root permission.
I made one more profile that was darker(gumma 1.5) than the first correct one,
and applied it with xcalib...nothing happened.
I expected my display window was darkened.
It seems Virtual video card of VirtualBox is not independent of Windows driver control.
Of course,I know it'll be enough that I can see the same color in the Linux box as Windows vista shows.
Since I can proof the retouched photos profiles on such device profile made in Windows vista.
I think I can use Lprof for matching scanner or printer.
Windows vista said "it has no tags related to Nividia 6200" (in japanese) as I would apply the trial profile above. What is lucking for? xcalib doesn't discriminate.
I have not worked with Vista at all so I don't know what it wants as this relates to setting the video card gamma table. I do know that the video drivers are way different than they were for XP because of the DRM (Digital Restriction Management) stuff. But I am not sure that this has anything to do with the "..no tags.." error message.
Regardless of how LProf is being run you should be able to use it to create scanner and camera profiles since these are completely independent from the OS unlike video related stuff (calibration being the main issue). That is a scanner profile created by LProf running on Linux (for example) or a virtual Linux session that is for a Windows connected scanner will work as long as the same work flow and software that were used to capture the profiling target are used when the profile is applied.