[argyllcms] Re: ArgyllCMS V1.7.0 has been released

  • From: Graeme Gill <graeme@xxxxxxxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Mon, 04 May 2015 16:02:02 +1000

Pascal de Bruijn wrote:

Hi,

Thanks! Much appreciated. I just renewed my "license" :)

your regular support has been appreciated!

ccxxmake -?? shows 'e' twice:
e LCD White LED
e LCD RG Phosphor IPS

Yep - that's a bug. (I'm sure it was working at one stage - I must
have broken it and not noticed).

Another thing I noticed with ccxxmake (not particularly with 1.7.0), is
that it uses scientific notation, when there are three zero's after the
decimal point. While there is logic to it, it does make these matrices
harder to read, and harder to compare with a diff command for example. It's
not of great importance, but it would be more convenient at times. (for
example:)

0.979483 -0.0111703 5.16712e-03
-1.45944e-03 0.996108 1.29009e-03
-0.0123473 0.0234351 1.03744

That's in the CGATS library. I think I was just trying to maintain
precision wile minimizing file size. I'll tweak it to allow some more
digits before switching to scientific notation.

I also noticed, that colprof -q h -b n also embeds the arts tag, which if I
understand correctly has no application that such a particular profile
(since it's input only). I'm aware it's a bit of a corner case, but
presumably -b n should disable the arts tag from being embedded?

The 'arts' tag could be used whenever there is a Media White point
tag in the profile - which means all of them except a device link.
An input profile does an absolute to perceptual chromatic transform
when creating the table or matrix, just like a print or display profiles.

And, another minor point, not particularly related to 1.7.0, when I have a
ccmx that has it's selector key set to 'e', say for a ColorMunki Smile
(which has it's own internal WLED matrix), it seems that the internal
matrix keeps being the 'e', and my custom ccmx is remapped to another key.
I'd like to argue that when I provide a ccmx, with an 'e' selector, I'm
doing so because it's better than a devices internal matrix, and thus would
like my custom ccmx, to be mapped to 'e' after all, thus override the
device matrix.

A little complex to fix, but I'll see what I can do. I'll have to
add a new tag in the ccmx/ccss files to indicate whether it is an "oem"
file, and I still think I want to make all the the "built ins" have
priority. If I add such a tag to the OEM install code, it won't be
fixed unless you re-run oeminst again either.

Of course I'd happily test any patches regarding any of the above points,
presuming you might agree...

I'll update <http://www.argyllcms.com/Argyll_dev_src.zip> in due course.

Cheers,

Graeme Gill.


Other related posts:

  1. Home
  2. argyllcms
  3. Archive
  4. 05-2015