[Openicc] New options on the mainline

Sun Jan 20 15:03:01 PST 2008

Yes, there is an "apparent disconnect" in that I am a scientist and
not like you a religious fanatic. When I started to write software
thirty years ago we just shared our source code with everybody else in
the science community and didn't call this saving the world or make a
big thing of it.

Let me be a bit blunt and technical for a change. It is necessary to
be blunt, Hal, as differently from Robert *you*, Hal, have a problem
in understanding technical details relating to color.  You can use ANY
piece of sofwtare in the world, open or not to write the STANDARD TEXT
FILES which describe _measurements_ .  Do you understand that a
MEASUREMENT is a FACT, that establishes  the STATE OF A SYSTEM ? Of
course one can use an open source system to make measurements, or one
can use a closed source system, it doesn't matter because there is a
STANDARD INTERCHANGE FORMAT for measurement files. My suggestion was
that as everybody reads and writes these standard files, including of
course the excellent open-source argyll system, implementors will gain
time by integrating  a parser for the measurements to the existing
codebase.

Another detail you don't understand, as a religious fanatic, is that
open-source people don't make measurement equipment, hardware makers
make measurement equipment. Which is why most of the color consultants
in the world use the manufacturer's software to generate the files
THAT ARE STANDARD . Because the high-end spectros cost substantially
more than the computers they are hooked to. If you are prepared to
create software that drives the DTP70, iSIS, IO, and Barbieri
spectros, please do so, but until you are finished don't deprive your
userbase of the ability to get measurements painlessly from their
existing equipment by reading standard files generated by working
software that happens to live on other platforms.

I know I sound very unpleasant, and I am very unpleasant - I am a
prime defender of open source software, and wish the whole world used
it and Microsoft went away, but I cannot stand religious fanatics.

Edmund

On Jan 20, 2008 11:06 PM, Hal V. Engel <hvengel at astound.net> wrote:
> On Sunday 20 January 2008 13:38:04 edmund ronald wrote:
> > Why reinvent the wheel ? There are standard linearisation targets that
> > can be dumped in an image file, printed by Gutenprint, read by using
> > free (as in cost-free) software like Colorport  with ANY standard
> > instrument, Colorport or other manufacturer software generates a CGATS
> > file, and then that CGATS file can be easily parsed back into some
> > utility *which you need to write* to determine linearisation. The same
> > for profiling, one can assume that if the user can print his targets
> > (s)he can get the job done.
>
> On open platforms that assumtion is not valid.   Where do I download a Linux
> version of ColorPort or a version that will run on a Solaris SPARC machine or
> a freeBSD machine?  The problem is that none of these vendor supplied
> software run on our platforms.
>
> I don't think anyone here is trying to reinvent the wheel.  ArgyllCMS will do
> most everything that ColorPort will do at least with a limited set of meters
> (DTP20, DTP22, DTP41, DTP51, EyeOne Pro) but has a UI that is not as
> accessable.    But unlike ColorPort it is a cross platform applilcation and
> it runs on our open system.
>
> >
> > Doing it this way brings your job down to the reading of the linearity
> > values from a CGATS or txt file, which means a few hour work instead
> > of all this decision about what open source project to involve next. I
> > know about this stuff because I helped the Caldera guys integrate the
> > DTP70 instrument in their RIP,taking my DTP70 on location, and it took
> > us one afternoon to get it done.
>
> If the device vendors were actually doing their job on our platforms you would
> perhaps be correct.  But your DTP70 is also unsupported on our platforms and
> if you call X-Rite support and ask for drivers and softwre that will run on
> Linux or any other open platform you will not get any satisfaction.
>
> I had wondered about the apparant disconnect I was seeing in your emails
> relative to the other posters on this list but now I think I understand.  The
> name of the email list is OpenICC.  The key word is open as in ICC for Open
> systems.  It appears that you missed that.
>
>
> >
> > Edmund
> >
> > On Jan 20, 2008 10:19 PM, Hal V. Engel <hvengel at astound.net> wrote:
> > > On Sunday 20 January 2008 12:24:33 Kai-Uwe Behrmann wrote:
> > > > Am 20.01.08, 11:28 -0800 schrieb Hal V. Engel:
> > >
> > > snip
> > >
> > > > > When I looked at trying to linearize my printer a few weeks back what
> > > > > I wanted was to start with the existing curves and to be able to
> > > > > apply a correction to that curve.  The problem of course was the UI
> > > > > does not make that curve available and there was no way to get this
> > > > > without resorting to making API calls to the GutenPrint driver and
> > > > > even then it was not clear from the API docs that these calls are
> > > > > really what I wanted.
> > > >
> > > > We will see those task several times. As they are not Gutenprint
> > > > specific, it would make sense to handle them in a separate project. At
> > > > the moment it is unclear who takes over this task.
> > > >
> > > > > I think that what is really needed is an API that allows for applying
> > > > > a correction curve to the existing base curves.  I believe that this
> > > > > is how most RIPs operate but I really don't have any experience with
> > > > > them.  Once there was such an API exposing it in a UI so that users
> > > > > could hand enter a set of correction values would be a good starting
> > > > > place.  For example the QuadTone RIP Eye-One-ReadMe document shows a
> > > > > set of examples based on taking a set of measurements of a 21 step
> > > > > gray ramp (this is a B&W RIP) and then loading this into an
> > > > > application called QTR-Linearize-Data that analysis those
> > > > > measurements and gives a result something like:
> > > > >
> > > > > LINEARIZE="96.55 92.14 86.45 81.02 75.65 70.55 64.85 59.60 54.62
> > > > > 50.06 45.73 41.99 37.63 33.91 30.95 27.75 25.01 21.80 19.84 18.43
> > > > > 16.95"
> > > > >
> > > > > The user then takes this data and drops it into the QuadTone UI and
> > > > > tells it to use these measurements to correct the printers output.
> > > > > The data above is nothing more than the L* values from the
> > > > > measurements.  We already have the tools to make similar sets of
> > > > > measurements and to create similar data sets. Of course the real
> > > > > issue is what would the GutenPrint API do with these measurements to
> > > > > make the linearization corrections?
> > > >
> > > > My impression is to keeping such stuff outside of Gutenprint makes
> > > > completely sense. The curves can easily described in ICC profiles. It
> > > > would be up to early colour binding applications or the print system to
> > > > select and chain the according profiles (calibration + final profile).
> > > > We could certainly assist in creating or teach in using the appropriate
> > > > tools.
> > >
> > > I was mostly trying to layout some "user" expectations in this specific
> > > area. That is a user would expect to be able to generate and print some
> > > type of linearization target that was correctly laid out for his/her
> > > spectrophotometer.  Then, either from the linearization software or
> > > externally, measure it and that this data would (after being entered into
> > > the linearization app if it were measured externally) result in the
> > > appropriate corrections being made to the ink curves.
> > >
> > > At first this could be very basic and could even be a set of command line
> > > apps to do a series of steps to get the job done.  For example, ArgllCMS
> > > could be used to generate and then measure the linearization targets.
> > > The resulting CGATS measurement file could be used as input into the
> > > linearization app which would feed the resulting curves back into
> > > GutenPrint.  Once this was working we could start building a GUI around
> > > this and eventually end up with a nice fairly easy to use system.
> > >
> > > I do agree that this could be totally external to GutenPrint or it could
> > > also be part of GutenPrint or some combination of these.  From a user
> > > point of view where the separation takes place is not very important as
> > > long as things work.  But you are right that having this be external to
> > > GutenPrint would allow it to work with other drivers if those drivers
> > > exposed the needed interfaces.
> > >
> > > I also think these tool need to support the work that goes on when the
> > > GutenPrint team developes the initial set of ink curves.
> > >
> > > > > Anyway I thought that I would through this out there to see if this
> > > > > sort of thing was possible.  I suspect that long term what it does
> > > > > should be based on some standard that tries to establish an ideal set
> > > > > of curves for each channel.  This might be based on something like
> > > > > G7.
> > > >
> > > > Would it make sense to you to support the provided G7 targets?
> > >
> > > I am not sure what you are asking.   But it would be possible to use
> > > LProf's SourceForge facilities such as CVS/SVN to support something like
> > > this.  It might even make sense to have this interface be an extension of
> > > LProf since it already has things like a UI for selecting and configuring
> > > meters and longer term LProf will have facilities for generating and
> > > reading printer targets.  Currently we are focused on display calibration
> > > and profiling work. But I don't think we can take this on unless there
> > > are new volunteers who can take on the added work load and I think that
> > > we would need someone to take on the lead role for this effort as well.
> > >
> > > Hal
> > >
> > > _______________________________________________
> > > openicc mailing list
> > > openicc at lists.freedesktop.org
> > > http://lists.freedesktop.org/mailman/listinfo/openicc
>
>
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc
>