[Openicc] GoSoC 2011: CPD and target printing

Chris Murphy lists at colorremedies.com
Wed May 4 19:07:23 PDT 2011

On May 4, 2011, at 7:28 PM, edmund ronald wrote:

> Chris, 
>  Maybe I find devicespace to be really useful to have around as a working space.

Device spaces make pretty hideous working spaces (i.e. image editing spaces). They aren't gray balanced, they can have cross overs, they have non-linear behaviors that don't match up among the channels, and if the device space is literally ink controlling, you can rapidly run into individual channel and total ink limit problems. I think this is very special use case. It's a very sharp unforgiving razor black for 99.2% of the user market.

If you're really going to build software for 0.8% of the market, where I'm not even included, I personally don't find that very interesting. It's way out there. And that's fine. I don't think such software should be restricted from being built or from working the way the developers and users want it to work. But I don't think there should be a big razor blade launching device in every print dialog for all applications pointed right at the user even if it's hidden by default behind an advanced panel. I think it's something that only certain apps should reveal.

> -  retouch in the printer space is a habit I fell into for my exhibition prints.

I think this is fallout from working with crappy drivers, and possibly also not such great profiles built for use with crappy drivers. And early on in this whole adventure we did have some pretty crummy "raw" color modes from manufacturer drivers. Still have this in some cases.

> -  When printing with Gutenprint I find I often prepare files on a Mac, use Photoshop to do color conversions, and then move the file onto Linux *just* for the final print which is thus made as if the print were a target. 

OK but I think we're talking about a workflow of 1-5 people on the whole planet. I don't think we can build an opt-out system that's going to allow you to opt-out of every single application. This is why this opt-out vs opt-in question is rather important to establish. But I don't see why the opt-out would be needed in a web browser or some new photo portfolio tool. These things should just work correctly for display and print. I don't see how you'd even use them for printing targets. It's like using a pasta rolling machine as a refrigerator. I'm only seeing incongruence.

> - I I always have countless small problems with targets, want to move them around on the paper or legend them so I remember what they are. These mods are best done in the GUI with the same type of app that is usually employed for layout and printing. 
>  Look, you may have a different workflow, and you can have a special target printing app for all I care; I would like to be able to print my targets from the GIMP.

I think the Gimp will need to implement the opt-out themselves. I remain unconvinced the the opt-out mechanism should be in the CPD for every single application. I see no reason why the Gimp would not subscribe to this opt-out for printing targets or prematched content. That would be the whole point of the opt-out system.

Chris Murphy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/openicc/attachments/20110504/643614ae/attachment.htm>

More information about the openicc mailing list