You are right. In effect I installed the packages in Hybrid with non version number and let pip to select the most appropriate version.
The version numbers that I included were the versions installed by pip.
opencv-contrib-python==4.9.0.80
is the last version available in pip with a binary available.
As you know these AI programs require a lot of packages, I had to figure out what were the missing packages in Hybrid.
Fortunately were only 3, with opencv-contrib-python being the most important.
=>
What happened to 'degrain_strength' ?
Why does HAVC_ddeoldify have sc_threshold and sc_min_freq but not EnableDeepEx and DeepExMethod?
So DeepEx can only be used when using Presets ? (no custom ? Should Hybrid drop 'custom' ?)
Also: I don't see how to properly support DeepExMethod != 0 in Hybrid.
I released a new version RC2 with a small update (see attachment).
I tried to be compatible as much as possible with the previous version 3.5.x
The main idea is to use HAVC_deolddify as a source of "exemplar" frames for "Deep-Exemplar-based Video Colorization" but at the same time to keep the use of HAVC_deolddify in "standalone" mode as in the version 3.5.x. Also HAVC_deepex can using HAVC_deolddify as source or can work in "standalone" using only external "exemplar" frames. It is implemented (in RC2) also a mixed mode, where HAVC_deepex can use as sources both HAVC_deolddify and external "exemplar" frames.
I not only renamed the old filter functions (even if the old one are still available but are "deprecated") but for some of them I added/removed some parameters.
With the only exception of HAVC_stabilizer, which is the same as in version 3.5.x and need to be the last function in the rendering pipeline, I applied the following changes:
HAVC_ddeoldify
removed: dotweak, dotweak_p, degrain_strength (KNLMeansCL.dll not more necessary to be loaded)
added: sc_threshold, sc_min_freq (is necessary to load MiscFilters.dll)
if sc_threshold==0 no reference frames are generated and HAVC_ddeoldify will work in "standalone" mode as in version 3.5.x, so is not necessary to add a flag EnableDeepEx
HAVC_deepex will work in "standalone" using only the external reference frames (clip_ref = None) and in this case in the custom section need to be enabled only the parameters for HAVC_deepex
There is an interesting option implemented in HAVC_deepex that is "only_ref_frames" (available only in "custom" mode). If this option is enabled, in the folder specified by the parameter "sc_framedir" will be saved the reference frames used by HAVC_deepex , since this option is added mainly for debugging in this case the clip is not colored by HAVC_deepex and it will be still in black and white and only the reference frames will be colored. This option is useful not only for debug but also to manually adjust the bad colored frames. In this case it is possible to put in another directory only the bad frames with the fixed colors and eventually new reference frames and use the DeepExMethod=1 and set "sc_framedir" with the name of new folder containing the adjusted frames, to regenerate the video containing the "improved" frames. This feature was not available in version 3.5.x and thanks to "Deep-Exemplar-based Video Colorization" it is also possible to perform some kind of semi-automatic colorization.
Okay,...
I do not seem get the whole 'DeepExMethod' thing.
:param DeepExMethod: Method to use to generate reference frames.
0 = HAVC (default)
1 = HAVC + RF same as video
2 = HAVC + RF different from video
3 = external RF same as video
4 = external RF different from video
RF = reference frame?
Quote:The main idea is to use HAVC_deolddify as a source of "exemplar" frames for "Deep-Exemplar-based Video Colorization" but at the same time to keep the use of HAVC_deolddify in "standalone" mode as in the version 3.5.x.
"exemplar" frames <= are these what you call RF ?
From the looks of it, I won't add 'DeepExMethod' and 'ScFrameDir' to Hybrid.
Don't see how to properly add these to Hybrid in a meaningful way while making sure they are used as intended.
=> I'll add "EnableDeepEx, DeepExPreset, ScThreshold, ScMinFreq" to HAVC_main.
These setting will not influence the 'custom'-mode at all.
I'll remove: dotweak, dotweak_p, degrain_strength from 'custom'-mode.
RF is the acronym of "reference frames" and yes it is equivalent to "exemplar frames".
I used this term because it is the term used in "Deep-Exemplar-based Video Colorization"
You should rename the checkbox "DeOldify" at the left of "Coloring" panel in "HAVC" for the reasons already explained (the frame with the DeOldify parameter don't have to be renamed, it's Ok).
I suggest to move the "GPU ID" below Merge weight, so you have more space for DeepEx.
Having more space for DeepEx, you can create a dedicated "DeepEx" frame like "DeOldify" and "DDColor"
In this new frame you can add all the DeepEx parameters, including: method, render_speed, render_vivid, enable_resize, sc_framedir, only_ref_frames, dark, dark_p, smooth, smooth_p, colormap.
As you can note I added in DeepEx some of stabilization parameters, the reason is that when are used inside DeepEx these filters will be applied only on the reference frames and so are much faster.
If it is a problem the proper management of sc_framedir you can limit its usage by forcing the following convention:
if only_ref_frames is true
sc_framedir = clip dir + "\RF_out"
if only_ref_frames is false and method > 0
sc_framedir = clip dir + "\RF_in"
Once you have created this dedicated settings frame for "DeepEx" you can add also 'DeepExMethod', 'ScFrameDir' in the Preset section.
I know that this will complicate the GUI, take all the time you need, there's no rush.
Atm. one can either use:
1. a preset with HAVC_main which wraps: HAVC_ddeoldify + HAVC_deepex (optional) + HAVC_stabilizer
or
2. (custom) HAVC_ddeoldify + HAVC_stabilizer
Yes, I could adjust Hybrid to convert 'custom' to HAVC_ddeoldify + HAVC_deepex (optional) + HAVC_stabilizer, but I think this is overkill.
Like I mentioned time and time again, the is all getting too complex, too many parameters,...
Especially since I have to expect there to come an additional xy new parameters with the next release of HAVC/deloldify.
Since this is really bothering me, I thought about removing all the custom stuff and just limit Hybrid to support just the HAVC preset based part.
Problem is, that also annoys the hell out of me (only partially supporting havc/deoldify), I now decided to drop the support for it as a whole.
=> Next Hybrid version will not support HAVC/deoldify any more.
If folks want to use it, they would need to either write their own custom additions to Hybrid or write their own code in a custom section.
Please continue the support for this filter. The amount of thought and creativity that went into this project and the results are astonishing.
There are many of us who are always excited to see the next upgrade to this wonderful tool.
1. I do not have the time and motivation to check the whole code of everything in __init__.py to figure out what inner workings and documentation changed.
2. The amount of parameters is too much, yet in each change it increases.
=> Sorry, it does not seem to be worth the effort for 2 users (Dan64, zspeciman).