[FEATURE]: Implement API to control typical spectrometers.

[KelSolaar]

Description

There is a growing need to be able to control spectrometers with Python and possibly leverage Colour to process the data.

I'm taking the opportunity that @tjdcs mentioned it on Gitter to start a thread.

A few random points and tags for VIS:

1. A dedicated repository would be preferred as we could make Colour an optional dependency. It is also extremely hard to test without actual hardware attached.
2. I wrote a module for the Colorimetry Research spectrometers at Weta FX that could maybe be open-sourced. I will check with @kthurston if it is possible.
3. I have at home an Ocean Optics spectrometer that I would be keen to handle through Python. There is already python-sea breeze that could be wrapped.
4. @quister has an Asantes spectrometer and this could be of interest to him.
5. @JGoldstone might have related stuff of interest in his pocket.
6. @KevinJW might have stuff that he cannot share but still find the idea interesting.

Cheers,

Thomas

[JGoldstone]

Although the project in which my spectroradiometer code was originally meant to be open-sourced, done on my own time, it ended up being too useful and I did paid-time work on it so ARRI owns it now. I did suggest open-sourcing it but maintaining control (as Pixar maintains control of USD and OTIO I believe) but there was a perception that any delay in fixing bugs in the project would reflect poorly on us. It wasn't officially said that we could never open-source it, but OTOH I don't feel as if I carried the day in the argument.

A difference between projects that have gone from closed- to open-source (e.g. OpenEXR, OCIO, OIIO) and this one is that those projects all see heavy use inside the originating company. This project is to date, except for a tiny component that is an implementation of ARRI's camera control protocol, only used by me. And I am about to be even busier than usual, for the next year, in helping people adapt to the workflow implied by ARRI's new camera.

As a starting point I could ask if I can share a couple of pieces: the protobuf+grpc definitions that define the meter service abstraction (i.e. the .proto file) and the Python abstract base class that lets a single protobuf+grpc-based meter server talk to a variety (at the moment, just Minolta CS-2000[A] and i1Pro[23], but CR300 on the horizon) of devices without any device-specific code being in that server. Would that be useful?

If I can finish it before leaving for holiday tomorrow I might be able to get out a diagram of the overall system. It's designed to coordinate display of target content (including, for reflective targets, controlling lighting to illuminants the target), measure the target, capture images or clips of the target, and store resultant measurements using an extending subclass of Colour's IES TM 2714 implementation. But it's looking like a busy day.

@KelSolaar, I believe (it's been a year) I wrote some testing substrate where I was informally mocking the behavior of the Minolta, and I was planning on cleaning that up and maybe actually using Python mocks for the CR300. Perhaps the testing isn't as bad as you think.

One thing that might help, a lot actually, in persuading ARRI to let this be open-sourced but still associated with ARRI would be a particular quid pro quo: a promise from experienced hands to guide the task of fully fleshing out the project on GitHub: rigorous CI, code quality metrics, code coverage assessment, and packaging. I could make an argument that it would be worth open-sourcing the package just for me to be able to learn how to 'do GitHub right'. Colour does a pretty good job here; OpenEXR (I think much because of @xlietz) does a suberb job of this. So maybe that's an avenue.

[tjdcs]

Thanks for opening this request on my behalf @KelSolaar. I do have a short term and very quickly upcoming need for a CR-300 controller. I'll probably start developing something on my fork soon. Possibly today or this weekend. I'm happy to scrap that if other people have solutions that are better but will take longer to come out. But it's where I'm at. I have to write code anyway, might as well try to do something that will benefit others.

A few points of feedback and ideas.

1. I'm never going to use one of these spectros and not be interested in color transforms in the same project. So I will always have colour-science in my workspace.

2. Making color-science [optional] restricts the potential API to essentially outputting only the spectrum, and measurement metadata like exposure time. Some spectro's do output XYZ, CRI, etc... directly but frankly I don't trust their code that I can't see. Particularly with anything that isn't XYZ 1931 2-deg. Older spectros that scale XYZ may be using the wrong scaler for candelas. So unless we copy some of the color transforms into two places, the API will be extremely restricted.

3. I'd prefer an API that outputs color-science objects directly. But if these can be serialized into protobufs for others use that's great. I think that's a separate issue than implementing support though.

4. Given the closeness between the two "packages" in my usage, it would be much simpler from my POV to just add a new subpackage for io.hardware.spectros or something to colour-science.

5. testing for breaking changes or even pseudo-data using color-science's other SPD generation capabilities shouldn't too hard with the mocking framework provided by pytest. Still, real world tests are needed. As far as spectroradiometers -> I have access to CS2000, PR650, PR655, CR-250, CR-300. Once the framework is built out I expect there to be a simple serial port (or other) io module that provides only the lowest level device communication to a more useful spectroradiometer class.

Other devices that I have access too:

spectroiradiometer (new vocab unlocked?)

• MK350N

spectrophotometer

• i1 Pro3 Plus
• i1 Pro3
• several benchtop models which are all out of date and possibly not that useful to really implement. future future future work.

[JGoldstone]

Certainly no way I will have anything soon, so we might see several independent and not necessarily comprehensive CR300 controllers emerge. Yeah, my code depends on colour. And though I will take colorimetry from a meter if it's got it, in practice I always try and get spectroradiometry if available. My Colorimetry objects are built from three pieces: Context, values, and Provenance. Context is built from Observer, Colorspace and Illuminant, values is just the triplet; and Provenance is an Enum, one of MEASURED, DERIVED, DEFINED and MANUAL. MEASURED doesn't distinguish between colorimetry from a genuine, non-diffraction-grating-based colorimeter and colorimetry from an internal diffraction grating but no access to it.

In re: the MK350N, do you have API documentation? It looked to me as if you had to use their app. I did write something for the Sekonic version that won't give you spectra, but does give you a pretty picture of the spectrum from which it's deducing colorimetry...anyway, someone in my team in Munich has one of those but I haven't found anything that suggests it can be remotely controlled so I'd love to hear more.

re the i1Pro3: I have an i1Pro, i1Pro2 and i1Pro3 [non-Plus]. The X-Rite SDK is solid but it's proprietary; you really have to sign something constricting to get access to it if you're not a manufacturer. Graeme Gill of Argyll is trying to black-box a driver for it and if history is any predictor he'll do a great job and then you could be free of that restriction. I'd reach out to him. In fact I'd reach out to him to see if Argyll has support for other devices without documentation being vendor-provided.

[tjdcs]

Alright. I'm going to take a crack at this with just the CR-300 over the next several days. We can see if we like that structure. It may need some "pythonic" tuning up. I'm relatively new to python.

MK350N has a serial port protocol I think. but good point about that. I haven't actually looked for or used it. Just a potential target. It may be difficult / impossible but I think it's very likely they are using a M, RM spectrum serial-port style interface like others.

Good to know about the X-Rite SDK. That could be very tricky. But it would be very nice. perhaps also making the list of future future future work.

[quister]

Hi, all. Yes, this would be very handy. I have the AvaSpec-ULS4096CL-EVO from Avantes, which has various libraries including python for driving it, though I've not yet set aside time to dive in. It's on my list, though.

[KelSolaar]

To @JGoldstone's point, it seems like there are two competing desires here:

1. Producing something quick that could be used immediately with a less generic backend, possibly harder to extend.
2. Producing something based on a more reusable framework that would be likely easier to extend.

Both paths are valid provided they end up to something that can be used. The code I have at work solves point 1 and is probably along the lines of what @tjdcs needs. What @JGoldstone proposes is point 2 but requires getting some traction on ARRI's end, shall we start a thread in the background?

[JGoldstone]

@KelSolaar I think a background thread would be great.

[KevinJW]

I'm old school, my CR-100/250/300 code is in C++ and is conceptually similar to previous code owned by my previous employer which controlled Photo Research devices, because the APIs are very similar and in my applications I need similar concepts, end result is very similar code. If I was to start again I guess I'd try for Python, my use case would be to work nicely within a multi execution context world.

As an example in a PyQt GUI, you can't hang up threads waiting for many seconds for the devices to respond, so some architecture for event handling or reader threads or whatever is a must to consider. I'm assuming any interface library should not be tied directly into PyQt as other people might want/need different UI components etc,

[tjdcs]

This is a good point. I'll be sure to include that in my rough implementation (just in case it gets adopted)

[JarrettR]

Is control of external devices in scope for this project?

It seems to me that a spin-off project might be a good idea, exclusively for device control. This repo, to me, is purely for calculation and processing, but that may just be the way I use it.

I have access to a Sekonic C-7000, and we are doing some automation with the SDK. I may be able to make the case to open source parts of it and contribute to whatever results from this discussion.

[tjdcs]

name request:

colour-specio

Requesting this name and project affiliation for code related to controlling spectroradiometers or other instruments. Code is currently available on https://github.com/tjdcs/specio

Currently Supports CR-300 officially, and unofficially supports other colorimetry research family spectroradiometers. The code is in its infancy, and is unlikely to maintain the high standards of the main colour-science repository due to the issues of testing and maintaining instrument dependent code.

Following this discussion: I agree that spectrometer control belongs to a seperate project. The current code depends on colour-science version 0.4.1 and it's API is designed to emit colour-science objects that are easily read into and out of other functions in the colour-science repository. There is no file io mechanism, although that is a welcome contribution and a project objective.

I'd like to publish the initial version of specio soon, although it is a very simple codebase thus far.

[tjdcs]

If there is not concenseous on this, I will still publish specio under a different name and an affiliation / organization merge can be discussed in the future (if ever deemed necessary / worthwhile )

[KelSolaar]

Exciting and I'm totally fine with it! I'm a bit buried under OCIO and Work work but I will get back to you soon! Feel free to take the name!