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

  • From: Pascal de Bruijn <pmjdebruijn@xxxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Mon, 4 May 2015 18:32:09 +0200

On Mon, May 4, 2015 at 8:02 AM, Graeme Gill <graeme@xxxxxxxxxxxxx> wrote:

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.


Thanks!

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.


Ah ok, my bad.


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.


Actually this wasn't what I was getting at. In case of CCMX/CCSS files, I
can always just edit them manually to remap anything I'd like. This is why
it's so awesome that argyll uses text based file formats. So I'm not sure
that actually requires any changes in that sense.

The ColorMunki Smile is a bit of a cornercase I guess, since the White LED
matrix for that device is embedded into the device itself, right? So I have
no CCMX file I can edit to remap the selector key. (Aside from modifying
and rebuilding argyll sources, which is a tad, overboard I guess).

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.


I'll keep my eye out :)

Regards,
Pascal de Bruijn

Other related posts:

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