[Printing-architecture] Any news regarding colour management?

[Printing-architecture] Any news regarding colour management?

[Kai-Uwe Behrmann]

Is anyone working on integrating colour management in CPD regarding

* ICC profile selection,
* profile passing back to applications, and maybe
* other stuff?


kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org

Re: [Printing-architecture] Any news regarding colour management?

[Tim Waugh]

[-- Attachment #1: Type: text/plain, Size: 399 bytes --]

On Thu, 2011-01-06 at 10:18 +0100, Kai-Uwe Behrmann wrote:
> Is anyone working on integrating colour management in CPD regarding
> 
> * ICC profile selection,
> * profile passing back to applications, and maybe
> * other stuff?

I'm working on colour management at the moment, not in CPD, but in CUPS.

Take a look at this:
http://blogs.gnome.org/hughsie/2011/01/05/colord/

Tim.
*/


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: [Printing-architecture] Any news regarding colour management?

[Kai-Uwe Behrmann]

Am 06.01.11, 09:28 -0000 schrieb Tim Waugh:
> On Thu, 2011-01-06 at 10:18 +0100, Kai-Uwe Behrmann wrote:
>> Is anyone working on integrating colour management in CPD regarding
>>
>> * ICC profile selection,
>> * profile passing back to applications, and maybe
>> * other stuff?
>
> I'm working on colour management at the moment, not in CPD, but in CUPS.
>
> Take a look at this:
> http://blogs.gnome.org/hughsie/2011/01/05/colord/
>
> Tim.
> */

What are you doing inside CUPS?

Do you plan or write a generic C interface any system or independent 
application can have access to?


kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org

Re: [Printing-architecture] Any news regarding colour management?

[Tim Waugh]

[-- Attachment #1: Type: text/plain, Size: 480 bytes --]

On Thu, 2011-01-06 at 10:33 +0100, Kai-Uwe Behrmann wrote:
> What are you doing inside CUPS?

CUPS needs to register ICC profiles with colord for each printer queue,
so that colord can associate ICC files with them.  This way a user can
choose an arbitrary profile without having to modify the PPD file.

> Do you plan or write a generic C interface any system or independent 
> application can have access to?

Yes, colord already has a D-Bus interface.

Tim.
*/


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: [Printing-architecture] Any news regarding colour management?

[Kai-Uwe Behrmann]

Am 06.01.11, 09:53 -0000 schrieb Tim Waugh:
> On Thu, 2011-01-06 at 10:33 +0100, Kai-Uwe Behrmann wrote:
>> What are you doing inside CUPS?
>
> CUPS needs to register ICC profiles with colord for each printer queue,
> so that colord can associate ICC files with them.  This way a user can
> choose an arbitrary profile without having to modify the PPD file.

If the PPD shall not be changed, for what needs CUPS to interact 
with a external daemon? It is already now possible to fetch the PPD from 
CUPS. We do this in the CUPS ICC module for Oyranos for instance.

How shall the CMS and CUPS interact in your plans?

>> Do you plan or write a generic C interface any system or independent
>> application can have access to?
>
> Yes, colord already has a D-Bus interface.

DBUS is not a C interface. As well many applications will reject to use 
D-Bus as its is overkill. I would not consider it an appropriate 
replacement for a generic C interface.


kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org

Re: [Printing-architecture] Any news regarding colour management?

[Tim Waugh]

[-- Attachment #1: Type: text/plain, Size: 1178 bytes --]

On Thu, 2011-01-06 at 11:10 +0100, Kai-Uwe Behrmann wrote:
> If the PPD shall not be changed, for what needs CUPS to interact 
> with a external daemon? It is already now possible to fetch the PPD from 
> CUPS. We do this in the CUPS ICC module for Oyranos for instance.
> 
> How shall the CMS and CUPS interact in your plans?

The pstoraster print filter will retrieve the correct ICC file and tell
ghostscript to use it.

> >> Do you plan or write a generic C interface any system or independent
> >> application can have access to?
> >
> > Yes, colord already has a D-Bus interface.
> 
> DBUS is not a C interface. As well many applications will reject to use 
> D-Bus as its is overkill. I would not consider it an appropriate 
> replacement for a generic C interface.

Well, yes, you could write it as a proper asynchronous C interface, but
you would have to reinvent a lot of stuff.  Then if you want to run it
from a shell script or from some other language, you'd need to write a
command line front-end or language bindings.

But with D-Bus, it is already callable from C, Python, the shell, etc,
synchronously or asynchronously.

Tim.
*/


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: [Printing-architecture] Any news regarding colour management?

[Kai-Uwe Behrmann]

Am 06.01.11, 10:18 -0000 schrieb Tim Waugh:
> On Thu, 2011-01-06 at 11:10 +0100, Kai-Uwe Behrmann wrote:
>> If the PPD shall not be changed, for what needs CUPS to interact
>> with a external daemon? It is already now possible to fetch the PPD from
>> CUPS. We do this in the CUPS ICC module for Oyranos for instance.
>>
>> How shall the CMS and CUPS interact in your plans?
>
> The pstoraster print filter will retrieve the correct ICC file and tell
> ghostscript to use it.

Indeed, that will be very useful. Can you imagine to have that in a 
generic way, so more CMS's can utilise that capability?

The reason I ask is that Oyranos CMS provides already a lot for 
configuring and colour managing the desktop and devices. Its going to be 
integrated into KDE, can run standalone with Xorg or in small devices. So 
the Oyranos project would be interessted to hook as well into CUPS and 
tell pstoraster, which ICC profile to use for printing.

>>>> Do you plan or write a generic C interface any system or independent
>>>> application can have access to?
>>>
>>> Yes, colord already has a D-Bus interface.
>>
>> DBUS is not a C interface. As well many applications will reject to use
>> D-Bus as its is overkill. I would not consider it an appropriate
>> replacement for a generic C interface.
>
> Well, yes, you could write it as a proper asynchronous C interface, but
> you would have to reinvent a lot of stuff.  Then if you want to run it
> from a shell script or from some other language, you'd need to write a
> command line front-end or language bindings.
>
> But with D-Bus, it is already callable from C, Python, the shell, etc,
> synchronously or asynchronously.

I have nothing against D-Bus as is. But is it relly needed in that 
context? I guess not. A simple convention can reach the same effect and 
remains open for a heterogenous environment.


The task is to
* create a request with meta information (e.g. PPD) to get ICC
* send and wait for an answere from command line tool, C interface ...
* get the answere and translate it to a ICC profile
* use the ICC profile with ghostscript


kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org

Re: [Printing-architecture] Any news regarding colour management?

[Tim Waugh]

[-- Attachment #1: Type: text/plain, Size: 1925 bytes --]

On Thu, 2011-01-06 at 11:33 +0100, Kai-Uwe Behrmann wrote:
> Indeed, that will be very useful. Can you imagine to have that in a 
> generic way, so more CMS's can utilise that capability?

I think it's already pretty generic actually -- I don't think there's
anything in colord that ties it to any scheme in particular.  Really
it's just a small daemon to associate printer queues with ICC files.  I
imagine (but don't know for sure) that Oyranos CMS could add a small
hook into colord and that would be all that is required.

> The reason I ask is that Oyranos CMS provides already a lot for 
> configuring and colour managing the desktop and devices. Its going to be 
> integrated into KDE, can run standalone with Xorg or in small devices. So 
> the Oyranos project would be interessted to hook as well into CUPS and 
> tell pstoraster, which ICC profile to use for printing.

Yes, this is similar to how gnome-color-manager works I believe.

> I have nothing against D-Bus as is. But is it relly needed in that 
> context? I guess not. A simple convention can reach the same effect and 
> remains open for a heterogenous environment.

The associations between devices, profiles and ICC files are kept in a
running daemon which starts on first use, and this is managed by D-Bus.
I'm sure it could be done another way, but again it just seems the most
convenient already-implemented way.

Is this sort of system really likely to be needed on a system without
D-Bus installed?

> The task is to
> * create a request with meta information (e.g. PPD) to get ICC
> * send and wait for an answere from command line tool, C interface ...
> * get the answere and translate it to a ICC profile
> * use the ICC profile with ghostscript

That's part of it.  The other part is for the CUPS scheduler to register
colour profiles and ICC files with colord for each queue on start-up.

Tim.
*/


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: [Printing-architecture] Any news regarding colour management?

[Kai-Uwe Behrmann]

Am 06.01.11, 10:55 -0000 schrieb Tim Waugh:
> On Thu, 2011-01-06 at 11:33 +0100, Kai-Uwe Behrmann wrote:
>> Indeed, that will be very useful. Can you imagine to have that in a
>> generic way, so more CMS's can utilise that capability?
>
> I think it's already pretty generic actually -- I don't think there's
> anything in colord that ties it to any scheme in particular.  Really
> it's just a small daemon to associate printer queues with ICC files.  I
> imagine (but don't know for sure) that Oyranos CMS could add a small
> hook into colord and that would be all that is required.

Oyranos CMS had developed a very robust approach to select ICC profiles 
for all sorts of devices and drivers. This approach is flexible 
and integrates very well with existing ICC standards.

I see no signs that this will go into colord. So using colord is not an 
option for Oyranos CMS. As users will fall short compared to generaly 
careful, flexible and well integrated information handling in Oyranos.

>> The reason I ask is that Oyranos CMS provides already a lot for
>> configuring and colour managing the desktop and devices. Its going to be
>> integrated into KDE, can run standalone with Xorg or in small devices. So
>> the Oyranos project would be interessted to hook as well into CUPS and
>> tell pstoraster, which ICC profile to use for printing.
>
> Yes, this is similar to how gnome-color-manager works I believe.
>
>> I have nothing against D-Bus as is. But is it relly needed in that
>> context? I guess not. A simple convention can reach the same effect and
>> remains open for a heterogenous environment.
>
> The associations between devices, profiles and ICC files are kept in a
> running daemon which starts on first use, and this is managed by D-Bus.
> I'm sure it could be done another way, but again it just seems the most
> convenient already-implemented way.

It is not convenient to have a new unneeded dependency, when it can be 
done likewise without. The Posix shell is good and enough. D-Bus 
would be a bloated requirement for that simple task.

Please do not confuse this task with typical desktop systems. CUPS and 
Ghostscript are no desktop only software. The printing system needs to run 
on a wide variety of Linux configurations, where the desktop is only a 
small part of.

> Is this sort of system really likely to be needed on a system without
> D-Bus installed?

D-Bus a hard requirement on embedded systems and for servers?

>> The task is to
>> * create a request with meta information (e.g. PPD) to get ICC
>> * send and wait for an answere from command line tool, C interface ...
>> * get the answere and translate it to a ICC profile
>> * use the ICC profile with ghostscript
>
> That's part of it.  The other part is for the CUPS scheduler to register
> colour profiles and ICC files with colord for each queue on start-up.

Querying ICC profile, which are configured in a CUPS queue, is already 
solved in Oyranos. The CUPS C library calls are fine for that.

> Tim.
> */

kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org

Re: [Printing-architecture] Any news regarding colour management?

[peter sikking]

hey Kai-Uwe,

> Is anyone working on integrating colour management in CPD regarding
>
> * ICC profile selection,
> * profile passing back to applications, and maybe
> * other stuff?


we investigated color management a while ago when we dealt with the
photo printer cluster, then designed a solution:

<http://wiki.openusability.org/wiki/printing/index.php/Photo_printers_parameter_specifications#Color_Management_and_the_CPD 
 >

notice that now that the maximum-complexity solution is done, it is  
being
applied to other printer clusters, with the complexity scaled down where
the printer's product concept demands it.

     --ps

         founder + principal interaction architect
             man + machine interface works

         http://blog.mmiworks.net: on interaction architecture