camicc: converting Adobe's DCP profiles to ICC for darktable

[rvietor]

@Donatzsky

And as long as the resulting profiles aren’t distributed, they probably don’t care about this either.

And that is the key point: distribution. Private use of legally obtained files is allowed (and in any case hard to check/prevent). Same as with peer-to-peer: they don’t prosecute for the downloading, but for the uploading part of the process…

[finestructure]

@martinus

If I use the extracted ICC profile just for myself and don’t distribute it. But if I then distribute an image that is processed with the assistance of that profile… is that image then a derived work, and thus a violation of copyright… I don’t think so, but not sure…

Using a tool to produce a work never makes that thing a derived work, as far as I know, except in the case where the tool embeds a part of itself in what was created–that’s why runtime libraries meant to be bundled into executables are licensed very permissively, separately from the rest of the compiler.

@dark_photon It’s good to scratch an itch, but you should know you can do this manually by using dcamprof to convert the DCP to a profile, then convert the profile to an ICC.

Is this tool outputting LUT or matrix ICCs? I think LUT input ICCs are unsuitable for scene-referred workflows since they don’t handle extreme colors (and are not well supported in darktable). I think the normal method is to use a matrix-style ICC as the input and do any additional correction in the color calibration module.

[martinus]

@finestructure

Using a tool to produce a work never makes that thing a derived work, as far as I know, except in the case where the tool embeds a part of itself in what was created–that’s why runtime libraries meant to be bundled into executables are licensed very permissively, separately from the rest of the compiler.

But there is where layers get very nitty-gritty.

According to my understanding, an ICC is a matrix used in the process of calculating the colours from your image.

It is not the algorithm, no, it is input data.

So the resulting image is partially the result of multiplying the sensor data with the color profile. (I am know that I am over simplifying here).

So you can argue that it derived work.

It is not that I think that such an argument will hold in court, but I don’t want to bet on it…

[rvietor]

@finestructure

Using a tool to produce a work never makes that thing a derived work, as far as I know, except in the case where the tool embeds a part of itself in what was created

That’s not even the point here. Here, the tool takes (possibly copyrighted) data, transforms it and writes output. That output might be a work derived from the input, but (the copyright status of) the tool is irrelevant in this case.

@martinus

It is not that I think that such an argument will hold in court, but I don’t want to bet on it…

Exactly…

[finestructure]

@martinus

It is not that I think that such an argument will hold in court, but I don’t want to bet on it…

You’re right. Even knowing the correct answer wouldn’t be that useful, because copyright is interpreted differently everywhere.

@rvietor

the tool takes (possibly copyrighted) data, transforms it and writes output.

Since we aren’t talking about publication in this example, first-sale doctrine would probably win over copyright. Meaning, if you lawfully own something, you can do whatever you want with it. I’m not a lawyer, though.

[rvietor]

@finestructure

Meaning, if you lawfully own something,

That’s another wrinkle: afaik, you don’t buy Adobe software, but a licence to use the sotfware, and such a license can come with restrictions on said use, restrictions to which you agreed in the contract…

But yeah, I misread, OP isn’t offering to distribute profiles, just the tools to generate them.

[dark_photon (Rafael)]

I tried dcamprof, but I could not get the expected results. The image was always super gray, and nothing like the expected thing. I read some old posts about using dcamprof, but still no success.
Then I ask AI to help use dcamprof, and it said that “dcamprof converts a DCP to ICC through its native profile format, which only has fields for the matrices — so the HueSatMap, LookTable, and tone curve that carry the entire “camera look” (contrast and saturation) are structurally dropped, leaving a flat, gray-ish colorimetric profile.” .
Also, dcamprof is 6 years without any updates, which made think I would be easier to just ask AI to make a similar too with this issue fixed. I went overboard and decided to automate the download, and extraction of the Adobe’s DCP, which is not convenient to do on Linux (install wine, etc).

As I said, I don’t know about this color science hacks, so I can say what the AI tells me: “LUT by necessity — the DCP’s look lives in 3D tables no matrix can express”.

I will investigate more if this is an issue.

[dark_photon (Rafael)]

I appreciate the discussion if I could get in trouble about this tool.

But besides the automated download of the Adobe DCPs, is my tool doing something fundamentally different than what Rawtherapee does when it interprets Adobe’s DCP (which the user manually downloaded)?

If not, then I will sleep fine knowing I am not doing something so different than some people already do with Rawtherapee (and Rawtherapee itself explains how to do it).

[finestructure]

@dark_photon

I will investigate more if this is an issue.

For me, the quick test is editing a photo with very high dynamic range, such as a photo of a sunset, or anything with sunlight on light colored things, and dark color in shadows. In my tests with LUT input profiles from dcamprof, the highlights change color and lose all contrast. Other people on this forum have posted issues as well.