On 27/09/16 10:14, Tobias Ellinghaus wrote:
> 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_.
Agreed
> 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.
yes, that's what I want.
Thanks
Graham
>
>> Graham
>
> Tobias
>
--
Graham White
Electronic Engineering and Computer Science
Queen Mary, University of London
http://www.eecs.qmul.ac.uk/~graham
____________________________________________________________________________
darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
