Please keep replies on the list.

Am Montag, 26. September 2016, 22:09:51 CEST schrieb Graham White:
> On 23/09/16 11:59, Tobias Ellinghaus wrote:
> > Am Donnerstag, 22. September 2016, 21:09:41 CEST schrieb Graham White:
> > 
> > [...]
> > 
> >> And I have done some reading of the Darktable source code, which is much
> >> more illuminating than the manual, and that seems to indicate that
> >> Darktable expects to do all the colour management itself.
> >> 
> >> At which I can only think "why?". Because Darktable is really good in
> >> other respects, and this is clearly a bad design decision, because it is
> >> terribly unmodular. Unix/Linux expects software to be modular, to do one
> >> job, and to communicate using well defined interfaces to other software
> >> in order to do other jobs. And the ICC colour profile specifications
> >> basically specify a pipeline, at each stage of which you know the
> >> correspondence between the internal representation of colour and some
> >> standardised representation of colours (Lab in practice). So that all a
> >> program should do is to be able to export a file in such a way that the
> >> next stage in the chain knows what colours the file represents, and that
> >> ought to be equally true of writing to a file or sending data to a
> >> printer (in fact, Linux treats the two exactly the same).
> > 
> > darktable takes the input image's color profile into account when reading
> > a file and exports to a user selectable color space. What in that
> > pipeline isn't exactly like what you want there? "Darktable expects to do
> > all the colour management itself" doesn't make any sense as there is no
> > way to NOT do colour management when doing more than colour agnostic
> > changes like cropping. You can just do it right or wrong. So could you
> > please elaborate on what you mean there? I have the feeling that we have
> > some misunderstanding going on.> 
> >> So what on earth is going on here?
> >> 
> >> Graham
> > 
> > Tobias
> 
> I think there is a difference between exporting and printing.

Ah, you were referring to printing here. I have to admit that I don't own a 
printer so I have no experience with that.

> Darktable's behaviour in exporting is different from its behaviour when
> printing: when it exports, it does the right thing, because I can then
> take the file which it exports and print it using another application,
> and get good results.

Good. :-)

> However, if you look at the source code, and, in particular, the file
> common/cups_print.c, there is a function dt_print_file, and on lines
> 344ff of the function body, you will find the following:
> 
> ----------------------------------------------------------------------------
> --
> 
>   // disable cm on CUPS, this is important as dt does the cm
> 
>   if (*pinfo->printer.profile)
>     num_options = cupsAddOption("cm-calibration", "true",
>                     num_options, &options);
> 
> ----------------------------------------------------------------------------
> - I take the comment to mean "disable colour management on CUPS, this is
> important as Darktable does the colour management".
> 
> So: you can switch CUPS colour management on or off, depending on where
> you want colour management to happen. But you can make a choice. And
> darktable always switches it off. If, however, you want to use a RIP
> (maybe because you like the way it does colour management), then you
> want the RIP to do the colour management: your application will drive
> the RIP using the CUPS protocol, and you want to be able to switch off
> colour management in the application.

As I see it, there is no unmanaged image in darktable. It always has to be 
transformed to _something_. The reason we disable it in CUPS is that more 
often than not the CUPS settings are at least bogus or even wrong, and having 
all settings in one place is easier to manage. So what you are basically 
asking for is darktable exporting to a specific profile and then keeping CUPS 
color management on? Maybe Pascal Obry can chime in here as he wrote all the 
printing code.

> Graham

Tobias

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to