Actually, my gear is pretty old, but on the what that means is that the maximum ISO it’s capable of is a tolerable level of noise even without any noise reduction. (they max out at 3200)
Noise reduction is something I really really want, but I really want it to be good without needing to mess around with a load of sliders.
In the end it’s because I’m putting it off, and because I’m afraid it’ll be really slow.
I need to mess around with the various algorithms available in darktable and RawTherapee and just pick one to steal…
It’s pretty slow; there are optimizations, but I’ve been too lazy to figure them out.
The other is an RGB implementation of the wavelet denoise algorithim from dcraw.c:
Much faster, decent results, but it’s not well-controlled (my “amount” doesn’t translate well in different image resolutions), but it’s not as good as NLMeans.
Every time @ggbutcher brings up wavelet denoise, I say no– I don’t like it. It muddles the details. Denoise should handle the noise without degrading the signal too much. I would say follow @rawfineret al.'s approach to denoising. Slow but worth the trouble. Maybe in need of extreme simplification for Filmulator’s purposes.
Well, yes. Every denoiser tries to achieve that. In that regard it’s a question of which artefacts you want. If you overcook wavelet denoise, it looks…err questionable?, but this is true for every other algorithm. Overcooking=Bad. Some say that ‘denoising’ is misleading and should be called ‘noise reduction’. From that it is easier to convey that different algorithms can do different reductions before they break apart. Visually appealing ‘breaking up’ is probably highly subjective.
So something like a VMAF-scored noise reduction hierarchy? Hmm. How large is the parameter space that has to be sampled for one noise reduction algorithm? And after that a ‘best parameter’ competetion between algos? Interesting.
I don’t know if this is the right place, but to me neither sharpening nor noise reduction is necessary for Filmulator. If you add sharpening, you must add noise reduction because without NR sharpening is useless. But other programs can do this job in a wide variety, so why adding it?
Filmulator is small, fast and simple and mainly does what I would expect from a raw converter, particularly producing images that are perfect for working on.
Nevertheless, the developed images need a final retouch in Gimp or maybe another program. It would thus be great to have an option to open the final image directly in Gimp as Tiff. Perhaps you could borrow it from darktable or RawTherapee?
Futhermore, a colour picker for White Balance would be very helpful because adjusting WB by sliders is very inconvenient and error-prone.
And it would be great if the Exif informations would be handed over…
Hmm, an “open in external editor”, with a command set in the Settings tab?
color picker
I’ll have to think about how to implement this, but it should be doable.
That’s a deficiency in Filmulator’s TIFF handling at the moment. Before I was just copying over all the EXIF data, but it was bringing thumbnails and such along with it and GIMP would refuse to open them, so I omit the EXIF data.
Is only having basic exif data written okay with you? Camera make model, timestamp, exposure parameters, and focal length, basically?
Yes, open in external editor would be great. And it would be completely sufficient to have camera make model, timestamp, exposure parameters, and focal length in the Exif!
In rawproc I made a dialog window into which I load the output of exiftool. Recently, I added a “grep” filter that removes all lines not containing the filter text. Not too hard to do, and quite useful.
In wxwidgets I subclassed the list control; should be able to do something similar in Qt. Beauty of the scheme is the user can change it to use any exif command line program, e.g., exiv2…
Just a small thing (but perhaps not that small to code…):
I noticed that Filmulator resizes the app window always to the same size when restarted, regardless of what dimensions (e.g. fullscreen) I chose before. The same applies for the size of the queue. Is ist possible that it keeps these settings for the next start?
And, to expand the wishlist for the future: When opening filmulator with several images from explorer/digikam, for each image a new instance of filmulator is started. Is it possible to start only one instance and import all images in this one?
I think remembering the window size and state should be doable.
As for additional imports being enqueued in the existing editor… I need to do some research. It’s probably a good idea to do this but I need to figure out how.
Great! Concerning the size there is a work-around in the Windows system but perhaps not for other systems, it would thus be good to have it in the app.
Because a workflow using different programs is not universally liked. Some people are fine with using a separate DAM, raw developer, stitcher, retoucher, print app and more besides for one photo. Others like to do as much as they can in just one program. It’s a personal preference and I guess it ultimately comes down to what the developer prefers.
@europlatus Well, it was a rhetorical question of course.
Nevertheless, there are so many varieties of all-in-one attempts on the market, FOSS and commercial, so that it seems to be wiser, not to start the next attempt but to concentrate on the developing process.
