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
signature.asc
Description: This is a digitally signed message part.
