Thanks! It's appreciated!
Color matching algorithm and color transfer for film and photography
- Thread starter Menno Dreischor
- Start date
Thanks! It's appreciated!
Here is an example I did for shot matching a little while ago.
Left column is unmatched, right column is matched.
Don't take it as a final, approved look. As the shots progress towards evening, it would of course make sense to follow the time of day in the grade. The exercise was in seeing how well the algorithm could be used to do shot matching across a sequence, ironing out differences and creating consistency.
Left column is unmatched, right column is matched.
Don't take it as a final, approved look. As the shots progress towards evening, it would of course make sense to follow the time of day in the grade. The exercise was in seeing how well the algorithm could be used to do shot matching across a sequence, ironing out differences and creating consistency.
If you have been following this thread, you may know that the algorithm was originally meant for color restoration.
Menno has since discovered several other use cases where the algorithm proves quite powerful.
But just like asking an llm to count r's in strawberry or draw an svg of a pelican riding a bicycle, you will always be able to find edge cases or examples where things fall apart. This of course, does not detract from the overall usefulness of llm's and that's also the case with Menno's algorithm.
It's not a magic one-click-done solution (well, sometimes it is) and there is a learning curve to creating great matches.
My guess is that some people will try and test the algorithm using known test images and seeing how well the algorithm can match a log image to its DRT'ed r.709 (I know I'm one).
Here we have a test image in REDWideGamutRGB/Log3G10, used as a source:
This is with OpenDRT 'Standard' used as the reference:
This is the matched result:
This is with OpenDRT 'Umbra' preset used as the reference:
This is the matched result:
This is the matched result when cropping to a specific region:
Menno has since discovered several other use cases where the algorithm proves quite powerful.
But just like asking an llm to count r's in strawberry or draw an svg of a pelican riding a bicycle, you will always be able to find edge cases or examples where things fall apart. This of course, does not detract from the overall usefulness of llm's and that's also the case with Menno's algorithm.
It's not a magic one-click-done solution (well, sometimes it is) and there is a learning curve to creating great matches.
My guess is that some people will try and test the algorithm using known test images and seeing how well the algorithm can match a log image to its DRT'ed r.709 (I know I'm one).
Here we have a test image in REDWideGamutRGB/Log3G10, used as a source:
This is with OpenDRT 'Standard' used as the reference:
This is the matched result:
This is with OpenDRT 'Umbra' preset used as the reference:
This is the matched result:
This is the matched result when cropping to a specific region:
I've been thinking about this too while following the thread a bit. Cool to see some examples with decent success at first glance.
I'd be curious once such a DRT is 'matched', how does grading underneath it behave? (expose up/down a few stops etc) Similar to the referenced DRT?
I also thought about if the algorithm would be capable to have a (graded) Rec.709 image as reference but be tasked to apply a transformation on log data while a conversion to Rec.709 is already applied to it next in the chain. My guess is currently no, as it likely does not look at it's own result relative to a different output to compare whether it made correct decisions?
Also curious. What is the result if you crop the reference region to the color checker only, and another cropping to the color checker + just enough to see 1 of the bright bulbs above the mirror?
To the eye the immediate mismatch in your examples seems the 'density' of the red patch which is darker in reference, and for the cropped test the light bulbs, understandably, as it did not receive any input on what to do with 'brighter' data compared to reference.
Last edited:
Depending on the match, it's not that different. On the projects I have used it on, the plugin sits at the end of my node tree and I grade upstream of it. But I have not been using it exclusively as a DRT and it's not really designed with that in mind.
I get that, and it's also something I have been trying to create a workflow for. We want a log-log workflow down the line, as that gives the most flexibility. There's an intuitive desire to want to match an sRGB/r.709 reference to a log image and have the resulting match be in log space as well. That's not inherently achievable as such.
One method I found, if one wants to match a shot to a reference from Shotdeck for example, is to to do a CST on the reference to make it pseudo-log. It's not perfect but works quit well from my own testing. That way, you can stay in log and use your preferred flavour of DRT.
For straight up matching log to log that's not a problem.
I tried that as well and got a similar result. The algorithm is not really designed with any intention of matching color charts so it's not something it can do perfectly. Isolating a single color though will create a 100% match to that specific color (though it will of course screw up the rest of the image)
Red patch from full image match:
Match when cropping to the red patch only for the source and reference:
Thanks for sharing!
I understand it's purpose is not to be a DRT. I just think it is an interesting side effect if it is able to hold itself well under such a task.
Yea I figured that would be an approach after thinking about it some more.
Yea makes sense. I was just wondering whether it would be able to better pick up that red color without drifting away from the overall match, given most other colors were visually much closer.
I would like to take this opportunity to thank Christian for his efforts over what has now been almost a year of cooperation. This project began many years ago as a method to restore the colors of scans of ageing film prints. Over the last two and a half years it has evolved from what initially was presented as an image processing algorithm to a phenomological model that is able to capture some aspects of color perception. However, I'm at heart a scientist, and what was missing was the colorist perspective on color matching, and some much needed business acumen. So, over the past year much has been achieved with regards to a professional workflow rooted in many years of color grading experience amongst other things. I can't wait for all of you who have been following this thread, and expressed interest in the algorithm to find out what Christian has built!
Last edited:
Silent observer here. I first became aware of it through Petr Harmy back then, and I’ve occasionally browsed through this thread.
I'm glad to see this project coming to its well deserved closure, and I'm excited to see what’s coming.
I'm glad to see this project coming to its well deserved closure, and I'm excited to see what’s coming.
Thanks for chiming in, it really boosts morale!
It's no secret that we are not the only player in the color matching game.
Resolve, Premiere and Final Cut have their own built in color matching tools and there is a small selection of plugins out there as well.
While you sometimes get something useful out of them, more often than not it's a roll with the dice and you are pretty much locked to whatever result you get back.
Besides being a lot more (technically) accurate, our solution also allows for more tweakability when doing matches, such as choosing an appropriate model, adjusting smoothness and cropping.
Here is an example with using our plugin, Resolve's color match tool and a paid 3rd party solution.
Baseline source/ref:
Resolve's built in color match tool:
3rd party paid tool:
Our plugin:
While no other processing was involved, in all fairness, as our solution has adjustable parameters, you don't always get the optimal match without doing a little work yourself.
Here are two other matches I did as well for this source + ref.
Alternative 1:
Alternative 2:
Resolve, Premiere and Final Cut have their own built in color matching tools and there is a small selection of plugins out there as well.
While you sometimes get something useful out of them, more often than not it's a roll with the dice and you are pretty much locked to whatever result you get back.
Besides being a lot more (technically) accurate, our solution also allows for more tweakability when doing matches, such as choosing an appropriate model, adjusting smoothness and cropping.
Here is an example with using our plugin, Resolve's color match tool and a paid 3rd party solution.
Baseline source/ref:
Resolve's built in color match tool:
3rd party paid tool:
Our plugin:
While no other processing was involved, in all fairness, as our solution has adjustable parameters, you don't always get the optimal match without doing a little work yourself.
Here are two other matches I did as well for this source + ref.
Alternative 1:
Alternative 2:
when can we expect this to be released? 
when can we expect this to be released?
There is no date as yet, as there are a lot of variables, but testing and development have been steady and purposeful.
