Feature Request: darktable-cli Coordinate Input for Color Correction about darktable HOT 6 OPEN

darktable-cli isn't designed to deal with module paramters directly - it needs a xmp or a style file for that. But those xmp files just stores the results, not information how the results were generated.
Having a fixed color checker position in an image that doesn't require interaction also seems to be an edge case, so don't hold your breath waiting for that.

from darktable.

Could you maybe elaborate on the workflow - where the coordinates would come from? Some other external GUI? Auto-detected somehow? Or are they fixed (how often does it happen in real life?)?

from darktable.

Dear darktable-dev Team,

Thank you for your responses and for considering my proposal. I'd like to provide more details regarding the workflow and how the coordinates for the ColorChecker position could be obtained automatically.

Workflow:
The idea behind this enhancement is to simplify the color correction process, especially for users dealing with a large number of images in batch processing scenarios. Here's how the workflow could work:

1. Image Preprocessing: Users would start by preparing their images, ensuring they contain a ColorChecker or a similar reference chart for color correction.

2. Automatic Detection: Before running darktable-cli, an external script or tool could be used to automatically detect the position of the ColorChecker within each image. This detection could be based on pattern recognition, edge detection, or other computer vision techniques. Alternatively, users could specify the position manually for images where automated detection is not feasible.

3. Coordinate Input: The detected or manually specified coordinates would then be passed as input parameters to darktable-cli along with the image file paths and other processing parameters.

4. darktable-cli Processing: darktable-cli would use these coordinates to perform color correction.

5. Output: The processed images would be saved with the color corrections applied, and users can continue their workflow with the corrected images.

Benefits:

• Efficiency: This workflow would significantly streamline color correction for users handling a large number of images, eliminating the need for manual GUI interaction.
• Consistency: Automatic detection ensures that color correction is consistently applied across multiple images, reducing the risk of human error.
• Flexibility: Users can choose between automatic detection or manual specification of ColorChecker coordinates, providing flexibility for various scenarios.

I hope this clarifies the workflow and the potential benefits of this feature. If you have any further questions or suggestions for how this could be implemented more effectively, I'm eager to hear your thoughts.

Thank you for your continued consideration.

Best regards,
Pierre

from darktable.

Why not start with the first step - the tool doing the autodetection?
As long that isn't in place there's no benefit in a massive functional enhancement of darktable-cli.
Even if that autodetection function is done it's better to integrate this to the gui function...
Switching from gui for partial processing and then to some commandline tools to do color corrections that affects the pixel pipe burned into a xmp files doesnt seem to be a efficient, consistent and flexible solution. It sounds more like complex way to shot yourself into your foot ...

from darktable.

I completely agree that integrating the autodetection function into both darktable-gui and darktable-cli could be a valuable addition. It's crucial to strike a balance between automation and flexibility in image processing workflows.

The challenge with integrating autodetection into darktable-gui directly is that it might limit flexibility when it comes to detecting different types of color checkers. If someone wants to add support for a new type of color checker, it would likely require training a model specifically for that checker, which could be a complex and time-consuming task.

On the other hand, relying on more straightforward image processing tools for autodetection might be less accurate but could provide greater flexibility. Users could adapt these tools to their specific needs, even if they're working with unconventional color checkers or setups.

So, perhaps a balanced approach would be to integrate a default autodetection tool within darktable to make it user-friendly and accessible out of the box. Still, at the same time, allow users the freedom to customize or extend autodetection capabilities as needed. This way, users who have straightforward color checker setups can benefit from an easy-to-use solution, while advanced users can tweak the detection process to their requirements.

While darktable-cli may not have been initially designed for this kind of automation, It might be an area for potential growth and development within the darktable ecosystem.

Finding the right balance between automation and flexibility is key to addressing the needs of a wide range of users in the field of color correction, and it's an exciting area for exploration and potential improvement in darktable's functionality.

from darktable.

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.

from darktable.