[Openicc] CUPS Color Management under Linux gets into distros

[Hal V. Engel]

On Friday, March 04, 2011 04:38:01 PM Chris Murphy wrote:
> On Mar 4, 2011, at 7:13 AM, Cyrille Berger Skott wrote:
> > On Friday 04 March 2011, Alexandre Prokoudine wrote:
> >> Well, I understand the expertise bit, and the hardware bit, and the
> >> interest bit. But the vision bit? Not being able to print directly
> >> what you paint?
> > 
> > How many artists do print their work themself?
> 
> If the end goal is something that will be printed, I'd roughly guess 98-99%
> of them at least proof their own work on a printer themselves. Or at least
> want to.
> 
> > And how many would want to do
> > it from inside Krita?
> 
> Can't answer that. Don't know the market.
> 
> > I can see it as being important for a picture
> > application, but for drawings/paintings, you would usually print them on
> > printers that artist cannot afford, and it is more profitable for them to
> > send it to a print shop.
> 
> Absurd. That's the entire point of color management. The artist can see the
> printable colors on-screen so they aren't choosing colors that can't be
> printed in the first place; and they can simulate the press on a local
> cheap printer as well. That is for drawings and paintings. Artists are
> using inexpensive inkjet printers to produce prints that cost thousands,
> to tens of thousands of dollars, per print. The artists can afford inkjet
> printers of some size or they could not afford their computer or their
> apartment.
> 
> They send these to a print shop that has NO idea what the color intention
> was, so they do several iterations just agreeing on the color. $1 per
> print? $5? $50? This is the reason why no company who understands inkjet
> printing and color management is outsourcing high end contract proofing.
> They do it in house. They do not send it to a print job for proofs. The
> print shop is for cheaply printing 100, or 1000, or 100,000 copies. Not
> for proofing. Proofing is a huge profit center for print shops.
> 
> > We want Krita to be the "cool drawing/painting application". And that
> > does not involves printing. All we need to make sure is that the print
> > worker can open the files produces by Krita in his "cool printing
> > application", whatever that is. Or the editor in his "cool layouting
> > application". And ideally, all this is done in a color managed workflow.
> 
> Well yeah it would have to be color managed or the workflow would be
> fakaked, wouldn't it? It would be fragile and unpredictable.
> 
> I think Krita must be a good example application that is in need of the
> CPD.

This really is not a CPD issue.  The CPD requires that the app hand it a PDF 
spool file and if that file is stripped of CM info then the printing pipeline 
will treat it as sRGB assuming that the content is RGB and assuming that there 
is a CM smart printing engine in place.  The issue is that Krita is currently 
dependant on the Qt print engine to produce that spool file and as I have 
reported the Qt PDF print engine is badly flawed.  The CPD would not change any 
of this for the Krita folks.  

The only option at this point is to by pass the Qt printer paint device and 
create PDFs directly to be sent to the printer.  This may not be a huge issue 
since there are libraries for creating PDFs out there but I don't know if 
these are good enough to create properly color managed PDFs.  And even if 
there were a library that would do the job it would still be non-trivial to 
add this functionality to an app like krita.   In the long run either the Qt 
printer stuff gets fixed or Qt apps that are concerned about CM will need to by 
pass Qt when printing docuements where color matters.

> If it can simply hand off the document correctly, its job is done.
> It's up to the print pipeline to do the right thing from that point on.
> Why in the world should we go to a monolithic specialized printing
> application just to get something proofed on a desktop inkjet printer?
> 
> > If someone was coming to us and say that exporting images to PDF is
> > required by his print shop/editor, then we will have to implement a PDF
> > export that countains the ICC profile (might be needed when we are done
> > with implementing a full comic workflow, but until now, PDF is overkill
> > for exchanging images).
> 
> I would think a large percentage of comic design would be vector based,
> even the text that looks sorta hand written could be a font, and PDF would
> be highly suited for this task.
> 
> > Is there any proper viewers other than graphics/imagemagick ? Usually my
> > answer is that for export they would need to convert to sRGB, because,
> > even if they themself switch to a proper viewers, they don't want to
> > educate the whole world.
> 
> OH well, I guess they don't care too much about color accuracy.
> 
> 
> Chris Murphy
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/openicc/attachments/20110304/278a4e29/attachment.html>