Selur's Little Message Board

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77

Quote:1) the lists for filters "Chroma smoothing/stabilizer" start with a boolean flag to enable them.
When the list is checked/unchecked can you automatically change the flag to True/False ?

Hybrid does not really validate those arrays/lists, it just checks that the (trimmed) string:
1. start with a '['
2. ends with a ']'
3. that when split the element at index 0 container 'True'
=> In theory I could parse the content and change and validate it, but I would have to adjust it each time you change the parameters, so I think for the moment I will keep it the way it is.

Quote:2) Can you dedicate to the parameter "Darkness" a dedicated GUI params like "Chroma Limiter"

Code:
:param darkness:            parameters for darken the clip's dark portions, which sometimes are wrongly colored by the color models

                                   [0] : darkness_enabled (bool), if true the filter is enabled 

                                   [1] : dark_threshold, luma threshold to select the dark area, range [0.1-0.35] (0.01=1%)  

                                   [3] : dark_amount: amount of desaturation to apply to the dark area, range [0-1]

Not plaining to do so, since 'darkness' has more than one element aside from the enable/disable decision and the next thing that happens when I add elements for dark_threshold and dark_amount in the ui is that you add x additional parameters.
=> Sorry, not going to happen. (maybe once vsDeoldify is more stable)

Cu Selur

Ps.: Fixed a small typo, uploaded a new dev, same link.

(29.03.2024, 21:06)Selur Wrote: [ -> ]
Quote:1) the lists for filters "Chroma smoothing/stabilizer" start with a boolean flag to enable them.
When the list is checked/unchecked can you automatically change the flag to True/False ?
=> In theory I could parse the content and change and validate it, but I would have to adjust it each time you change the parameters, so I think for the moment I will keep it the way it is.

Ok, but if I change the param list to something like

Code:
chroma_smoothing_enabled=True, chroma_smoothing_param=[0.1,0.2,0.6,0.65]

Dan

(29.03.2024, 21:06)Selur Wrote: [ -> ]Not plaining to do so, since 'darkness' has more than one element aside from the enable/disable decision and the next thing that happens when I add elements for dark_threshold and dark_amount in the ui is that you add x additional parameters.
=> Sorry, not going to happen. (maybe once vsDeoldify is more stable)

To be to be more precise respect to the version 2.x I added the following parameters

1) "darkness: list = [False, 0.2, 0.8]"
2) " enable/disable FP16 in ddcolor inference"
3) in chroma_stabilizer the parameters: 4, 5, 6, 7

For a total of 8 additional parameters.

If you prefer I can try to reduce the number parameters, in order to do not exceed the number of parameters included in ver. 2.x

Dan

Quote:Ok, but if I change the param list to something like

Code:
chroma_smoothing_enabled=True, chroma_smoothing_param=[0.1,0.2,0.6,0.65]

'Yes', then I could better integrate it in the ui and wouldn't have to check for 'True'. (this should be done for all parameters)
You might also want to think about shortening the parameter names.
(just a suggestion, since having parameters with multiple underscores usually is bad)
Maybe instead of 'chroma_smoothing_enabled' and 'chroma_smoothing_param', better something like 'chr_smooth' and 'chroma_sp'?
So:

Code:
clip: vs.VideoNode, color_method: int = 2, merge_weight: float = 0.4, deoldify_params: list = [0, 24, 1.0, 0.0], ddcolor_params: list = [1, 24, 1.0, 0.0], ddcolor_tweaks: list = [False, 0.4, 0.4, 0.0, 1.0, 1.0, True, 1],  combine_params: list = [False, 0.6, 2.0, 0.15, 0.2, 0.3, 0.6, 1.0], darkness: list = [False, 0.2, 0.8], chroma_resize: bool = True, device_index: int = 0, np_threads: int = 8, torch_hub_dir: str = model_dir) -> vs.VideoNode:

could become, something like:

Code:
clip: vs.VideoNode, method: int = 2, mweight: float = 0.4, deoldify_p: list = [0, 24, 1.0, 0.0], ddcolor_p: list = [1, 24, 1.0, 0.0], ddcolor_tweak: bool = False, ddcolor_tweakp: list = [0.4, 0.4, 0.0, 1.0, 1.0, True, 1],  combine_p: list = [0.6, 2.0, 0.15, 0.2, 0.3, 0.6, 1.0], dark: bool = True, dark_p: list = [0.2, 0.8], chr_rez: bool = True, device_idx: int = 0, np: int = 8, torch_dir: str = model_dir) -> vs.VideoNode:

combine_parameters should always be 'True' when the method index > 1, so having an extra parameter to enable it is unnecessary.
and

Code:
ddeoldify_stabilizer(clip: vs.VideoNode, chroma_smoothing: list = [False, 0.1, 0.2, 0.5, 0.8], chroma_stabilizer: list = [True, 5, 'arithmetic', 1, 60, 0.5, 0.8, 0], chroma_limiter: list = [False, 0.02], chroma_resize: list = [True, 24]) -> vs.VideoNode:

could become something like:

Code:
ddeoldify_stab(clip: vs.VideoNode, chr_smooth: bool = False, chr_smoothp: list = [0.1, 0.2, 0.5, 0.8], chr_stab: bool = True, chr_stabp: list = [5, 'arithmetic', 1, 60, 0.5, 0.8, 0], chr_limit: bool = False, chr_limitp: list = [0.02], chr_rez: bool = True, chr_rezp: list = [True, 24]) -> vs.VideoNode:

Quote:If you prefer I can try to reduce the number parameters, in order to do not exceed the number of parameters included in ver. 2.x

The 2.x already had way to many parameters.
The problem is:
a. integrating (and always changing, testing, adding interactions, setting tool-tips, etc.) for tons of parameter is a pain.
b. having tons of parameters makes a filter not really usable, since users will just blindly flip switches and ask for help so that others tweak their settings.

Cu Selur

I changed the functions parameters as you suggested.

Code:
def ddeoldify(

    clip: vs.VideoNode, method: int = 2, mweight: float = 0.4, deoldify_p: list = [0, 24, 1.0, 0.0], ddcolor_p: list = [1, 24, 1.0, 0.0, True], ddtweak: bool = False, ddtweak_p: list = [0.0, 1.0, 1.0, False, 0.4, 0.4],  CMC_p: float = 0.2, LMM_p: list = [0.3, 0.6, 1.0], dark: bool = False, dark_p: list = [0.2, 0.8], chrez: bool = True, cmb_inv: bool = False, device_index: int = 0, torch_dir: str = model_dir) -> vs.VideoNode:

I performed also the following changes:

1) removed the method: Adaptive Luma Merge
2) moved fp16 flag in ddcolor_p
3) split the parameters of the 2 combining methods: CMC, LMM
4) assigned a dedicated flag to: invert clips merge

Code:
def ddeoldify_stabilizer(clip: vs.VideoNode, smooth: bool = False, smooth_p: list = [0.2, 0.7, 0.9, 0.1], stab: bool = True, stab_p: list = [5, 'A', 1, 60, 0.5, 0.8], chrez: bool = True, chrez_p: int = 24) -> vs.VideoNode:

I performed also the following changes:

1) removed the filter chroma limiter

All the parameters have the suffix "_p", when the list contains only 1 element I substitute the list with a simple python variable, but I can keep the list (let me know)

I counted 36 parameters (excluding clips and enable/disable list flags), it is still an high number, but you have to consider that there are 2 coloring filters, 3 merge methods and 4 filters

Let me know I have to apply additional changes.

Thanks,
Dan

Is there a scenario where it makes sense to disable 'chrez', if not, it should be removed from the parameters.

Another question: Does the input resolution influence the result ?
I was wondering whether resizing HD to SD resolution before applying deoldify and ddcolor and later upscale and copy the chroma to the original would make sense to speed things up or whether this would only lower the accuracy / temporal consitency?

otherwise:

Code:
# frame size calculation for inference()    

    frame_size = min(render_factor * 16, clip.width)

    if chroma_resize_enabled:

        clip_orig = clip;

        clip = clip.resize.Spline64(width=frame_size, height=frame_size)

should be:

Code:
if chroma_resize_enabled:

        # frame size calculation for inference()    

        frame_size = min(render_factor * 16, clip.width)

        clip_orig = clip;

        clip = clip.resize.Spline64(width=frame_size, height=frame_size)

additionally:

Code:
chrez: bool = True, chrez_p: int = 24)

_p parameters should always be lists.
if you only got one parameter it should have it's own name so chrez_p should be render_factor.

Code:
CMC_p: float = 0.2, LMM_p: list = [0.3, 0.6, 1.0]

to keep the naming consistent, CMC and LLM should be lower case.
also since 'CMC_p' is has only one paramater it should be 'cmc_thresh'.
maybe change 'cmb_inv' to 'cmb_sw' for combine_switch switching seems more fitting than inverse.

Code:
:param LMM_p:               parameters for method: "Luma Masked Merge" 

                                   [0] : luma_mask_limit, luma limit for build the mask used in Luma Masked Merge, range [0-1] (0.01=1%) 

                                   [1] : luma_white_limit, if > luma_mask_limit will be applied a gradient till luma_white_limit, range [0-1] (0.01=1%)

                                   [2] : luma_mask_sat: if < 1 the ddcolor dark pixels will substitute with the desaturated deoldify pixels, range [0-1] (0.01=1%)

Can you change the description of luma_mask_limit and luma_white_limit ? atm. they don't really seem to make sense.

Cu Selur

(30.03.2024, 07:57)Selur Wrote: [ -> ]Is there a scenario where it makes sense to disable 'chrez', if not, it should be removed from the parameters.

Another question: Does the input resolution influence the result ?
I was wondering whether resizing HD to SD resolution before applying deoldify and ddcolor and later upscale and copy the chroma to the original would make sense to speed things up or whether this would only lower the accuracy / temporal consitency?

for what concern the chroma filters: "cherez" enabled will not affect the output resolution, so it makes sense to remove from the parameter list and left it always enabled (I introduced the flag mainly for testing).

Unfortunately the input resolution impacts the inference and filters speeds, that's the reason why I introduced the render factor also in the stabilizer.
The downsize before the inference and then the upscale is already implemented by the render_factor, no reason to implement it externally.
Also the resizer used to downscale has little impact (both deoldify and ddcolor are using "bilinear") because the luma restore is able to provide back the full original resolution.

I will apply the proposed changes in the next RC.

Dan

P.S.
The explanation of "Luma Masked Merge" is provided in the "method" description of this filter

Quote:I will apply the proposed changes in the next RC.

I'll adjust Hybrid then. Smile

Cu Selur

Here the new RC4. I updated some description.

Dan

Code:
deoldify_p: list = [0, 24, 1.0, 0.

    :param deoldify_p:          parameters for deoldify():            

                                   [0] deoldify model to use (default = 0):

                                       0 = ColorizeVideo_gen

                                       1 = ColorizeStable_gen

                                       2 = ColorizeArtistic_gen

                                   [1] render factor for the model, range: 10-44 (default = 24).

                                   [2] saturation parameter to apply to deoldify color model (default = 1)

                                   [3] hue parameter to apply to deoldify color model (default = 1)

Quote:[3] hue parameter to apply to deoldify color model (default = 0)

calling:

Code:
clip = ddeoldify(clip=clip, method=3, deoldify_p=[3, 24, 1, 0], ddcolor_p=[1, 24, 1, 0, True])

I get:

Code:
File "F:\Hybrid\64bit\Vapoursynth\Lib\site-packages\vsdeoldify\__init__.py", line 183, in ddeoldify

clipa = _deoldify(clip, method=method, model=deoldify_model, render_factor=deoldify_rf, package_dir=package_dir)

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

File "F:\Hybrid\64bit\Vapoursynth\Lib\site-packages\vsdeoldify\__init__.py", line 309, in _deoldify

return clip.std.ModifyFrame(clips=[clip], selector=partial(ddeoldify_colorize, colorizer=colorizer, render_factor=render_factor))

^^^^^^^^^

UnboundLocalError: cannot access local variable 'colorizer' where it is not associated with a value

'_deoldify' has no match model 3,....

Cu Selur

Ps.: updated the download, but couldn't test everything due to the bug.

(30.03.2024, 11:28)Selur Wrote: [ -> ]
Code:
deoldify_p: list = [0, 24, 1.0, 0. :param deoldify_p: parameters for deoldify(): [0] deoldify model to use (default = 0): 0 = ColorizeVideo_gen 1 = ColorizeStable_gen 2 = ColorizeArtistic_gen [1] render factor for the model, range: 10-44 (default = 24). [2] saturation parameter to apply to deoldify color model (default = 1) [3] hue parameter to apply to deoldify color model (default = 1)

calling:

Code:
clip = ddeoldify(clip=clip, method=3, deoldify_p=[3, 24, 1, 0], ddcolor_p=[1, 24, 1, 0, True])
'_deoldify' has no match model 3,....

It is correct, for deoldify valid models are: 0, 1, 2 (the valid models are described in " :param deoldify_p: ")

Dan

P.S.
I will release a new RC with correct description for "hue"

Selur

Dan64

Selur

Dan64

Selur

Dan64

Selur

Dan64

Selur

Dan64