# cineFlow — degraining small-gauge scans, open source

**URL:** <https://forums.kinograph.cc/t/cineflow-degraining-small-gauge-scans-open-source/3085>\
**Category:** Software\
**Created:** [August 13, 2026, 3:44pm UTC](https://forums.kinograph.cc/t/cineflow-degraining-small-gauge-scans-open-source/3085 "2026-08-13T15:44:02Z")\
**Posts on this page:** 5\
**Page:** 2

<div class="post-metadata">

**Author:** ![npiegdon](https://forums.kinograph.cc/user_avatar/forums.kinograph.cc/npiegdon/32/2729_2.png) [@npiegdon](https://forums.kinograph.cc/u/npiegdon)\
**Post date:** [October 5, 2026, 1:25pm UTC](https://forums.kinograph.cc/t/cineflow-degraining-small-gauge-scans-open-source/3085/21 "2026-10-05T13:25:35Z")

</div>

That’s really remarkable! The amount of extra detail you can squeeze out by using adjacent frames always feels a bit like magic.

I’d be curious to see the water in motion. It’s challenging not to over-soften it using techniques like these.

If the two-pass approach worked this well here, have you tried it in the general case on less challenging material? Your reasoning for the parameters used in both passes seems like it would remain sound in just about every situation. Or would it be overkill elsewhere?

---

<div class="post-metadata">

**Author:** ![cpixip](https://forums.kinograph.cc/user_avatar/forums.kinograph.cc/cpixip/32/852_2.png) [@cpixip](https://forums.kinograph.cc/u/cpixip)\
**Post date:** [October 5, 2026, 1:46pm UTC](https://forums.kinograph.cc/t/cineflow-degraining-small-gauge-scans-open-source/3085/22 "2026-10-05T13:46:02Z")

</div>

> [@npiegdon](#):
>
> If the two-pass approach worked this well here, have you tried it in the general case on less challenging material?

Well, no. The reason: this 2pass-approach doubles the time as well as the number of parameters to tune. You would not want to go through this until absolutely necessary.

In fact, one pass of cineFlow is usually sufficient for a broad range of materials: HDR or RAW scans, color reversal or negative bw-footage, Kodachrome 40 or old Agfa-stock. One pass is for all practical purposes sufficient.

> [@npiegdon](#):
>
> I’d be curious to see the water in motion.

Well, if you look at the example image 4 (the single sea lion), you can spot some loss of detail in the fast-moving water in the background. One could optimize here further, which I have not done. All examples were rendered with the same fixed settings.

The technique of cineFlow is very different from things like Neatvideo (cineFlow does not use any noise profile) or Topaz (in cineFlow, no image structure is ever invented). The cineFlow-program tries to lock instead onto the faint image structures in the source. Grain removal and other things (reduction of density variations for example) are actually a by-product of the process.

For an idea how water in motion looks like, have a look at the example video linked [above](https://forums.kinograph.cc/t/cineflow-degraining-small-gauge-scans-open-source/3085/18). For some challenging examples in the normal 1pass-processing, have a look [here](https://forums.kinograph.cc/t/cineflow-degraining-small-gauge-scans-open-source/3085/7).

---

<div class="post-metadata">

**Author:** ![cpixip](https://forums.kinograph.cc/user_avatar/forums.kinograph.cc/cpixip/32/852_2.png) [@cpixip](https://forums.kinograph.cc/u/cpixip)\
**Post date:** [October 5, 2026, 5:02pm UTC](https://forums.kinograph.cc/t/cineflow-degraining-small-gauge-scans-open-source/3085/23 "2026-10-05T17:02:56Z")

</div>

Well… - and here is the actual video of the cineFlow result on the Sea Lion Cave:

[https://www.pixelcircus.com/cineFlow/Sea%20Lion%20Comp.mp4](https://www.pixelcircus.com/cineFlow/Sea%20Lion%20Comp.mp4)

Note that all scenes of the Sea Lion sequence were processed with the same fixed settings - these are certainly not optimal for some of the scenes. I am still experimenting here…

---

<div class="post-metadata">

**Author:** ![cpixip](https://forums.kinograph.cc/user_avatar/forums.kinograph.cc/cpixip/32/852_2.png) [@cpixip](https://forums.kinograph.cc/u/cpixip)\
**Post date:** [October 6, 2026, 5:31pm UTC](https://forums.kinograph.cc/t/cineflow-degraining-small-gauge-scans-open-source/3085/24 "2026-10-06T17:31:44Z")

</div>

## cineFlow – Results with Defaults

As mentioned before, most material achieves presentable results with just the default parameters of cineFlow. This matters, as there are a lot of parameters to play with.

The following example shows some scenes from Yellowstone National Park. The source material was Kodachrome 40, developed only a full year after exposure. The camera was a rebranded, consumer-grade Cinon.

This kind of material is challenging for the algorithm cineFlow is built on: the waterfall consists of diffuse, fast-moving structures, and in front of it there is transparent spray. Both make it hard to find correspondences between frames.

The results below were obtained with the default settings of the program. Nothing was adjusted.

The results seem to be usable. Only in the spray does the result lose a little of the original’s modulation.

[https://www.pixelcircus.com/cineFlow/clip\_002A\_compare.mp4](https://www.pixelcircus.com/cineFlow/clip_002A_compare.mp4)

The default parameters used for processing are:

```auto
{
  "mode": "best",
  "downscale": 2.0,
  "flow_backend": "RAFT",
  "context": 2,
  "geo_mismatch": 1.9,
  "geo_softness": 0.5,
  "photo_mismatch": 0.055,
  "photo_softness": 0.018,
  "photo_radius": 3,
  "sharp_base": 0.05,
  "sharp_full": 0.034,
  "sharp_gamma": 0.7,
  "sharp_amount": 4.5,
  "detail_filter": "guided",
  "detail_sigma": 0.5,
  "detail_eps": 0.01
}

```

By the way – that’s all that is written in a cineFlow config file “`cineflow.json`”.

---

<div class="post-metadata">

**Author:** ![cpixip](https://forums.kinograph.cc/user_avatar/forums.kinograph.cc/cpixip/32/852_2.png) [@cpixip](https://forums.kinograph.cc/u/cpixip)\
**Post date:** [October 9, 2026, 4:56pm UTC](https://forums.kinograph.cc/t/cineflow-degraining-small-gauge-scans-open-source/3085/25 "2026-10-09T16:56:11Z")

</div>

## cineFlow - optimizing parameters

As noted above, the default parameters of cineFlow should get you going. For challenging scenes, adjusting a few of them can improve the result noticeably.

The following scene is such a case. It is a Grand Canyon sunset, again on Kodachrome 40 that was developed about a year after exposure. The scene combines a bright sky with very dark canyon walls, so like all examples so far it was scanned in HDR mode. On top of that, the clip carries plenty of dust and a few scratches.

Here’s an example of an input image - a “raw” HDR scan:

 ![f00031_input_DIS_dustA_sc2_ctx6_sx3](https://forums.kinograph.cc/uploads/default/original/2X/6/682c7ccf00dee6a5932ca226ed6e5fde4d8d8f7b.jpeg)

Processed with the default parameters, the grain is reduced, but dust and scratches survive the processing (this is intentional behaviour for `best`-mode).

The above input image with default parameters prcessed yields this:

 ![f00031_output_best_RAFT_best_sc2_ctx2_sx4.5](https://forums.kinograph.cc/uploads/default/original/2X/0/056f8e5b9b28f85b7d77e5ff5cbb1aa4e22b9ad6.jpeg)

For the optimized version, a few parameters were changed. Processing happened in a single pass.

The flow backend was switched from RAFT to DIS. RAFT, being a neural network, tends to produce plausible-looking flow even where there is no real correspondence between frames, and such flow can pass the trust stages. DIS fails more erratically in those areas, which the trust stages can detect. In short, DIS makes better mistakes.

The mode was set to `dustA` instead of `best`, which removes most of the dust and scratches. Note that in the dust modes the photometric trust parameters have no effect on the result; the consensus of the neighbouring frames takes over that role.

The context was raised from ±2 to ±6 frames, and the geometric trust was loosened (threshold 4.0 px instead of 1.9, softness 1.0 instead of 0.5). Together this lets distant neighbours still contribute to the noise reduction. The price is a less strict forward-backward check, so in the darkest areas larger patches can occasionally shift by a few pixels.

The sharpening was adjusted to the low texture of the material.

This is the result obtained with the modified parameters:

 ![f00031_output_dustA_DIS_dustA_sc2_ctx6_sx3](https://forums.kinograph.cc/uploads/default/original/2X/0/007ddd555393c55efe615d23502c3e3370d01b86.jpeg)

The diagnostic views and statistics in flowQt help to understand why a setting works or does not, but tuning by eye is just as legitimate. Changing a value, looking at the result and changing it again is exactly what flowQt is meant for. Beyond the basic choices, the final settings are a question of aesthetics, and there is no single right answer.

The complete comparision clip:

[http://www.pixelcircus.com/cineFlow/17\_Dark\_Canyon\_compare\_002.mp4](http://www.pixelcircus.com/cineFlow/17_Dark_Canyon_compare_002.mp4)

For reference, these were the settings used:

```auto
{
  "mode": "dustA",
  "downscale": 2.0,
  "flow_backend": "DIS",
  "context": 6,
  "geo_mismatch": 4.0,
  "geo_softness": 1.0,
  "photo_mismatch": 0.055,
  "photo_softness": 0.008,
  "photo_radius": 3,
  "center_weight": 1,
  "dustA_mismatch": 3.0,
  "dustA_softness": 1.5,
  "sharp_base": 0.05,
  "sharp_full": 0.017,
  "sharp_gamma": 0.8,
  "sharp_amount": 3.0,
  "detail_filter": "guided",
  "detail_sigma": 0.5,
  "detail_eps": 0.01
}

```

[Previous page](https://forums.kinograph.cc/t/cineflow-degraining-small-gauge-scans-open-source/3085.md?page=1)