[argyllcms] Re: Software for matrix manipulation?

  • From: Steve Coleman <stevenlcoleman42@xxxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Mon, 12 Apr 2021 11:51:50 -0400

As a retired computer/data scientist I would like to make a suggestion. If
you are looking for a high level language for data analysis then you might
want to consider Python. Python is pretty much the go-to language for
scientific data analysis these days with litterally hundreds of thousands
of packages available including matrix manipulation and even
machine learning.

When I left the Lab last year many were ditching languages like Matlab and
converting everything over to Python. Python can be imbedded into other
C/C++ applications, used as JIT, or even compiled. At APL we had just
embedded Python into our data analysis tool and it gave our capabilities no
one even knew they even wanted, but it solved so many problems they had
struggled for years trying to solve. Users could now add algorithms on the
fly as extentions to help do the custome analysis they needed. Even Matlab
allows you to run Python code directly from within its own language
framework.

Python is an easy language to learn and has one of the largest data
analysis libraries to choose from of any language. If anything there are
too many choices. I think at last count that I recall there were upwards of
500,000+ packages you could install with a simple command.

I believe that machine learning, if you have enough data, could be
extremely useful in "understanding" color management. By passing through
the data and analyzing the changes on each pass, a machine learning
algorithm could not only learn what happens when you turn the knobs but
could then also make predictions for certain settings and different
materials and devices. It would be a very flexible solution and a win-win
for both users and equipment/suppliers.

Steve.


On Mon, Apr 12, 2021, 11:07 AM Ben Goren <ben@xxxxxxxxxxxxxxxx> wrote:

Before life moved me away from photography a few years back, I was
building spectral models of camera sensors and lenses and using those
models to generate simulated .ti3 files to hand to Argyll.

Back then, I was just using Excel for the math. It worked, with all the
obvious limitations and complains.

As I’m getting ready to pick things back up again, I’m thinking about
moving to something that’s not quite so much of a kludge.

Do I want to bite the bullet and go all the way to C? I’ve hardly written
anything in C and mostly stuck to higher-level languages — most recently
mostly in the Microsoft world with C#.

At the same time, I’m working my way towards an M.S. in Statistics…so
would I be better off going in the direction of something like Octave or
Scilab or even R?

Nothing I anticipate doing will be all that complex — I was able to do
everything in Excel before, after all.

I suppose I should add…the basic idea I’m aiming for is to create ICC
profiles for use with Argyll to apply to TIFF files created from minimal
processing of RAW camera files. I have a spectroscope I can use to get the
camera’s sensor response, and I’ll be using an i1Pro for spectral
measurements. This will include spectral characterizations of lenses — as
in, use the i1Pro to measure the spectrum of some uniform source (such as
the sky or something large and white in direct sun), and then to measure
the spectrum of that same source through the lens. Then the effects of the
lens can be reversed to create the model of the sensor, and any other lens
can be virtually applied to the sensor model.

Then, I have a large library of reflective spectra, including generated
samples as well as measurements. Combined with an illuminant spectrum
(either standard or measured at the scene) and I can create a
tens-of-thousands-of-patches .ti3 file for Argyll to generate a profile.

If there’s a more direct-to-Argyll approach I could take with just the
spectral measurements, I’d be happy to leave the number crunching to
Argyll. Or, if there isn’t such an approach but it’s not much bigger to
create one in C to incorporate into the Argyll codebase than it would be to
re-create what I used to do in Octave or whatever, I could go that route….

Thanks,

b&

Other related posts: