I got the link for ColorNavigator 7 from EIZO Suport a year ago. Supposedly runs on Red Hat Enterprise Linux 7 . If someone could make a version for Ubutnu 20.04, I would be very grateful.
https://drive.google.com/file/d/14lFG-MHPu0q1lohbZv4rDQ_YMnLEcHvw/view?usp=sharing
Eizo is free but it will work only with Eizo monitors.
For Eizo better to have X-Rite Display Pro than Spyder since Eizo color accuracy is better than Spyderâs accuracy.
Ask for Eizo representative in your country to provide you the link to CN7.
RH is only supported by Eizo butâŚ
For CN6 I just looked at the instalation scripts and mimic what they did. Some libs here, there. Nothing special. However better to just have CentOS 7 in VM for that. You got one problem less.
Plus there is the flatpack version of displaycal available now as well, which solves the issues of Python2 dependencies for distros which have removed python2 from their repositories.
I too got the link and downloaded the software.
I suspect that they donât do a lot of work on the software since some of the dependencies are fairly old, notably openSSL.
I fixed the other dependencies, but it crashes with an SSL error, âFATAL FIPS SELFTEST FAILUREâ. I suspect that it needs to be run in a VM.
Yes, thatâs what I thought⌠Thanks for the effort!
Itâs not a good idea at all to calibrate screens from within a VM. You need direct access to the GPU VCGT, at least to overwrite it for the time of the calibration. If you fail at that, you might calibrate in the VM over what the base OS is already color-correcting. Better boot in live USB or something.
(NB: itâs customary for color management systems to use the VCGT for white balance and contrast linearization).
Pierre,
For calibration with CN (same for SpectraView II by the way):
Now in VM CN has direct access to display and sends commands directly to monitor requesting to display a colored patch in the middle of the screen.
X-Rite also is directly serviced in VM and is reading just the patches from the screen.
So you bypass the whole stack and operate purely on the display.
If that doesnât work you couldnât use ICC profile prepared from others too (for instance calibrated in a professional service or shop during purchase).
I guess the difference is that you shall not profile display under VM. For calibration it is a different story since you need direct access and you purely operate on device.
I think you are mistaking a display profile with a softproofing profile. Of course, softproofing doesnât use the VCGT. But the VCGT is written on hardware (by the CMS or whatever) and applied on top of the ICC profile, so having access to display doesnât necessarily mean the VCGT is nuked to neutral.
I have no idea what really happens in VM, but thatâs definitely something to carefully check if you donât want bad surprises.
Notice itâs possible to make display profiles that donât use VCGT at all, but that doesnât guarantee that some other piece of soft is not messing up with it elsewhere (and all the redshift/night color thingy use the VCGT to change the white balance of the screen at night to preserve your sleep).
I just hope I donât but canât be really sure. 
If profiling calibrated monitor (which actually is a step in CN after calibration) produces system (PC+monitor) depended ICC profile then it negates the idea of the ICC which describes only device (here monitor) capabilities.
For calibration LUTs are written into the monitor itself by calibration software (CN) and OSD in monitor is locked so ICC describes that particular state of monitor.
Besides I can purchase verified monitor with additional services like calibration and ICC profile (also could include warming up for several days to see if display is uniform and no bad pixels appear). So services like calibration of display would also had no sense since the technician wonât install software on clientâs PC but rather use heâs own with dedicated SW.
Regarding VMs. I read that video card drivers are kind of passthru. They did not access card and change anything thus CM in Guest is not working. Host shall be CM in that case. There is a lot of questions regarding this topic to my surprise.
Maybe I could ask @gwgill for a comment here, please.
Only specialized systems have the ability to change the state of the display in hardware. General computer systems donât have this available, so they use what is available to alter the display behavior - graphics card per channel LUTs. The technical advantage is that per channel LUTs are more detailed than 3D Luts, so a display can be made to behave in a more easily/accurately characterized way. The practical aspect is that (mainly for historical reasons) typical ICC based color management systems assume relative colorimetric color conversions, so things like white point and brightness are not able to be set by the color management pipeline. So the a mechanism available for this that doesnât rely on being able to computer control a displays settings is per channel graphic card LUTs.
A further point of confusion is that the term âcalibrationâ has many meanings. Iâve explained the desktop/ICC profile system meaning above, but in other contexts (i.e. film & video) it has a different meaning. What it means there is configuring the display hardware to emulate a particular standard colorspace. For a desktop system such a calibration approach is generally a disadvantage, because it is much less flexible than a profiling approach. Using profiling your aim should be to maximize the native gamut of the display rather than restrict it to a single colorspace, so that the color management system can display any number of source (i.e. emulated) colorspaces simultaneously.
You canât assume anything about how a VM handles display values, per channel LUTs, instrument access or any number of other things that may have an impact on setting up a color managed system. You are pretty much on your own in investigating and verifying that things will work as you hope they will.
Itâs getting more and more complicated Thank you for you answer.
The original question here was if it was sane to use Color Navigator in VM since Eizo provides only RedHat support. In Linux you need USB cable so that CN can work. Thus passing USB devices (both Display and X-Rite) to VM (passthru) should result in direct access to hardware and proper calibration. In CN for Linux calibration is via USB bypassing all video stack and in particular graphics card.
In Color Navigator I change only brightness as I remember. For my purpose I use display Native color space. Thatâs it. Do I need more?
I donât have this particular knowledge but being a SW engineer I assume that USB is needed to send commands directly to displayâs firmware requesting for instance red patch, blue patch, grey patch and so on and later on to store some values in displayâs hardware and finally to block menus.
If such then VM is just a vehicle for libraries to launch properly calibration software.
Once I had dual boot to calibration but VM is far more convenient.
But in the end weâre talking here about Eizo cs/cg/cx and Color Navigator.
I would not dare to profile for instance Dell or laptop in VM. Thatâs rather not sane and unpredictable.
So I was convinced that my case was actually a calibration.
Display hardware sits behind computer hardware. So whenever you display a color patch on the display, to get a recording from your colorimeter, to later compute a deviation, your color patch goes through the OS/app CMS first (âregularâ ICC profile), then through the GPU VCGT, then through the display internal hardware (the embedded LUT), and finally to the LED panel. The USB connection is only meant to upload the LUT (computed by the software during calibration) to the monitor memory, it doesnât handle the pixels or any video signal.
So, donât expect USB cables to make things easier, video signal still goes through the HDMI pipeline (unless itâs an USB 3/Thunderbolt port that indeed can be used to send video signal, but I havenât seen any desktop monitor using that yet), and experience all the usual pipeline steps of the video signal trough all the software and hardware layers.
Hence me saying âwatch outâ with VMs. Just get a live USB system on some USB key that uses the right OS for your vendor calibrating tool, and sends video through the usual graphic stack, it will take you 30 min to setup and you will probably spare you hours of troubleshooting through opaque layers and drivers nightmares (been there, done that, not funny).
Iâm not sure. Iâm not convinced now thus I will find out
I think there is something wrong with the flatpak. I am on Debian Bullseye and here Displaycal-flatpak apparently cannot access the file system. It does no see any files, it ergo it does not see argyll, it does not see any icm or icc files, and my guess is also that it cannot save profiles that it created, and it cannot load profiles or display info about profiles. It just sees an empty home directory.
ok, just tested, it actually can save the created calibration and profile data, but in a special directory, and it can load other profiles too, if they are in that directory.
However, I have noticed that in the profile information window, color space of the selected profile cannot be compared with sRGB because sRGB is not in the list of comparison profiles, neither is AdobeRGB or other well known profiles, or at least equivalent profiles. I only see P3 and other âexoticâ comparison profiles.
@hub I guess these are âminor bugsâ that can be fixed easily? I think the possibilty to complare profiles with sRGB, medium gamut etc. is important.
Probably itâs for separate topic. However itâs a thread in this discussion.
I say that it is possible and perfectly fine to calibrate (HW calibration and verification) EIZO CS/CG/CX display from ColorNavigator running in GuestOS inside VirtualBox.
It is possible due to the fact that CN communicates with Display using USB cable. Displayed patches of color are generated directly in the device and are requested via commands sent by USB cable. Therefore it completely skips video card in Guest and Host OS (virtual and real).
Below is the process of verification of the profile in such configuration. The ICC profile is of course shared between Host and database of CN in Guest (itâs just a file somewhere in filesystem). Calibration is very similar with the exception that in the beginning one needs to set options.
So here are the screenshots from the verification process. Host: Ubuntu 20.04, Guest: CentOS 6.9 64bit.
Below you see that CN refuses to run without USB Cable attached. It was attached in Host but not passthru to Guest.
Below: I havenât verified any profile for long time.
Below: X-Rite is also passthru to Guest. Now CN has direct access to EIZO and X-Rite skipping the Host stack.
Now itâs fun. CN starts in Fullscreen mode but itâs not that easy in small desktop in Guest. I should place X-Rite where it suggest but I did not!
This is taken with smartphone! I know where the patches are going to be displayed.
This is how Host sees display during verification. It shows progress but nothing being displayed nowhere! Just a feedback that verification reached some level.
But this is how it looks like with my eyes
Of course I could not take a snapshot and take a picture at the same time so the patch number differs but it is not to cheat but for illustration.
Observations:
Conclusion:
Such calibration and verification is HW based and applies to device itself. As a result ICC profile describes this device and its characteristics.
There is no difference to between running CN inside VM and on Host directly since the key here is that in both cases the critical process is controlled out of the band (USB, not the video way).
Note:
@anon41087856 This is my way of seeing this topic and Iâm 99.9% sure itâs legitimate and correct for this case. I set my display for photo editing. In case of playing with Displayâs gamut (for video or similar) it could be different.
I hope it will be helpful for somebody.
Hi, I just bought a datacolor spyderX after quickly read that it is compatible with linux but now I am facing the same issues that you all had.
I hope that this post isnât off topic. I found this thread searching solution for these problems and after having read it all I thought that I could post my experience here.
Iâm using ubuntu 21.04 and 20.10.
As you know, the latest displaycal doesnât work due to dependencies problems.
I tried tha flatpak, it runs but it give me this error when I try to start the calibration:
I think that in the case of the flatpak version, the problem is some kind to permission to access the usb datacolor device (which is recognized fine with lsusb and in the displaycal main screen).
But other than this displaycal problem, there is another one:
I know that you can calibrate also with the gnome color manager (even if I donât know if with the same level of accuracy), but when I go to the color settings, I see that the âcalibrateâ button is grayed out due to the fact that the OS cant recognize the spyderX.
I isolated the problem as it seems that the Argyll version in the ubuntu repository doesnât recognize the spyderX, but if I try manually with the 2.2.0 downloaded from the official Argyll website, it recognizes it.
The problem is that it doesnât work âsystem wideâ with the gnome color manager and I cannot find anywhere a deb package or a repository with the latest Argyll available.
I tried to compile it manually but the instruction arenât clear enough and I donât have the needed knowledge of compilers to do it without help.
Any thoughts or suggestion to, at least, make the flatpak work?
You should be able to change the directory where the new argyll is located in the flatpak version of displaycal. I think you already did that. I am not quite sure what your question is.
You can install profiles with argyll/dispwin 2.1/2.2(?) from the terminal. Gnome color management is not necessary. Change into the argyll directory (where dispwin is located) and type dispwin -I myprofile.icc
The flatpak doesnât have problems with argyll as it is bundled with it. It is a different, permission problem, and as the flatpak runs in a sort of sandbox, it could not be fix with usual solutions.
It is the same problem as described here:
But, due to the fact that the flatpak runs in a sandbox, the fix doesnât work as expected, I think.
For color manager: I can apply different profile with it, its the gnome calibration tool that doesnât start because it doesnât recognize the spyderX, due to a too old argyll version installed.
Maybe this can help:
https://mega.nz/folder/kx40mY7J#eo_1RHHMyVL6WQTwbXZG0g 5
Itâs a live Debian Buster system with 5.9 kernel that includes Displaycal 3.8 and Argyll 2.1
The Iso is splitted in several parts since I could not upload the file in one piece.
