[argyllcms] Re: Display Calibration with Colorimetry Research CR-100 CR-250

  • From: Tucker Downs <tucker@xxxxxxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Thu, 11 Mar 2021 23:20:55 -0500

Thank you for these insights. I will look at the two drivers you suggested.
Dealing with serial port heuristics is indeed a pain. This is not an urgent
project for me but I will look into it over the next several weeks.

- Tucker

On Thu, Mar 11, 2021, 8:19 PM Graeme Gill <graeme@xxxxxxxxxxxxx> wrote:

Tucker Downs wrote:
Would you accept a third party contribution under MIT on this?

A third party contribution is welcome under MIT or GNU, but comes
with disadvantages that need thinking through.
(If it's GNU, then no support in the ColorMeter App.)

I can compile the code and include it in source and binary
distributions, but I can't guarantee it will work - someone
with an instrument will have to do the QA and send bug fixes back.

The driver developer may not be compiling on the range of
platforms supported by ArgyllCMS, and that could create difficulties
in including support for that instrument on some platforms, and/or
verifying that it works or fixing it if it doesn't.

If such a driver breaks other instrument operation, then I would
have to disable it. (With serial based instruments this is
quite a possibility - the heuristics of automatic serial instrument
discovery are tricky. USB serial is slightly easier, but unfortunately
the manufacturers of USB serial based instruments rarely seem to make
their instruments recognizable at the USB level, and discovery
heuristics are still needed.)

Changes I make to the instrument or system interface API's can break
the driver and there's no way I can check or fix it. The best I can do
is get it to compile again, and I may not know how to do that in
a way that keeps the driver working. I may add new capabilities to
the API but I won't be able to implement them for that instrument, or
may implement them in a way that doesn't work or breaks the driver.

An instrument may need or operate better with changes to the instrument
API, but making those changes is more awkward to manage, and I
won't be aware of the need or opportunity for such API changes unless
the driver developer signals them, and I have the time to be able
to work with them on implementing the changes.

At a practical level, merging changes back is mostly a manual
process since the public source code is a sub-set of of my source
code.

So in summary, yes it's doable and has the great advantage of
broadening the range of instruments supported and dividing the
work needed to write them, but comes with some disadvantages
that have to be lived with.

For a serial connected spectrometer, I'd start with the JETI driver.
For a serial connected colorimeter, I'd start with the K10 driver.

Cheers,
        Graeme Gill.




Other related posts: