Following the Model Comparison analysis (concluded today) included in the README, which confirmed the positive effect of model combination I changed the default values of parameters used by the function ddeoldify(). Now the dd_weight is set equal to 0.5 by default. Please pay attention to the fact that in the version of DDColor I changed the range of values of dd_strength to be equivalent to the render_factor in Deoldify (now both parameters have default value = 24). You should change the GUI using the new defaults, the parameter dd_strength should be named strength or even better render_factor and not input size as now. In the new version the relationship between render_factor and input size is the following
input_size = render_factor * 16
In effect both the parameters are related to the resolution used to perform the inference, bigger values implies that the inference is using a bigger matrix, improving the quality of the inference, but slowing down the encoding process. A good range for these parameters, that do not slow down too much the encoding (of course it depends also on the available GPU) is between 23-33.
(06.03.2024, 17:12)zspeciman Wrote: @Dan64, that was a nice test you run. I was colorizing some photos and videos as well to see the difference. DDcolor photo images are stunning, but in the videos, in some parts it works very well (more robust color than standalone DeOldify) and in others parts more like the 60s psychedelic colors. The merge concept is a brilliant idea to combine the stability of DeOldify with the the color pop of DDcolor
I also observed this effect, I noted that happen more frequently on dark scenes, I'm working on a solution to remove this effect, probably an adaptive merge could solve the problem.
Dan
(06.03.2024, 17:12)zspeciman Wrote: 1. In DDcolor, what is Input size about? FP16? Artistic Model vs ModelScope?
2. I wasn't sure what Streams settings was about either, but when I changed 1 to 4, the video had a several corrupted images, so I stuck to 1
3. In DeOldify with Simple Merge enabled, in the DDcolor settings on the right, what does that input size about?
You might note somewhere what version works with what Hybrid release, since the current public release does not work with v1.1.5 as expected. Also, current torch addon does not come with v1.1.5.
Cu Selur
----
Dev versions are in the 'experimental'-folder of my GoogleDrive, which is linked on the download page.
I found a way to stabilize DDColor, with a method that I called AdaptiveMerge, the problem is that is too slow.
Using this method the encoding speed is reduced by 50% and this method is very simple, I was unable to find a way to speed up the computation.
I don't know very well Vapoursynth and the available documentation is "poor". Maybe there is a way to get a faster encoding...
The current code is the following
Since DDColor on dark scenes shows a psychedelic effect (try to use it with the attached video), the adaptive merge "weight" the weight_merge parameter by the brightness of the image.
In order to not penalize too much DDColor I multiply this value by 1.2.
For example if the brightness is 45% and the weight_merge is 50% the effective weight used in the merge is given by = 50%*(1.2*45%) = 27%
This computation must executed at frame level.
Do you have any idea on how it is possible to speed up the function AdaptiveMerge3 ?
08.03.2024, 04:42 (This post was last modified: 08.03.2024, 04:47 by Selur.)
Got a few ideas how to speed that up, not sure whether it will work.
Will look at it after work.
What Formats are clipa and clipb you feed to AdaptiveMerge3, some more context how you use it would be helpful.
Cu Selur
----
Dev versions are in the 'experimental'-folder of my GoogleDrive, which is linked on the download page.
But I'm not happy about this solution, because is only a patch to DDColor.
I'm thinking to develop a Temporal Chroma Smoother for DDColor, but I still have to find a way on how implement it.