Advice on free local B&W film colorization — DDColor + exemplar propagation vs altern

[KAKA_colorize]

Hi everyone, I'm working on colorizing old black-and-white films (Iranian cinema) on a modest PC — GTX 1650 with 4GB VRAM, so the DiT/HAVC route (8GB+ VRAM) is out of reach for me.

My current pipeline:
1. Split into scenes
2. Colorize one keyframe per scene with DDColor-large (CPU)
3. Propagate colors with an exemplar-based model (zhangmozhe Deep-Exemplar-based-Video-Colorization, CPU)
4. Reassemble with original luminance + audio

It works, but I'm hitting quality limits — DDColor sometimes paints foliage red/orange instead of green, and the 2019-era propagator can smear colors. I've tried SD 1.5 img2img as an alternative keyframe colorizer and it was worse.

Here are two clips of the same footage for comparison:
- My pipeline (DDColor-large + exemplar propagation): https://drive.google.com/file/d/1zabMn4z...p=drivesdk
- MagicHour's colorizer on the same footage: https://drive.google.com/file/d/1Tc6TrzR...p=drivesdk

Questions:
1. Is there any newer free colorization model that runs on 4GB VRAM or CPU and beats DDColor-large for natural colors (green foliage, natural skin)?
2. Has anyone tried denser keyframes (e.g. 1 per ~30 frames instead of 1 per scene) with exemplar propagation — does it help temporal consistency enough to justify the extra compute?
3. Out of curiosity — does anyone know what approach MagicHour's video colorizer uses? Their results on the same footage are clearly better (semantic understanding of objects), and I'd love to know if there's a public model in that direction.

Thanks for any pointers!

[Dan64]

Hello,

  try vs-havc deployed with Hybrid.
  For the settings to use, read the chapter 4.0.1 at page 42 of HAVC user guide
  
Dan

[KAKA_colorize]

Thanks a lot, Dan! Really appreciate you taking the time to reply.

I'll try vs-havc deployed with Hybrid using the 'Best settings for low powered GPU' from chapter 4.0.1 of the user guide, and I'll post the results here on this thread once I have them.

Thanks again!

[KAKA_colorize]

Hi Dan,

Update: I now have all three on the SAME indoor scene, so the comparison is fair this time. Attached screenshot shows MagicHour vs vs-havc (your ch. 4.0.1 low-GPU settings) vs plain DDColor, 3 frames each.

Honest take: vs-havc and plain DDColor are basically tied — both get the gold picture frame, the maroon curtain and the blue suit wrong, while MagicHour nails all three. So vs-havc didn't move the needle for me vs DDColor.

The vs-havc clip (2 sec): https://drive.google.com/file/d/1jSZdigH...p=drivesdk

MagicHour clip (3 sec, same scene):
https://drive.google.com/file/d/1GdnoUCx...p=drivesdk

Is this the ceiling for free local tools on weak hardware, or is there another vs-havc setting/trick I'm missing? Any further advice appreciated.

Thanks!

[Dan64]

Hello,

  to me havc is much better than DDColor alone (see details in the red rectangle)

   

  havc colors are more stable and this is an important feature for video colorization.

  Moreover you are not comparing apple-with-apple, Magic Hour is a cloud service and behind they are using powerful GPUs using probably DiT models.
  I tried to colorize a frame with MH but the result was quite bad (washed colors)

   

  probably you provided to MH a clip with better quality and resolution.

   I attached a couple of clips colorized with longcat-q3 (your target) and flux2-dev-int4 (match MH)

Dan

[KAKA_colorize]

Hi Dan,

Thanks for the clips — I watched both. The longcat-q3 and especially the flux2-dev-int4 results are on another level vs classic havc/DDColor; the flux2 one indeed matches MagicHour's color choices (gold frame, navy suits, maroon curtains). Very impressive.

My hardware is what it is though: GTX 1650 with only 4GB VRAM, 16GB system RAM, i5 (12th gen), Windows.

Question: is there ANY way to run the Flux DiT path (HavcServerDiT / flux2-dev) on this hardware with script changes — e.g. a heavier quantization (q2/q3 GGUF), full CPU offloading of the text encoder, lower input resolution, tiling, or even pure CPU? Slow is fine — I can let it run for days on keyframes only, then propagate with CMNet.

Or is 4GB VRAM a hard wall for Flux no matter the tweaks? And if Flux is impossible, does LongCat or Qwen have a lighter variant that could fit this GPU?

Thanks again!

[Dan64]

Hello,

  Flux2 is a 30B model and there is no way to run it on 4GB VRAM. I tried LongCat Q2, but the quality is bad. So I suggest you to use longcat_q3 (3.05GB) or longcat_q4 (3.60GB) with 4 steps (manually override the current default of 2steps). The comfy_bridge is able to run quantized model even on system with low VRAM (it will stream the model from disk), but you need to install the HAVCDitServer on SSD to get a decent speed. I tested it on RTX2080 with 8GB VRAM and 16GB RAM, it run slow, but it works. To get a decent speed you need to enable "Fast Pipeline" (enabled by default).

Good luck!

Dan

[Dan64]

Hello,

  I released HAVC v2.8.0 

  In this release I added support to FLUX2 Klein 4b/9b.

  Klein 4b is smaller than LongCat Q3 (7.6 GB of weights against 8.8 GB, and 3.8 GB against 5.8 GB in the text-encoder phase) and, is faster than LongCat.
  Try it (it works well even with 2 steps).

   I attached the clip colorized with Klein 4b (2 steps).

Dan