Re: Decent results with Gutenprint - the poor man's RIP.
Re: Decent results with Gutenprint - the poor man's RIP.
- Subject: Re: Decent results with Gutenprint - the poor man's RIP.
- From: Kai-Uwe Behrmann <email@hidden>
- Date: Wed, 21 Jun 2006 10:22:31 +0200 (CEST)
It may appear logical to you by experience. But let me explain why I think
the 16-bit method is different from traditional linearisation of RIP's.
Linearisation can be divided into two logical parts. The first part is to
determine ink limits. This is necessary to avoid bleeding and to use
the capablities of the print media to its extend.
The second part is, what by the sense of the word is more appropriate to
linearisation, to compensate non linearities in the device response by a
curve or make the device response straight-lined. This curve lays
inside the boudaries found by part one, the ink limits.
Now the practical side. In Gutenprint's materials ("Media Type") list I
found allways a suitable one to get the ink limits. This list is
available in the CUPS interface too. Ok, tissue paper was not among them.
This fullfilled part one of the linearisation.
Once obtained the ink limits there was no need to me for custom
linearisation curves as described as part two from above. This is a
difference between 8-bit and 16-bit image -> device colour conversions.
Part two of the linearisation is absolutely necessary to get good results
in 8-bit workflows.
Despite of this the technology exist, and is useable, to print and profile
in 16-bit precission without the second linearisation part.
Beside this, a roughly balanced response in the 16-bit path would help to
have all measurement patches better spread over the gamut. The gamma or
"Density" values in Gutenprint should suffice for that.
To conclude:
Gutenprint eighter obtains 16-bit device values. Colour conversion can
appear then in the application or imaging library, for instance ColorSync
or Gutenprint itself.
Or Gutenprint obtains a possibility to get custom linearised and can then
better work with 8-bit device values. So one could send 8-bit Cmyk to
Gutenprint without too much stepping or the need of additional dithering.
For this second possibility it is not so clear who will do the programming
work.
regards
Kai-Uwe Behrmann
+ development for color management
+ imaging / panoramas
+ email: email@hidden
+ http://www.behrmann.name
Am 21.06.06, 00:30 +0200 schrieb edmund ronald:
> Without discourtesy, Mr. Behrman, when one decides to use a new
> printer with new inks on a new paper - one will need to determine ink
> limits first, and then linearization, and ink curves. If someone has
> done it for you already, then of course profiling is enough.
>
> At the moment this is not so easy for a user to do (I cannot do it).
> An expert (maybe Robert) is doing it for you, but he is only doing it
> for the ink cases he knows about on the papers he knows about. I
> propose making this part easier so anyone on the Colorsync list can do
> it.
>
> And yes, most people on the Colorsync list already know this routine
> because it's necessary for a RIP when you install it for a client with
> the client's chosen media. Which can be anything from tissue paper to
> plasic.
>
> Edmund
>
> On 6/20/06, Kai-Uwe Behrmann <email@hidden> wrote:
> > Am 20.06.06, 08:36 -0700 schrieb Roy Harrington:
> >
> > > I think linearizing the print driver response would be a more
> > > important
> > > factor than having a 16-bit interface.
> >
> > The 16-bit printing workflow was allways very reliable and highly
> > fault-tolerant.
> > Without further linearisation (Gutenprint's "Uncorrected") I obtained
> > solid printouts admired by my visitors.
> > A much bigger issue, for instance, was bronzing.
> >
> > regards
> > Kai-Uwe Behrmann
> > + development for color management
> > + imaging / panoramas
> > + email: email@hidden
> > + http://www.behrmann.name
> >
_______________________________________________
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