3rd Party Dreamcolor software
3rd Party Dreamcolor software
- Subject: 3rd Party Dreamcolor software
- From: "tl" <email@hidden>
- Date: Wed, 18 Mar 2009 09:11:51 -0400
Hi Graeme
I believe that the code was written in a fashion that a competent Linux
programmer could supply his/her own measurement solution. The ddc/support is
a Video Card issue that must be handled on a graphic card basis. The USB
interface to the display is a bear because of the enumeration issue with the
selected part. That was a real weakness in the display architecture. I do
not think that the display will enumerate properly using LIBUSB under Linux.
The USB first enumerates as a Mass Storage Device. In many facilities, the
USB mass storage capability is not enabled due to security reasons, so that
limits the utility of the USB interface in a Linux environment. So the
interface should be handled by the i2c channel in the graphics card.
The guys in the studios are using this with alternative devices, such as a
PR650. As I understand the open source project, it was not designed around
any particular measurement device, and it was not designed to interface to a
particular graphics card ddc driver. I believe that HP can supply a Linux
driver for our dreamcolor puck device. I will check that availability out.
I am certain that most people do not understand the pipeline well enough to
actually write software for it, you, grame, are probably an exception. It
is straight forward from the standpoint of a color scientist, but the actual
coding is extremely low level. Even though I wrote the initial calibration
application, I would not mess with the LUTs in the panel, particularly the
second one. I would like to write a standalone application that sets the
backlight color temperature and luminance using an i1Pro,but I don't have
the time. The backlight and luminance can be changed independently without
too much hassle, but I am not sure they will stick on a power cycle.
If you can accurately set the backlight color temperature and luminance in
full gamut mode, then build a display profile (version 4 preferred), you
will have a great colormanaged workflow. Most successful photographers
using the system just profile the system with their existing tools. The
full gamut mode on the display actually exceeds Adobe RGB on most displays.
As a cautionary tale to those thinking that thirty bit displays are going to
somehow magically give better shadow detail, check to make sure that your
color management system can actually generate output with 10 significant
bits. Then try to find a graphics card driver that can actually manage 10
significant bits. Our advanced development team in Grand Rapids has been
dealing with these issues and they are not trivial. When it comes to this
phase of technology, we are all on the bleeding edge.
Regards,
Tom
Message: 12
Date: Tue, 17 Mar 2009 11:30:56 +1100
From: Graeme Gill <email@hidden>
Subject: Re: 3rd Party Dreamcolor software
To: colorsync user <email@hidden>
Message-ID: <email@hidden>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Greg Staten wrote:
> Note that we already have an open source calibration solution on Linux
that
> might be useful to look at. It is called Ookala and is hosted at
> sourceforge.net <http://sourceforge.net/projects/ookala-mcf/>.
Hmm. While it's a nicely organized chunk of code, I'm not sure that it's
reasonable
to call it a "Linux solution" when it can't possibly work at all, since it's
missing
vital pieces - namely instrument drivers.
Graeme Gill.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Colorsync-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden