New ColorHug user as of today

[kirby....@myfairpoint.net]

I hope to provide a running list of observations and questions as I go. 

Observation: The letter included in the package points to http:///www.hughski.com/owner.html.  Firefox objects to the certificate it sees so relentlessly that making an exception has no effect.  Apparently the correct address is now https:///www.hughski.com/owner.html.

Note: My interest in the ColorHug was enhanced by the seeming close integration with Linux.  (Running Mint 18.3 MATE on this PC.)  I expected directions that would dive into such topics as where to put the icc profile, and how to make sure that no other icc profile was also engaged.  I am hoping at this moment that there is more of a process description buried in the live USB yet to be examined.

To be continued...

[kaseki]

USB doesn't mount but other USB devices do.  I will need a link to the live CD/DVD software to make a copy into another USB stick or CD.

[kaseki]

On Friday, March 15, 2019 at 5:04:46 PM UTC-4, kaseki wrote:

Addendum 2: The PC I'm testing on is based on a Gigabyte USB3 board running an AMD Phenom II 4 core CPU (and the usual suspects) initially built ca. 2006.

[kaseki]

On Friday, March 15, 2019 at 5:04:46 PM UTC-4, kaseki wrote:

Addendum 3: the measurement device operates using the Display Analyzer tool installed via Software Manager.

[kaseki]

On Friday, March 15, 2019 at 5:04:46 PM UTC-4, kaseki wrote:

Addendum 4: The ColorHug2 seems to interact appropriately to Linux files related to the ColorHug or Argyle, etc.  That is, there is a connection between the OS and the USB sensor, and the sensor seems to react appropriately to the software.

Nonetheless, observed in detail there was strange behavior yesterday in attempting preliminary calibration.  My new BenQ  SW2700 PT is specified to be factory calibrated and the provided test report supports that.  Comparing an x-rite color checker Passport under 6500K light (CRI ~96%) to a synthetic image of the x-rite patch RGB values suggests that the colors are reasonably matched in most cases.

Yet the ColorHug Display Analyzer software (under Linux Mint) claims a color temperature of 7300K instead of the 6500K set in the BenQ menu.  Further, In the early calibration steps under DisplayCAL there is a recommendation to turn the green much lower and the red and blue much higher.    Changing them in the Hue menu did not seem to change them in the measurement.  This is probably pilot error, but I think there is some other issue involved.

For example, I have cleaned out resident icc's from my old HP ZR2440w.  Color Profile viewer seems to be reporting that the system is using /usr/share/color/icc/colord/Gamma6500K.icc, aka D65.  I would think that without any new calibration overlay, and with a factory calibrated BenQ, the OS shouldn't be using ANY other icc.  I'm not sure how to set it to none for testing.

Enlightening comments will be appreciated.

The apparently dead "Live USB" may have become so due to being subjected to high power x-rays when passing through US Customs.  The possibility of ESD damage seems less likely.  Deadness confirmed on an Acer laptop.

[kaseki]

Addendum 5: Mr Hughes kindly provided a link to the iso file that one would find on an operative USB stick.  To make a long story tolerable, I found the PC in use for photo purposes to be unable to boot from a USB stick, or even from a USB DVD player.  (Something to research in the fullness of time.)  The 2 different DVD R/W devices installed in the PC tower were too old for the DVD format of the writable DVDs on hand.  Other format DVDs were obtained, but none seemingly old enough.  I ended up installing new Plextors that I had been saving for an eventual replacement PC.

So with a DVD boot disk and new DVD players, I booted up into the Red Hat build used to carry the supplied ColorHug software and DisplayCAL and its supporting software.  Perhaps normal Red Hat functions more normally, but I found that windows would jump around on the screen, the file manager would not look into my existing hard drive without just disappearing from sight, and a general awkwardness of functionality.

As for the calibration process, the three main stages behaved as follows.  The ColorHug Display Analyzer provided almost the same results as running under Mint.  Reported color temperature was slightly lower but still much higher than the factory calibrated BenQ was expected to be.  (7K vs 6.5K degrees)  The initial part of the DisplayCAL (base adjustment) showed the same "too much green, too little red and blue" result.  Unfortunately, changing the hue on the display would seem to take in the OSD menu, but not show up as a change that DisplayCAL could see (or that I could see).  This (fictitious green to red and blew unbalance) is the cause of the ultimate over-red result, I believe.

So I calibrated without changing the base condition to see what would result.  The resulting profile was found in the LiveDVD's home directory, which of course would evaporate when rebooting to the installed Mint OS.  RedHat's inability to look into my harddrive sabotaged any direct move of the profile, so I had to write it to a USB stick, and then, when rebooted into Mint, move the profile to the hidden directory dot-local/share/icc.  I also put a copy under dot-color.

I then ran Profile Loader.  It allowed me to temporarily see the result of loading the profile.  Not good.  Way too reddish, and maybe purplish.   So I didn't install the profile.  I am now a slightly wiser but not very enthusiastic ColorHug2 experimenter.  I still have to keep open the plausible argument that this result depends more on operator error than on hardware/software error.  If I learn more I'll provide a further addendum.

On Friday, March 15, 2019 at 5:04:46 PM UTC-4, kaseki wrote:

[Bruno Pagani]

Le 21/03/2019 à 14:38, kaseki a écrit :
> I then ran Profile Loader.  It allowed me to temporarily see the
> result of loading the profile.  Not good.  Way too reddish, and maybe
> purplish.

Yes, as I said the default CCMX in the ColorHug2 is wrong for the R
reading, and see too few of it (which results in wrong temperature
measurement too). Consequence is that it “corrects” the profile by
reddening a lot. I also guess this actually results in wrong colorspace
measurements.

Richard acknowledged our messages years ago about this issue and said he
would investigate it and make more tests, but we never heard of that
again since.

One partial workaround for this, under DisplayCAL, is to select the “LCD
(generic)”, “Refresh (generic)” or “Raw” mode in the “Instrument”
section. This actually changes the used CCMX to default ones, so you
don’t get the advantages of ColorHug2 calibration, but since this one is
wrong anyway… Not ideal (the best would be a recalibration of the
ColorHug2 using a spectro-colorimeter), but already quite good and
likely the best you can achieve until someone with the adequate material
solves this issue.

Regards,
Bruno

[kaseki]

Thanks.  I'll have to experiment with your suggestions.

[ipe...@gmail.com]

Is colorhug no longer available?

[Richard Hughes]

On Wed, 21 Oct 2020 at 15:56, ipe...@gmail.com <ipe...@gmail.com> wrote:
> Is colorhug no longer available?

The sensor supplier got sold to a much larger multinational and pushed
the minimum order quantity over what we'd sell in 2 years :( Plus, we
had a second baby, and the LVFS kinda exploded. We're not planning on
making any more I'm afraid. Apologies.

Richard.

[Andreas Scheucher]

Hi, AFAIK the producer and seller got a baby and has no time to offer it anymore.

--
You received this message because you are subscribed to the Google Groups "colorhug-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to colorhug-user...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/colorhug-users/c16f818a-d219-4336-abe2-7bda63ce38dbn%40googlegroups.com.

--

Andreas Scheucher e.U.

www.scheucher.cc, andreas....@gmail.com, +4369911196989

Dr. Robert Graf Strasse 32/10, 8010 Graz, Austria