What features are planned for Filmulator?

europlatus · November 22, 2019, 4:39am

I know Filmulator is designed to be a lean software, but I’m wondering what features are planned. Is sharpening, noise reduction, etc. planned?
What features are absolutely not planned? I assume things like local editing won’t be…

CarVac · November 22, 2019, 5:44pm

Regarding image processing features, I think sharpening, noise reduction, and Lensfun distortion/vignetting correction will be the extent of what I want to add.

I do intend to add new features to the database and output, though.

I want at least basic tagging for photos, but I need to come up with a good UI for that.

Also, I want the ability to save the enqueued photos as sequentially-numbered files to a user-selected directory instead of to where their raw files are located.

Finally, I want to add contact sheet generation; this seems to be something Adobe has that people frequently ask for from other programs.

europlatus · November 22, 2019, 11:37pm

Good to know.
I really enjoy the simplicity of it, but having at least sharpening and noise reduction would be very welcome. I was developing some raws yesterday that were shot with a high ISO, and Filmulator obviously couldn’t help me get rid of the color noise.
I’m not so interested in the cataloguing side of things because I already have a system and Filmulator won’t manage all the old JPEGs and TIFFs I have lying around.

I think what’s holding me back from using it more is that its usefulness is somewhat limited by how good the input is, i.e. how well the photo was captured in camera. As soon as you are dealing with problematic photos, you need to work with other software with more features. I have lots of old photos that were poorly composed, dust, scratches, colour fade, etc, and Filmulator isn’t really the best tool for the job.

But for well-shot photos with no blemishes and no extreme color/tonal problems, it does a really great job I think and is very fast. Great work! I’m looking forward to see it “develop”

afre · November 23, 2019, 1:24am

CarVac takes perfect images only with his perfect gear. If you are patient

Once this happens, you can do whatever you need to the raw files and then get the Filmulator treatment afterwards.

CarVac · November 23, 2019, 3:50am

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…

ggbutcher · November 23, 2019, 7:21pm

rawproc has two denoise tools for considertation. One is a straight implementation of NLMeans as described by @David_Tschumperle in his blog:

github.com

butcherg/rawproc/blob/master/src/gimage.cpp#L3268

    
      
          			}
          		}
          	}
          	imginfo["Libraw.Mosaiced"] = "0";
          	imginfo["PhotometricInterpretation"] = "2";  //RGB
          	c = 3;
          	return true;
          }
          
          

          
#ifdef USE_LIBRTPROCESS
          
          

          
bool gImage::ApplyDemosaicVNG(LIBRTPROCESS_PREPOST prepost, int threadcount)
          {
          	unsigned cfarray[2][2];
          	if (!cfArray(cfarray)) return false;
          
          
	//allocation "by-hand":
          	float **rawdata = (float **)malloc(h * sizeof(float *));
          	rawdata[0] = (float *)malloc(w*h * sizeof(float));

http://opensource.graphics/, search for “Non-Local Means”

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:

github.com

butcherg/rawproc/blob/master/src/gimage.cpp#L3357

    
      
          	float ** red = RT_malloc(w, h);
          	float ** green = RT_malloc(w, h);
          	float ** blue = RT_malloc(w, h);
          
          
	#pragma omp parallel for num_threads(threadcount)
          	for (unsigned y=0; y<h; y++) {
          		for (unsigned x=0; x<w; x++) {
          			unsigned pos = x + y*w;
          			rawdata[y][x] = image[pos].r * 65535.f;
          		}
          	}
          	
          	rcd_demosaic (w, h, rawdata, red, green, blue, cfarray, f);
          
          
	#pragma omp parallel for num_threads(threadcount)
          	for (unsigned y=0; y<h; y++) {
          		for (unsigned x=0; x<w; x++) {
          			unsigned pos = x + y*w;
          			image[pos].r = red[y][x]   / 65535.f;
          			image[pos].g = green[y][x] / 65535.f;
          			image[pos].b = blue[y][x]  / 65535.f;

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.

FWIW…

afre · November 23, 2019, 7:55pm

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 @rawfiner et al.'s approach to denoising. Slow but worth the trouble. Maybe in need of extreme simplification for Filmulator’s purposes.

heckflosse · November 25, 2019, 12:13am

About sharpening: I intend to port RT capture sharpening to librtprocess soon (probably before end of 2019)

RT dual demosaic would also play well with Filmulator imho.

PhotoPhysicsGuy · November 26, 2019, 1:59pm

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.

Sweet!

Agreed.

afre · November 26, 2019, 4:09pm

Could be but there are tools to evaluate quality.

PhotoPhysicsGuy · November 26, 2019, 4:17pm

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.

afre · November 26, 2019, 7:06pm

That is a conversation for another time and thread, and I am mostly definitely not the person to speak to on such matters.

Luemmel · October 18, 2020, 9:07pm

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…

CarVac · October 18, 2020, 10:45pm

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?

afre · October 18, 2020, 10:51pm

Could you strip the previews and keep the rest?

CarVac · October 18, 2020, 10:53pm

If I knew how…

If anyone can help, I certainly would. I’d like to generate new thumbnails for the JPEG too.

Luemmel · October 18, 2020, 11:00pm

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!

ggbutcher · October 19, 2020, 2:55am

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…

CarVac · October 19, 2020, 3:19am

I did some testing, and just restored copying all the data over for tiff. It works in GIMP (select the first page) and in RawTherapee.

I’ll try to upload a new build tomorrow.

Luemmel · October 20, 2020, 9:06am

Great! Will be happy to test.

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?