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

Started by ilia3101, July 08, 2017, 10:19:19 PM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

bouncyball

Thank you but I could never manage to download files from wetransfer :(. Downloading ALWAYS stalls and can not be resumed.

Danne

Nice feedback IDA_ML.
I tested around a bit with your darkframe and additional crop mode footage. The averaging effect is very subtle but it´s there. I tested in Switch(sorry Mlv app) but wanted to check fast what mlv_dump is producing.
Darkframe averaging will work best with stressed footage. A bit under exposed(shadows will be cleaned) and also color cast from lenses so if the footage is properly exposed and you are using some good lenses the averaging effect will probably be minor.

IDA_ML

Quote from: bouncyball on March 15, 2018, 08:36:13 PM
Thank you but I could never manage to download files from wetransfer :(. Downloading ALWAYS stalls and can not be resumed.

Bouncyball,

May I suggest that you ask Masc to download the files for you (a total of about 2,4 GB).  I uploaded for him big files with Wetransfer in the past and he always succeeded downloading them.

Quote from: Danne on March 15, 2018, 08:44:00 PM
Nice feedback IDA_ML.
I tested around a bit with your darkframe and additional crop mode footage. The averaging effect is very subtle but it´s there. I tested in Switch(sorry Mlv app) but wanted to check fast what mlv_dump is producing.
Darkframe averaging will work best with stressed footage. A bit under exposed(shadows will be cleaned) and also color cast from lenses so if the footage is properly exposed and you are using some good lenses the averaging effect will probably be minor.

Indeed, I used a good lens, Danne - the EF 24/2,8 IS.  Also, I try to expose to the right.  If the footage is underexposed, then the signal to noise ratio will be worse and at this high ISO (3200), the picture will look much noisier.  In that case, DF averaging and subtraction will probably not help much either.  That is why I think that a monochrome noise reduction, in combination with Chroma Separation will work better.

masc

Thanks for the uploads and all you wrote here... that's really a lot! :)

Your clip A: it seems there is another problem with your processor and MLVApp. On my Core2Duo on macOS I can export without any problem. @bouncyball: can you test on your Windows? Edit: hmm... you can't... I could try to upload it somewhere else for you... but that will need some time @60kB/s :D

Your clip B: Indeed there is only very low static noise in this clip. That is why you can't see something. I tried to subtract it averaged from clip A, and yes... I see a very tiny difference in the low right corner of frame 1 (dark area)... but it is soooo small the difference...

Your clip C: When MLVApp tells 100% on export, MLVApp has finished rendering - but ffmpeg is still on the run. For me ffmpeg run ~1min after MLVApp was at 100%. Then OK was shown. Maybe this takes still more time on your PC - I don't know - but ffmpeg is what the app is waiting for. You should see ffmpeg in task manager - if it is still running - just wait ;)

Your ideas:
1. Whitebalance picker is a thing we want to realize since a long time. It is realized in the GUI already (only invisible for now), but in the apps core the functionality is still missing. I hope Ilia will find the time on day to realize it. :)
Dark/Light Strengh/Range is different from black & whites & contrast in ACR. Maybe Ilia finds a way one day to add that additionally. I never missed it, because Dark/Light Strengh/Range can do more (it is only harder to understand what it does).

2. If someone knows algorithms which do desired tasks it is not such big deal to realize that. Until now I did not hear something about a noise reduction algorithm here... maybe Ilia has an idea?! ;) Would be cool, no question.

4a: You can't drag all files to MLVApp?! Okaaay... for me that was working even on Windows. What not works: "Open with" with more than one file on Windows - on macOS that was no problem (works different). I'll try to search for that...

4b: Hm... I don't know how to create special thumbnails. Could be another task for the future. ;)

5: Speed optimization is very hard to realize. H264 is one of the slowest codecs to export. Maybe the settings are different to MLV Producer - no idea what settings it uses. If you like having a fast export - ProRes with option Anatolyi is one of the fastest (at least for me).
It may be that opening MLVApp more than once and exporting is faster: MLVApp and ffmpeg has be to synced. For syncing we get nearly never 100% CPU for processors with more than 2 cores - but I don't know how to change that. But maybe we have other ideas in future how to make that better! :)

Thanks again for all you wrote!
5D3.113 | EOSM.202

Danne

Tried this? Pretty fast:
-c:v libx264 -preset ultrafast -crf 10

masc

Thanks @Danne. Maybe I add that as additional export option. Until now we use -preset medium -crf 24
5D3.113 | EOSM.202

Danne

Yes, lot of alternatives :).
By the way. Maybe multprocess exports working in parallell? I noticed exporting one instance of ffmpeg at the time is time consuming so I start off 4 processes in parallell and my computer fans start working :).

IDA_ML

Finally, to complete my feedback, I would like to share with you part of a private communication in which Bouncyball and I were discussing the question:

MLVApp versus MLV Producer:  Which one is better?
==================================

In my opinion, since both software products work perfectly on laptops that are not powerful enough to run professional video editors such as DaVinci Resolve, they both are well suited for travel, mobility and field work - for checking the video clips directly from the camera card using a card reader, performing basic corrections on the clips and archiving them in ProRes 422 or another editable format for further work on them later.  The main advantage of MLVApp vs. MLVProducer in my opinion are the natural and vivid colors that indeed are difficult, even sometimes impossible to achieve with Producer.   On the other hand, Producer offers more intuitive controls and is quite a bit faster at export.  My honest opinion is that both products do not compete but complement each other and are perfect for travel when you cannot take your powerful desktop  with you.   I have them both installed on my laptop and plan to use them as follows:

1) I would use MLVApp if I do not plan further color corrections or grading and also for archiving my clips, (b.t.w., I love the file sizes).  In this case I would just apply all corrections that I need in MLVApp and export the clips in ProRes422 or 422LT.  Then I would just cut and mount the entire movie with Filmora or some other simple software that works fine on my old laptop which I like to take with me while traveling.

2)  I would use Producer when I plan to perform the basic color corrections and grading later, on a powerful desktop with DaVinci Resolve.  In that case, I would import all clips into Producer, apply a flat profile and/or LUT and possibly some basic adjustments and export in ProResFast 4444, accepted as ProRes 422 by Resolve.  This goes really fast with Producer on the same laptop and file sizes are quite acceptable.  Then I simply get rid of the huge MLV files and save more than 75% disk space on my laptop.  All the rest I do on my desktop with Resolve  when I get back home.

Bottom line:
========

The developer of MLV Producer AWPStar and the developers of MLVApp have done a fantastic job with their advanced and powerful software which is perfectly suited for travel and mobility work on a laptop.  Both products complement each other and work very well with MLV files.  Hopefully, the authors will continue improving them and making them faster and more efficient.


masc

@IDA_ML: if you like only fast export: deactivate RAW Corrections, set profile to a LOG curve and set in export settings AMaZE to Bilinear. Now your export should be more than 2x faster (in my example from 22sec to 9sec for exporting a special clip). For me, speed and look is very similar then to what MLV Producer exports.
5D3.113 | EOSM.202

bouncyball

Thank you IDA_ML for such a comprehensive feedback! :)

Quote from: masc on March 15, 2018, 10:23:45 PM
Edit: hmm... you can't... I could try to upload it somewhere else for you... but that will need some time @60kB/s :D
Thank you! I've downloaded them now :)
All files importing and can be processed here on Linux 64 bit w/o an issue or crashes after fiddling with sliders correction etc. At home I have my kids' computer with old CPU and windows 7 on it, but I don't have access to it ATM.

Quote from: masc on March 15, 2018, 10:23:45 PM
I see a very tiny difference in the low right corner of frame 1 (dark area)... but it is soooo small the difference...
Yes static magenta noise contaminating colors is quite low here so difference is really subtle, anyway you always can look at histogram, it changes in the dark/shadows part when activating deactivating DF.

Quote from: masc on March 15, 2018, 10:23:45 PM
Dark/Light Strengh/Range is different from black & whites & contrast in ACR. Maybe Ilia finds a way one day to add that additionally. I never missed it, because Dark/Light Strengh/Range can do more (it is only harder to understand what it does).
All is said about WB picker so I'm not stopping to discuss this further :)
Regarding Dark/Light Strengh/Range sliders used in MLV App. I fully agree with @masc, they are very powerful and nice to operate when you used to it. They almost substitute Curves editor b/c you can alter whole range of the histo. In addition we have highlights and shadows sliders which BTW present in the windows binaries I posted for older CPU compatibility ;) despite we did not release this feature officially yet.

Regarding noise reduction: there is only chroma blur function which kinda cleans color noise but this is not the full blown wavelet based noise reduction and should be taken with a grain of salt :)

Quote from: masc on March 15, 2018, 10:23:45 PM
4b: Hm... I don't know how to create special thumbnails. Could be another task for the future. ;)
Here is the explanation how this could be done for windows with Windows Imaging Component (WIC). Sorry but this is really out of the scope of the MLV App itself :). However windows programmers are always welcome to implement this kind of stuff.

Regarding export or playback speed: these can be altered by optimizing mlv app debayering/processing and ffmpeg behavior.

AFAIK mlvp uses ASM level optimised stuff and is quite fast.
Fast CinemaDNG uses directly CUDA and is blazing fast on my GTX1080.

We know that there is a lot of room for performance improvement and we really appreciate if anyone with spare time and more experience willing to join the project and help out.

Edit: now higher priority is the new color handling stuff added by Ilia and we are testing it, this concerns also more advanced white balancing and occasionally WB picker.

regards
bb

bouncyball

@Danne

Added DF validity check. If it has more than 1 frame MLV App warns with the message box but does allow to load file anyway. Why? ;)

Now I regret I did not introduce dedicated DF file format for our proggie for the mlv_dump's compatibility sake. mlv_dump does not correct framecount in the header of averaged DF MLV and it has full frame count of the original clip in the header. So there is nothing to check and if used mlv_dump made DF we can not check the amount of frames correctly. It will fail as any other non DF MLV (now it just warns you but allow to use mlv_dump made DF).

Anyway it is sometimes interesting to see the effect of the subtracting any image from any image so let it be there with just warning :D (I'm too lazy to dig into mlv_dump again :P, besides if someone has a collection of DFs made by switch they already are made by old not patched mlv_dump)

regards
bb

IDA_ML

Bouncyball and Masc,

I really am very satisfied with how you reacted to our suggestions for improvements.  With this kind of positive attitude and listening to the users, I am sure, MLVApp will continue to improve and become more efficient and powerful.  Thank you so much!

Bouncyball,

It looks like, that not only you but also your kids with their old CPU computer saved my MLVApp life by allowing you to reproduce my problem.  This is the reason why I never throw away my old computers.  You never know when you may need to use them again :-)))!  May I suggest that, before releasing a new build, you make sure that it also works on your kids' old computer?

Masc,

Thanks a lot for your very useful suggestions.  Of course, I will continue testing in trying to optimize my workflow and will report my findings.

Danne,

I am trying to figure out the darkframe averaging stuff and w.r.t. that I have a question to you too.  How important is it that darkframe footage is shot at exactly the same settings, (F-stop, focal length, ISO, shutter speed, etc.) as the clip that needs noise cleaning?  Can't I just shoot some darkframe footage for every lens that I use, at some reasonable ISO, (say 800) and then use this footage for creating an averaged frame for all the videos that I film with that lens?  What if the settings are different from those the clip was shot at?  Noise is noise - it's a random process, right?  Then why should it depend so much on particular settings?

Danne

@IDA_ML
What lens you are using won't matter(check flat frame subtraction for this. Also included in mlv_dump).
Also check some basics evolving df subtraction and where it's primarily used and why:
https://en.m.wikipedia.org/wiki/Dark-frame_subtraction

Reason it's used in movie sequences are availability and automation procedures.
Dark frame automation is what it is. Sometimes the impact will be major, sometimes not. Removing cold/hot pixels, cleaning magenta cast, color noise, banding in shadows etc. It won't destroy image like a denoiser which I think is important since df could then be used on any footage with any lenses all the time. It will have an impact even at iso 100. You can check this by raising shadow parts which reveals canon sensor flaws and how it's cleaned with df.
Matching iso is vital. Maybe even shooting the df right after the regular footage was recorded but I have been using darkframes recorded on a different time with great results.

IDA_ML

Thanks a lot, Danne, I will experiment more with dark frames and will do what you suggested.

bouncyball

Quote from: IDA_ML on March 16, 2018, 11:44:25 AM
It looks like, that not only you but also your kids with their old CPU computer saved my MLVApp life by allowing you to reproduce my problem.
:D

Quote from: IDA_ML on March 16, 2018, 11:44:25 AM
May I suggest that, before releasing a new build, you make sure that it also works on your kids' old computer?
Sure. The reason of this issue is known and patch committed to the repository additionally with Ilia's fine tuning :)

Quote from: Danne on March 16, 2018, 12:37:51 PM
Matching iso is vital. Maybe even shooting the df right after the regular footage was recorded but I have been using darkframes recorded on a different time with great results.
Danne's absolutely right, the roots of this suggestion came from the fact that when sensor is warming up the HW noise increases.

But we are not gonna process NASA photos, are we? :) So DF recorded with this particular camera and same settings earlier is OK.

BTW the video mode you are recording to also matters. Example: if you use same ISO for plain 1080p and crop_rec module enabled modes (even with the same resolution) the noise will be different because in some modes camera uses various bining and skipping, in some 1 to 1 readout and that 'in camera' processing affects output raw image, hence noise footprint.

regards
bb

IDA_ML

Thanks for this important clarification, Bouncyball.  Different noise at different shooting modes makes perfect sense.  I will probably generate several averaged DF at different ISOs and shooting modes for my 100D and use them whenever necessary.

At this moment another small improvement suggestion dawns on me.  Would it be possible to add to the "I" (information panel) the bit and compression settings for every clip, e.g. 8, 10, 11, 12 or 14 bits uncompressed or losslessly compressed video?  That would helpful too.

bouncyball

Hmm... do you mean this info should be on the right side of the clip thumbnail in session list?

Otherwise here is the info panel examples with all the info you need (4th line from the bottom):








That info panel can be left open while double clicking on clips in session list and the info will update on every selection.

regards
bb

jpegmasterjesse

Loving the app!  There is an old experimental version of the dual-iso.mo for the 5d2 that actually works pretty great!  The tough part was finding a post-processing workflow that worked for it.  The current version of switch works fine.

Unfortunately MLVApp has a hard time doing anything with it - my guess is that it's almost certainly a black level issue.

As I'm a complete fool for bleeding edge 5d2 stuff, I paired this experimental 12/10 bit build: https://www.magiclantern.fm/forum/index.php?topic=5601.msg198349#msg198349
with the dual-iso module, and attempted to do some darkframe subtraction as well.

Normal (non-dual) 10/12 bit stuff from that build works just perfectly in MLVApp.

By turning Switch to default settings, and then setting it to full-auto I was able to do 12 bit, dual-iso, darkframe subtraction in one fell swoop - which felt lucky.

Here's the problem - I end up with converted DNG's and would like to import them into MLVApp for editing/organizing.  I don't know of any way to repackage DNG's back into an MLV.

I know that's a lot of info, but I included some sample files, including the experimental Dual-Iso module here:
https://drive.google.com/open?id=1O2P64L0uvF3ai2GPuj3s5foJYL-rHyB9






IDA_ML

Quote from: bouncyball on March 16, 2018, 05:25:04 PM
Hmm... do you mean this info should be on the right side of the clip thumbnail in session list?

There is a shooting mode called "8 ... 11 bit lossless" and the camera selects 8, 9, 10 or 11 bits automatically, dependent on the light and ISO.  I am not sure if MLVApp can recognize if the clip was shot at say 9 bits or 11 bits or it will interpret these numbers as 8 or 10 bits.  This is what I mean.  Other than that, the Info panel is great!

bouncyball

@IDA_ML

Ah.. yes now I got it.

It's not possible to tell exact bit depth of those MLVs b/c in reality they are 14bit with restricted values (with amplified gain).

One can approximately say that the footage is 12bit lossless if 4500<white level<8000 and 8-11bits lossless if white level is less then 4500. Otherwise real 14bit data has >15000 value.

However I don't think that implementing this logic to the MLV App will give us the chance to make reliable assumption. This was one of the main reasons I added white/black levels to the Info Panel's 3rd line from the bottom :)

bouncyball

Quote from: jpegmasterjesse on March 16, 2018, 05:43:11 PM
Unfortunately MLVApp has a hard time doing anything with it - my guess is that it's almost certainly a black level issue.
I'm not sure what is the exact reason (full 20bit dualiso processing gives error and can not process this MLV). Preview mode does work. It is nice that you uploaded this sample. Can you also upload the dark frame original (not averaged) MLV for this 12bit clip?

Edit: Danne's doing some black magic with the switch/cr2hdr I guess ;)

Quote from: jpegmasterjesse on March 16, 2018, 05:43:11 PM
Here's the problem - I end up with converted DNG's and would like to import them into MLVApp for editing/organizing.  I don't know of any way to repackage DNG's back into an MLV.
It is possible and g3gg0 was doing this long time ago for experimenting/developing. However I can not imagine the use case of that backward conversion now :)

regards
bb

a1ex

Quote from: bouncyball on March 16, 2018, 06:49:38 PM
One can approximately say that the footage is 12bit lossless if 4500<white level<8000 and 8-11bits lossless if white level is less then 4500. Otherwise real 14bit data has >15000 value.

However I don't think that implementing this logic to the MLV App will give us the chance to make reliable assumption.

Using ceil(log2(white - black)) should be a reliable assumption, as this quantity is always 14 for 14-bit raw.

Examples:
ceil(log2(5586-2047)) = 12 (source)
ceil(log2(10500-2047)) = 14 (worst case; lowest white level I'm aware of at default settings is about 13500)

Displaying the fractional value of log2(white - black) should be fine as well, as you can see how many "bits" are lost because of the non-ideal black and white levels. In this case, the user can do the upper rounding to find the number of bits.

bouncyball


Danne

Quote from: jpegmasterjesse on March 16, 2018, 05:43:11 PM
Unfortunately MLVApp has a hard time doing anything with it - my guess is that it's almost certainly a black level issue.

By turning Switch to default settings, and then setting it to full-auto I was able to do 12 bit, dual-iso, darkframe subtraction in one fell swoop - which felt lucky.

Interesting finding. I downloaded your file and it worked with my older version of mlv_dump (m) passing the dng to cr2hdr but cr2hdr wouldn´t recognise the dng files as dualiso if run with mlv_dump_on_steroids.



Code mlv_dump versions:
mlv_dump(ml-dng version)
https://bitbucket.org/Dannephoto/magic-lantern/branch/ml-dng-unified_11f

mlv_dump on steroids:
https://bitbucket.org/Dannephoto/magic-lantern_steroids/branch/mlv_dump-on-steroids

After some more testing it works also with mlv_dump on steroids if you set mlv output to 14bit:



You can actually force dng to process as dualiso in later version of cr2hdr. Grab cr2hdr inside Switch and do following:
cr2hdr --force [drag your dng here]
The file won´t look good though but it forces through 12bit.