[argyllcms] Re: ColorMunki Smile display types

  • From: Pascal de Bruijn <pmjdebruijn@xxxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Mon, 15 Jul 2013 19:54:10 +0200

On Thu, Dec 27, 2012 at 12:32 AM, Graeme Gill <graeme@xxxxxxxxxxxxx> wrote:

> Pascal de Bruijn wrote:
> > I've done some nosing around in the development sources... and while
> > keeping in mind this is of course a work in progress... I noticed the
> > following:
>
> Hi Pascal,
>         this is an aspect that has been hovering at the edge
> of consciousness, so thanks for bringing it into better focus.
>
> >
> > The ColorMunki Smile currently seems to ""abuse"" the display types,
> > so 'l' isn't regular lcd anymore, and 'c' isn't crt anymore.
>
> I was thinking 'c' for Ccfl, and 'l' for Led :-)
>
> > Next I noticed the Spyder4 is a fairly extensive/complete selection of
> > display types:
>
> > What I would suggest is to use the Spyder 4 display types as a model
> > for all the other devices (so there is at least consistency), and
>
> This can be made to work for the Spyder4 and most of the devices
> with fewer selections, but not so easily for the i1d3 without some hack,
> since the .edr/.ccss files will (currently) end up with numeric choices
> that simply depend on the file system order. One way of tweaking
> this would be to add an optional "selector" parameter to the .ccmx and
> .ccss files, but there would be some fudging to set these up in
> the .edr to .ccss conversion, and deal with potential clashes.
>
> > Also, maybe consider using 'w' or 'e' as alias for nr. 5 (white led)?
>
> Maybe 'f' for CCFL LCD and 'e' for LED LCD, with 'w' for wide gamut.
>

Of course all the above has been implemented for 1.5.0/1.5.1... however for
some devices -y l and -y c don't work anymore, potentially breaking
pre-existing scripts (when used with newer type devices).

So I'd suggest to add semi-sensible aliases for some types to 'l' and 'c'
where possible. I've attached a patch which should do just that, and at
least it compiles. I do not however own any of the affected devices, so I
can't do any real testing I'm afraid.

Please do thoroughly review before (if agreed) committing, my understanding
of the sources is limited at best.

Regards,
Pascal de Bruijn

Attachment: argyll-151-compat.diff
Description: Binary data

Other related posts: