Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

better lut3d placement in the pipeline #3108

Closed
jakubfi opened this issue Oct 9, 2019 · 4 comments
Closed

better lut3d placement in the pipeline #3108

jakubfi opened this issue Oct 9, 2019 · 4 comments
Labels
feature: enhancement current features to improve no-issue-activity scope: image processing correcting pixels
Milestone

Comments

@jakubfi
Copy link
Contributor

jakubfi commented Oct 9, 2019

Related to issue #3062

If we consider how the available GMIC LUTs are supposed to be used, default lut3d module placement in dt's pipeline should be different. I'd say it should go right before colorout. Take a look at the following examples prepared using one of GMIC LUTs with various software:

Image processed with rt's film simulation:
s-example_rt
Image processed with dt's lut3d (current placement)
s-example_dt_lut_basecurve
Image processed with dt's lut3d (fixed placement - right before colorout):
s-example_dt_basecurve_lut
And, for reference, unprocessed image ("clean" edit exported from dt) put through LUT with GMIC:
s-example_gmic

@jakubfi
Copy link
Contributor Author

jakubfi commented Oct 9, 2019

P.S. I've checked the module order once more. Before monochrome would be a better placement for lut3d, or maybe even before color reconstruction - I'm not sure about that one.

@junkyardsparkle
Copy link
Contributor

junkyardsparkle commented Oct 9, 2019

Doesn't this depend quite a bit on specific use case? The LUT is a fixed transform, so I would tend to think it would make more sense early in the pipe, allowing following modules to perform further action on its output. If you only want the effect of the LUT, it doesn't really matter where it is, because you won't have other stuff enabled. ;-)

(TBH, my insight is limited here, because I don't really see the point of using something so primitive in software with so many other, more flexible color tools... OTOH, I have used darktable to produce haldcluts for use in ffmpeg, etc; I think of them as more useful in that workflow - using a software which makes adjustment easy to apply a transform in software which doesn't).

@jakubfi
Copy link
Contributor Author

jakubfi commented Oct 10, 2019

@junkyardsparkle You're correct about this depending on a use case. My concern is that lut3d is most likely going to be used for applying GMIC LUTs, which are well-known and readily available, and this is going to be the main use case here. For this to work correctly out of the box lut3d shoud be later in the pipe, so that most users get the desired results instead of "this looks weird".

In other words: lut3d position in the pipe isn't fixed by definition. Some users will have to change its position anyway. I would like to allow most users get good results easily, and leave messing with the pipe order to (most likely) more knowledgeable users.

Either way it should be made very clear (only doc? or maybe popup hints?) that lut3d position may need adjusting depending on the type of LUT used.

@jakubfi jakubfi changed the title lut3d is misplaced in the pipeline better lut3d placement in the pipeline Oct 10, 2019
@github-actions
Copy link

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.

@johnny-bit johnny-bit added feature: enhancement current features to improve scope: image processing correcting pixels labels Sep 5, 2021
@johnny-bit johnny-bit added this to the 3.8 milestone Sep 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature: enhancement current features to improve no-issue-activity scope: image processing correcting pixels
Projects
None yet
Development

No branches or pull requests

3 participants