Night BW shot using old LX7

kofa · January 8, 2021, 8:33pm

Thanks.
Note to all: you may need to wait for RCD to stabilise, see RCD yields different results with same params (color smoothing) · Issue #7756 · darktable-org/darktable · GitHub

heckflosse · January 8, 2021, 8:44pm

In RawTherapee rcd is stable. Just give Hanno some more time to get it stable in darktable as well. Imho it’s worth it…

Underexposed · January 8, 2021, 8:50pm

If you are referring to Todd’s post, #27 above, when I open it, it is using AMaZE with green match full and local average.

priort · January 8, 2021, 8:53pm

Ya once I discovered that I had set this as an autopreset it makes sense where it came from. I had been experimenting a while back trying to look at chroma noise and the different demosaic modes…certainly in this example and pixel peeping it seemed like none was better for both looking at a very high zoom of around 200%…VNG seemed also to produce less chroma noise in the very dark parts but there was some fringing near sharp tonal transitions with VNG that were not there for amaze…so I guess it pays to remember what you change and remember to change it back… I do like Andy’s videos he is a character…

kofa · January 8, 2021, 8:54pm

Sure, what I meant was the darktable implementation. It’s not in a stable release, so funny stuff is expected.

Jade_NL · January 8, 2021, 9:20pm

Nope, I was referring to #38 and darktables install default.

@kofa: You might want to have a peek at RawTherapee’s Dual Demosaic-ing. darktable users don’t realize what they are missing Maybe @hannoschwalm and @heckflosse can collaborate after RCD is fully tested/implemented and work on a RCD-VNC4 method for darktable.

heckflosse · January 8, 2021, 9:21pm

We already communicate about this

heckflosse · January 8, 2021, 9:27pm

Enough of ot now. Let’s continue play raw

heckflosse · January 8, 2021, 9:34pm

heckflosse · January 8, 2021, 9:52pm

P1050600.jpg.out.pp3 (14.2 KB)

kofa · January 8, 2021, 10:14pm

Very nice, though I prefer the softer reflections from the camera’s version (and also @Phil_Smith’s, @elstoc’s, @age’s BW).
@Jade_NL: I was an RT user before darktable. Actually, I started using darktable because of its OpenCL acceleration (my Core2 Duo with 4 GB is not quite a powerhouse; will perhaps replace it this spring). But I do keep an eye on RT & ART, and Filmulator, too.

priort · January 9, 2021, 12:07am

Is RCD in the master branch?? I did a build a couple of days ago and I don’t have it??

pphoto · January 9, 2021, 12:47am

Nice image. I decided to stay in a colored version although I had to struggle a bit with the various colored lights.

P1050600.RW2.xmp (11.5 KB)

kofa · January 9, 2021, 8:49am

github.com/darktable-org/darktable

Introducing a tiled RCD demosaicer (#7337)

committed 09:36AM - 29 Dec 20 UTC

jenshannoschwalm

+698 -51

* Introducing a tiled RCD demosaicer The rcd demosaicer developed by Luis San…z Rodríguez is publically available at https://github.com/LuisSR/RCD-Demosaicing and is licenced under the GNU GPL version 3. I came across this via the rt issue tracker Beep6581/RawTherapee#5908 and have personally been using it in dt for some months. The results are very good, quality is at least en-par with Amaze, maybe depending on image content the results are slightly better or slightly worse. The biggest pro argument is less color overshoot, the penalty is marginally increased blur. Having a demosaicer output with less overshoot makes this a better option for further processing. I started developing the demosaicer by taking the algo from original github and adopted it to dt style. Over time i learned how @heckflosse had improved the code by tiling, less omp overhead and by adding sse2 code in the most time-critical internal loop as the compiler does not vectorize here as good. Further on we discussed many details and worked on performance on different machines. Thanks a lot! Now it is really good, on darktable rcd is ~3x faster than amaze and 30% faster than the non-cl ppg code. On my machine (pretty similar to the well known 9900k) i am now at ~135ms for a 45Mpix image. This is ~3 times as good as the non-tiled version. The border interpolation used the dcraw algorithm in the original code, there are minor issues so i chose the code used by rt as it has less artefacts. A border of 9 is always safe if tiling is used. Unfortunately there is no paper describing the algorithm, we only have the README in the original git repo at https://github.com/LuisSR/RCD-Demosaicing/blob/master/README.md Also there is no formal quality analysis, at rawtherapee we have https://rawpedia.rawtherapee.com/Demosaicing But we have a lot of experience people made when using this demosaicer in rt. Some notes for people testing the code 1) in demosaic.c you find the bitmask #define DEMOSAIC_TIMING 0 - 01 --> add timing info for the demosaicers while tuning avoiding the mass of -d perf info - 02 --> prohibit fall back to ppg 2) You might want to tune the tiling size in rcd_demosaic.c, unfortunately this has to be selected at compile-time. Making this runtime specified reduces performance by ~50% See former attempt #6738 * Add proper #include for optional sse4.1 intrinsics * Work on the SSE specific code sections 1. #ifdef the sse specific macros/inlines to avoid rcd being sse specif code. 2. The indx>>1 trick had been used to lower cache-mem pressure but lead to bad compiler vectoring. All indexes to lpf now use an extra index to avoid the shifting. (2) improves the non-sse performance by ~20% on my machine but still there is a significant gain of overall ~4% if using the hand-optimized code so i would prefer to keep this. * Fixing corner cases with border data * Using index/2 also for PQ_Dir As in steps 2.1 and 3.1 we can use index/2 as we calculate data only for every second pixel in a row. Reduces cache mem pressure and thus increases performance. * allocate tiling memory by dt_alloc_align_float As @ralfbrown suggests in #7419 comments and elsewhere we should always use dt_alloc_align_float instead of dt_alloc_align to get rid of the '64' magic. * Code maintaining keeping track of common/math.h The CLIP macro is only in 3.6 branch so we define it in rcd demosaicing if undefined. * Fixing compiler issue after common/math.h work 1. The CLIP macro is not necessary any more as defined in common.math.h 2. float (*const rgb)[RCD_TILESIZE * RCD_TILESIZE] = (void *)dt_alloc_align_float needs a cast

hannoschwalm · January 9, 2021, 4:42pm

It is in master branch but unfortunately i introduced a bug while optimizing performance. There is a pr fixing this so maybe you wait for a day until it gets merged

kofa · January 9, 2021, 5:01pm

Thanks for the quick fix. I hope to test this tonight, once I get home.

Jean-Marc_Digne · January 9, 2021, 5:25pm

thanks for posting, I have to practice night shots with DT 3.4

P1050600_02.RW2.xmp (22.6 KB)

Suki2019 · January 31, 2021, 9:39am

this is a real challenge to reproduce this SW look

that’s closest to what I can do with tonecurve on my laptop.
maybe I’ll try again on my real monitor.

P1050600.RW2.xmp (10.1 KB)

kofa · January 31, 2021, 2:18pm

Are you sure that’s the right sidecar? The original is a Panasonic RW2 file

Suki2019 · January 31, 2021, 2:49pm

damned…

is changed