Cool. If you’re into color grading, then at some point it could be interesting to discuss a suggested workflow for color grading with you, both for documentation and also for mapping out the current shortcomings in the toolset and the UI/UX.
I think I might not be the right person for that. I just tried to find a tool on Linux for editing some footage from my Lumix S5 camera and therefore started reading about the topic a bit. From my perspective at least, the technology behind it is only half of the story. A lot really is UI and how film- or human-eye-like the controls behave and so on.
But I guess the most important thing in Blender would be improving the responsiveness of the controls. Without any GPU acceleration (the integration of HIP might be a chance, but you can do all that also with OpenGL ES) working with 4K footage is currently really painful, even on a fast computer.
1 Like
@JosefR Congratulations on having your patch committed. I noticed two things:
- Opening an existing .blend and switching to the color processing of your patch makes all of the colors black(and the preview black). In a new file the default values seems okay.
- Comparing with the color node the offset value is black, but in the modifier in the sidebar it’s white. Does this make sense and everything is okay?
[quote="tintwotin, post:24, topic:19989]
@JosefR Congratulations on having your patch committed.
[/quote]
Thanks, my first one for Blender.
[quote="tintwotin, post:24, topic:19989]
- Opening an existing .blend and switching to the color processing of your patch makes all of the colors black(and the preview black). In a new file the default values seems okay.
[/quote]
I guess I have missed to set some correct default values somewhere. I will try to find where this has to be done.
[quote="tintwotin, post:24, topic:19989]
- Comparing with the color node the offset value is black, but in the modifier in the sidebar it’s white. Does this make sense and everything is okay?
[/quote]
I did that to allow applying negative offset values and having the slider in the middle position by default. Otherwise, you would have to select the “invert” button to get a negative offset.
Technically it is more correct to have black there by default because this is the rgb value that will be used for the offset. I am actually doing that by correcting the value from the widget:
if (cb.flag & SEQ_COLOR_BALANCE_INVERSE_OFFSET) {
cb.offset[c] = -1.0f * (cb.offset[c] - 1.0f);
}
else {
cb.offset[c] = cb.offset[c] - 1.0f;
}
For consistency with the compositor it might really be better to change that. But the compositor is using this “basis” field for offsetting the color value to achieve negative values as there is no “invert” option there. I am not sure which one is the best solution.