darktable
darktable copied to clipboard
darktable-org
Support .dcp color input profiles
Hi,
Because I didn't find any topic about .dcp input color profiles I submit suggestions for adding this feature do Darktable.
This issue did not get any activity in the past 30 days and will be closed in 7 days if no update occurs. Please check if the master branch has fixed it since then.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
I agree, DCP support would be greatly appreciated. I know darktable has darktable-chart for doing color calibrations, and supports ICC profiles, but DCP profiles are much more flexible and increasingly common. A simple search on google for darktable dcp support shows this is a commonly desired feature for darktable, so I think most users would find it a very welcome addition.
This issue did not get any activity in the past 60 days and will be closed in 365 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.
This auto-close action is really annoying for feature requests. There is not much to discuss at the moment. That feature would be nice to have. It will remain "nice to have" until it is implemented.
@ccoenen Can you tell me what exactly annoys you so much about the actions of this bot? Perhaps I can change the text of the bot's message so that the purpose of its work is more clear.
This is not limited to darktable, I may have reacted somewhat harshly because I get auto-close-bot messages on a weekly basis from all kinds of issues I'm subscribed to.
I don't think auto-closing feature requests is a good idea in general (not just in this project). I can see the usefulness of auto-closing for some purposes. Issues raised that are actually support tickets and such. And I know from first hand experience that an issue tracker is no fun at all if there are thousands of open tickets.
For feature requests, though I think any of these would be preferable to some bot:
- tagging this with
help wantedorup for grabsor whatever. If maintainers don't intend to implement this themselves but are generally open for this feature. This should exclude it from auto-closing at the same time or extend the times considerably beyond 60 days. It also communicates "this is not coming, unless someone steps up and does it" which may or may not help recruit other people. - tagging this with
next versionorbacklogor putting it on some future milestone - if the maintainers intend to work on this themselves. This should also exclude it from some auto-closing bot. - closing the issue manually, if maintainers do not intend to work on this and also don't really invite outside contributions. For example, when this is not aligning with their vision of the project.
This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.
This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.
This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.
It seems than the bot is the most active participant in this thread so far...
@kanyck : Do you want to take the lead on this project? The bot is active all the days and we are just a bunch of developers. If you have nothing more to offer please let the issue be closed by the bot.
FWIW, I think that auto-closing issues (and the related warnings from the bot) is a bad policy. A lot of successful FOSS projects have outstanding issues that have been open for years, if not decades. This does not mean that they are irrelevant, and won't be fixed at some point. Even if the OP cannot fix them, someone may come along in due course, or find a host of related issues when doing a refactoring, etc.
I understand that having a lot of open issues can be disheartening as a maintainer, but it is effectively harmless when handled appropriately. Labeling, periodic culling and re-triage of issues is a much better policy. See eg this recent discussion at Kubernetes and their subsequent solution.
DCP support would be great since camera "style" .dcp´s from Adobe are already available for almost all cameras (e.g. standard, vivid...)
For all of you that find this so important and useful, it would probably be a good idea if you could actually explain why and how it would fit in your workflow (which none of you have done so far). Unless the developers see a clear benefit, it's unlikely to get implemented.
@Donatzsky: because it saves work, as one could just grab an existing DCP profile for a camera without calibrating it manually. See eg the third reply by @abnormally-distributed above.
I've bought specific camera profiles and these were delivered as DCP files.
I have a camera in my ZenFone 8, which can shoot in raw format with OpenCamera. The resulting DNGs do not look anything like the jpgs at all. I have created DCP files with the adobe tool and my hope is that this would make processing these DNGs much simpler.
As @Donatzsky said, you want it but where this could be supported in dt workflow? No one give a way to properly add support for DCP in current darktable. Maybe in color calibration ? A bit like what is done with "calibrate with a color checker" ?
Maybe I'm wrong, but I don't think DCP is (readily) compatible with dt's current scene-referred workflow to begin with?
Perhaps w/ the legacy display-referred one, e.g. mapping ProfileToneCurve to base curve, and ProfileHueSatMapData and ProfileLookData to two LUT instances, but not sure dt even has an HSV working color space for those?
But even before thinking about DCP, dt doesn't support dual/triple illuminant input profile interpolation, which is a pre-requisite for it IMHO. That would in turn probably mean a big refactoring of color calibration (everything is relative to D65 currently)...
So, not a trivial request by any means.
@ccoenen
I have a camera in my ZenFone 8, which can shoot in raw format with OpenCamera. The resulting DNGs do not look anything like the jpgs at all. I have created DCP files with the adobe tool and my hope is that this would make processing these DNGs much simpler.
Have you tried to take a picture of a color checker and use the "calibrate with a color checker" in Color Calibration ? Should be a good alternative and already supported.
See https://docs.darktable.org/usermanual/4.4/en/module-reference/processing-modules/color-calibration/#extracting-settings-using-a-color-checker
@TurboGit: the appropriate place for this in the workflow would be where the color matrix is applied, in input color profile.
Yes, people can use a color checker. But that has two downsides:
-
They might not have one available. Yes, they are not expensive, but not cheap either, and need to be carried to a scene.
-
You cannot reuse results for different light conditions, so you have to calibrate again and again.
Just grabbing the matrix from a DCP file is a quick & dirty solution to profiling your camera, at least as a first pass. But given that no input matrices were added in the last 7 years or so, it may be the best one for some people. RawTherapee also has a bunch of DCP files which Darktable users could just grab and use.
Just grabbing the matrix from a DCP file
The input matrices for all currently supported cameras come from the DNG conversion, i.e. they are equivalent to the "Adobe Standard" DCP matrix already (the D65 one is used only).
no input matrices were added in the last 7 years
We're adding those all the time.
You're confusing this w/ custom calibration matrices. Those are not even used any more AFAIK.
AFAIK DCP profiles have a clear advantage over ICC in this: ICC is a one-point measurement, so it must be re-calibrated every time the light conditions are changed (which is not only a lot of fiddling. The light may change very fast, so you may have to re-calibrate every few minutes!) From the other side DCPs are two-pointed, so there is an opportunity to extrapolate between two points (and somewhat beyond). Yes, it's not ideal, but from my POV is much better than 1-point anyway. ICCs are quite enough for studio, but for outdoor shooting DCPs fit much better. And yes, there are lots of broken profiles out there but this does not mean that there are no good ones. I use ART along with DT and find DT more convenient and feature-rich, but I have to use ART because of two things: DCP profiles and pixel-shift support. So to say, DT is my main tool (95+% of use) but when I need to get right colors under tough light conditions or the pixel-shift support, I need ART. But I'd like to shift solely on DT, because workflows are quite different between the two, and I have to adapt back and forth. And DT is much more familiar to me, I use it since v0.6.
I have a camera in my ZenFone 8, which can shoot in raw format with OpenCamera. The resulting DNGs do not look anything like the jpgs at all. I have created DCP files with the adobe tool and my hope is that this would make processing these DNGs much simpler.
Have you tried to take a picture of a color checker and use the "calibrate with a color checker" in Color Calibration ? Should be a good alternative and already supported.
See https://docs.darktable.org/usermanual/4.4/en/module-reference/processing-modules/color-calibration/#extracting-settings-using-a-color-checker
@TurboGit I have not, but I will take a look! Thank you for mentioning this, I haven't come across this particular way, yet!