[AyedaOk]

Hi Andrii,

I believe RawForge is the best FOSS denoising model, but integrating it with Darktable isn't simple. So in the last few months, I've been experimenting with training my own denoising model. I've started with RawNIND and then integrated RawForge's losses. I've also added my own training data. I named the end result Okeinla.

Based on my "trust me bro" benchmark, it performs better than RawNIND and is on par with RawForge.

Model	PSNR ↑	MS-SSIM ↑	HFEN ↓	Mean ΔE00 ↓
RawNIND	46.824029	0.996371	0.587372	1.465568
RawForge TreeNetDenoise	47.352061	0.996644	0.562067	1.358544
Okeinla	47.152499	0.996782	0.574000	1.191244

This is the data I used for testing: https://huggingface.co/datasets/AyedaOk/rawbench-dataset. I can upload the testing stript if you want.

If I missed something in the PR, let me know.

---

• Model: https://huggingface.co/AyedaOk/okeinla
• Training source: https://github.com/AyedaOk/okeinla
• Dataset: https://huggingface.co/datasets/AyedaOk/okeinla-dataset and https://dataverse.uclouvain.be/dataset.xhtml?persistentId=doi:10.14428/DVN/DEQCIM
• Code and weights: GPLv3, with the NAFNet MIT notice retained.
• Training datasets: CC BY-SA 4.0.

Integration

This PR downloads the published Bayer ONNX from Hugging Face revision 7d4480d305ac9a425832afb9c110ee0b1af0200a and packages it with GPLv3 and NAFNet MIT license texts. It uses the existing setup, validation and demo pipeline without adding per-model unit tests or shared CI changes.

This PR also fixes the shared RawNIND demo’s non-RGGB Bayer preprocessing by cropping to RGGB before packing, matching the training loader and darktable’s force_rggb handling.

Added a CC0 Panasonic DMC-GF1 RAW from raw.pixls.us (entry 880) with a verified GBRG pattern to exercise the crop. Both Okeinla and RawNIND demos processed it successfully. Source, license and SHA256 are recorded alongside the sample.

[andriiryzhkov]

Thanks for all the work on Okeinla! This is just a first look at the code; a fuller review will follow.

No linear variant. The package only has model_bayer. darktable uses one active model for all raw denoising and falls back to the package's model_linear for X-Trans and linear raws. rawdenoise-nind ships both. With Okeinla selected, raw denoise stops working for every non-Bayer camera, which limits the model a lot. A model_linear variant would remove that limitation.

The pack_rggb fix in rawdenoise-nind's demo. Good catch: the old code packed BGGR, GRBG and GBRG raws by color but kept the sensor's own layout, while the models expect RGGB blocks (force_rggb). Cropping to start on R matches what RawNIND's own loader does. Since this changes rawdenoise-nind too, please mention it in the PR description.

Suggestion: use the ONNX you already publish. Your Hugging Face repo already has onnx/model_bayer.onnx, so you could download it straight into the output folder, as upscale-realplksr does, pinned to the same commit as the checkpoint:

checkpoints:
  - url: "https://huggingface.co/AyedaOk/okeinla/resolve/7d4480d305ac9a425832afb9c110ee0b1af0200a/onnx/model_bayer.onnx"
    path: "output/rawdenoise-okeinla/model_bayer.onnx"

The convert: section, convert.py, the repo: entry and the vendor/okeinla submodule could then go. Keeping the conversion here is fine too; it's your choice.

CI: please drop the change to check-pr.yml and test_model.py. Every model is already checked end to end (setup, convert, validate, demo), and nightly and release run the same pipeline. Per-model unit tests would be a new convention in the shared workflow for one model, and they would only run on PRs.

What the tests cover is mostly covered already:

• A wrong checkpoint already fails dtai convert.
• The demo step already runs the three X-Trans RAFs in samples/rawdenoise/xtrans. The test mocks raw_pattern=None, which a real X-Trans file doesn't have.
• The pack_rggb tests check rawdenoise-nind's code from Okeinla's folder.

To cover the non-RGGB path instead, add a BGGR, GRBG or GBRG raw to samples/rawdenoise/bayer, under a license that allows it in the repo. The demo step will then run it like the other samples, for both models.

[AyedaOk]

Hi Andrii, thanks for the review.

With a23d571, I use the published ONNX, removed the converter, and CI change.

I' ve also updated the PR description to mention the shared Bayer cropping fix.

With 3a79dcc I've added a GBRG sample. Both demos process it.

Note that I've noticed a brightness strip in Okeinla’s Python demo. The demo applies gain correction after stitching, while darktable corrects each tile and blends overlaps. With darktable, I don't see any issues. I can add the demo correction to the PR if you want.

Is a linear variant mandatory for acceptance, or can Okeinla remain Bayer-only? If it is mandatory, I will need a few weeks to train it.

[TurboGit]

Is a linear variant mandatory for acceptance, or can Okeinla remain Bayer-only?

Bayer-only is a bad limitation, would be nice to lift it.

[andriiryzhkov]

Bayer-only is a bad limitation, would be nice to lift it.

Without at least Linear variant model can not become default one, but we can still have it in the catalog even in limited form.

[AyedaOk]

I prepared everything to train a linear variant but it takes longer than Bayer for training. I can't run it 24/7, so I will need about 1-2 months before it's ready. I'm fine if you want to wait for the linear variant before adding it to the catalog.