MLV App - All in one MLV Raw Video Processing App [Windows, Mac and Linux]

[masc]

The 200D build is very fresh and on its very early start. Maybe this isn't supported yet. Or maybe there are still some small bugs here and there. As already written: if all is fine, you should see horizontal lines in the image, when importing and dualiso is On in camera, but Off in MLVApp. The algorithm in MLVApp can only work correctly, if those lines are really there.

[rejok_25]

The 200D build is very fresh and on its very early start. Maybe this isn't supported yet. Or maybe there are still some small bugs here and there. As already written: if all is fine, you should see horizontal lines in the image, when importing and dualiso is On in camera, but Off in MLVApp. The algorithm in MLVApp can only work correctly, if those lines are really there.

Hello Sir, I can see lines on my camera when Dual-Iso is on and in raw-video mode via LV. But none if the dual-iso is off. Just having problem when imported to the MLVapp and the horizontal lines aren't there. Anyway, thank you for answering!

[masc]

No doubt: the image data in your file does not contain any dualiso information, apart from the metadata (which only tells you configured it in camera). I expect it to be a bug in the ML camera build. The cam seems not to record to the card what you saw on the screen.

[Walter Schulz]

Hi, masc!


MLVapp 1.5.0 in Windows 10 and 11. Footage: Non-Dual-ISO, with focus pixels.

Issue with an export setting:
- Using TIFF as export everything runs as intended. Multi-threaded processing rather well balanced across several "CPUs". Average around 30-60 percent together.
- Using "CinemaDNG lossless" with Resolve name scheme: A single "CPU" is doing most of the work and almost at 100%. Thus CPU used by MLVapp drops to around 10-12 percent on a 12-thread PC.

Can you fix this?

[masc]

Hi Walter,
I think you mean latest 1.15, but in the end the problem is the same in all versions. LJ92 algorithm is single threaded only. It is needed for lossless encoding and decoding. Until now there wasn't any way to multithread this algorithm. The only way for a more efficient export is multi-clip export, but the MLVApp export pipe isn't made for this. This would need a different implementation. For other export than cDNG this is no problem, because processing works multi threaded.
Over a year ago I started to implement a command line MLVApp receipt/session compatible export application, which exports each clip single threaded, but multi clip, with the exact same optical result. This is very efficient and around 2.5x faster for AVFoundation exports and much much faster for cDNG. Unfortunately other export pipes don't work at all. It also currently just works on macOS, and this not always. The reason why it is not uploaded or commited yet. I also lost the motivation a bit for this additional tool...

[Walter Schulz]

I tried the "uncompressed" option, too: Same performance behavior.

[masc]

Sure. Then there is nothing to do anymore: no (time consuming) algorithm working which could be splitted to multiple threads.

[Walter Schulz]

I'm not sure we are on the same page:
All three cDNG export options (Lossless, uncompressed, fast pass) have the same performance issue: It looks like a single "CPU" is doing most of the job and the rest is - more or less -idle.
This is all caused by having LJ92 option?

(Fast pass is indeed blazingly fast, btw.)

[masc]

All cDNG exports types (including fast pass) are realised by a single thread. Just most RAW corrections will be multi threaded, but the algorithms are too fast for noticing.
The only way for speed up is multi clip or multi pic export. Both is not supported by the currently implemented export pipe. It was the way things worked in a very old version of MLVApp (with faster cDNG export), but there were many good reasons to do it differently. The cmd version I wrote about does the multi clip export...

[Walter Schulz]

Thanks for explaining the issue! Appriciated!

[doktorkrek]

- Using "CinemaDNG lossless" with Resolve name scheme: A single "CPU" is doing most of the work and almost at 100%. Thus CPU used by MLVapp drops to around 10-12 percent on a 12-thread PC.

In Kinochrome, multi-threaded CinemaDNG export is done by distributing the encoding of different frames between multiple threads.

[names_are_hard]

That sounds a sensible approach.  Would you consider porting it into mlvapp?  It would be nice to have all the good parts in one place.

[masc]

This would also need a rewrite of the DNG export module - which should be possible, if you know how to do multi threading in standard C. Currently the module is not thread safe. You get kind of constructor (in C) and then you can export one frame at the time using the module.

Find the code in dng.c and dng.h
From MainWindow.cpp the export is triggered in startExportCdng. The call saveDngFrame(..) is not thread safe and can't be used multi threaded out of the box.

[ricardopt]

Hi everyone!

Im using the latest mlvapp on linux, anyone knows how to load/use the focus pixel map files? on windows there would be a download "triger" or we could copy the files to the mlvapp folder but how can i do it when the program is in the appimage "format"? ive been using the chroma smooth 3x3 option but wondering if i can use the focus pixel map files instead?

Thank you

[masc]

@ricardopt
Find the solution in the MLVApp-wiki or in-app-help.
https://github.com/ilia3101/MLV-App/wiki#fix-focus-dots