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 1 Guest are viewing this topic.

50mm1200s

@masc @bouncyball How can I debug? I'm using the binary from github. Tried to execute from terminal, but it's quiet (no verbose info, even with --debug). The binary seems to use QT 5.9.1. I don't know how to compile on windows, just on linux, and I don't think this issue happens on linux (from what you're saying)...

masc

Quote from: 50mm1200s on July 18, 2018, 10:37:33 PM
@masc @bouncyball How can I debug? I'm using the binary from github. Tried to execute from terminal, but it's quiet (no verbose info, even with --debug). The binary seems to use QT 5.9.1. I don't know how to compile on windows, just on linux, and I don't think this issue happens on linux (from what you're saying)...
You need a installed Qt and the source code. You load the .pro into QtCreator, setup the debug mode, press debug, do the crash, and Qt tells you where it crashes. For me it also does not crash on Windows...
5D3.113 | EOSM.202

olofen

MLV > CinemaDNG > TIFF  versus  MLV > TIFF directly

Do I get the same 14 bits of colour when I export files from the MLV app first as CinemaDNG and then convert them to 16 bit TIFF files as I would get if I export them directly into a TIFF stream from the MLV app?
Someone said that a TIFF stream directly from the MLV app only retains 8 to 10 bits of colour....
EOS 5D Mark III 1.2.3
Mac OS High Sierra

masc

Quote from: olofen on July 18, 2018, 11:49:49 PM
MLV > CinemaDNG > TIFF  versus  MLV > TIFF directly

Do I get the same 14 bits of colour when I export files from the MLV app first as CinemaDNG and then convert them to 16 bit TIFF files as I would get if I export them directly into a TIFF stream from the MLV app?
Someone said that a TIFF stream directly from the MLV app only retains 8 to 10 bits of colour....

No you don't get the same colour. But this is no question of bitdepth. MLVApp exports 16bit TIFF.
If you export TIFF directly you export processed data. If you export cDNG, you export RAW data. The RAW data has to be processed somewhere else. I bet it won't be processed in the exact same way as MLVApp does. So the colour will be different.
5D3.113 | EOSM.202

olofen

Quote from: masc on July 19, 2018, 12:08:00 AM
No you don't get the same colour. But this is no question of bitdepth. MLVApp exports 16bit TIFF.
If you export TIFF directly you export processed data. If you export cDNG, you export RAW data. The RAW data has to be processed somewhere else. I bet it won't be processed in the exact same way as MLVApp does. So the colour will be different.
What would you recommend - to make the adjustments in the MLV app as a Raw processor and export as processed Tiffs OR export as CinemaDNGs and process in a Raw processor like Photoshop?

I want to work with my videos in Photoshop therefore the CinemaDNGs...
Do you know any other way of getting the videos from MLV to photoshop as untouched as possible?

(I am an artist in photography for soon 40 years and now I going into film! My favourite tool since 1990 is Photoshop and I want to be able to continue with it if possible. I found out that I could import Avi´s and Tiff streams among others into it but I want to know which sort of file is the best one and got the most info to get me the maximum freedom in working with the films)
EOS 5D Mark III 1.2.3
Mac OS High Sierra

Dmytro_ua

Quote from: olofen on July 19, 2018, 07:08:40 AM
I want to work with my videos in Photoshop therefore the CinemaDNGs...
Do you know any other way of getting the videos from MLV to photoshop as untouched as possible?

If you're good with PS, then for video I recommend you to use After Effects as it uses Adobe Camera Raw to interpret DNG files.
I wouldn't use PS for video in any case.
5d3 1.2.3 | Canon 16-35 4.0L | Canon 50 1.4 | Canon 100mm 2.8 macro
Ronin-S | Feelworld F6 PLUS

masc

5D3.113 | EOSM.202

50mm1200s

Quote from: masc on July 18, 2018, 10:43:17 PM
You need a installed Qt and the source code. You load the .pro into QtCreator, setup the debug mode, press debug, do the crash, and Qt tells you where it crashes. For me it also does not crash on Windows...

Ok, I'm trying.


masc

Quote from: 50mm1200s on July 19, 2018, 11:15:13 AM
Just curious: does MLVApp autodetects white levels or use predefined values?
@a1ex explained why this would be a good idea:
https://www.magiclantern.fm/forum/index.php?topic=10111.msg98298#msg98298
https://www.magiclantern.fm/forum/index.php?topic=10111.msg98359#msg98359
MLVApp reads out the whitelevels which are saved in the MLV by the camera. These values might be wrong (I saw that @ 7D and others already), this is why we implemented RAW white level slider - so you can adjust it manually to the right value.

Quote from: 50mm1200s on July 19, 2018, 11:14:45 AM
Ok, I'm trying.
Great! Feel free to ask if you have problems with it...
5D3.113 | EOSM.202

50mm1200s

Quote from: masc on July 18, 2018, 09:08:27 PM
Yes, totally right. A denoising algo would be best. I could test this algo in MLVApp, because it was easy to adapt to what we need:
http://www.ipol.im/pub/art/2011/bcm_nlm/
It works but it is soooo slow - OMG - some minutes per frame, and only on Win & Linux multithreaded to work correctly. So no real solution for us ;)

:(
I've found this implementation of BM3D that according to the author "can be used in real-time video denoising", using CUDA:
https://github.com/JeffOwOSun/gpu-bm3d

There's also this page linking to many denoise code and papers:
https://github.com/wenbihan/reproducible-image-denoising-state-of-the-art

masc

Oh, this site looks interesting... so many algorithms?! Thx! Unfortunatelly CUDA is no solution for me... that works on none of my computers... :D (what is my main reason for developping this app)

BTW: IGV demosaic is available in MLVApp now! ;)
5D3.113 | EOSM.202

Danne

You are fast @masc.
What is IGV demosaicing doing? Hadn´t had the time to check into reading yet.

masc

Quote from: Danne on July 19, 2018, 02:32:43 PM
You are fast @masc.
What is IGV demosaicing doing? Hadn´t had the time to check into reading yet.
Puh... don't ask me... :D "Bayer CFA Demosaicing using Integrated Gaussian Vector on Color Differences". I found an implementation which was not to different from our AMaZE interface, adapted the code and voilà. In hard contrast scenes it looks slightly better than AMaZE, therefor it looks a bit more noisy (specially after sharpening). One disadvantage is a bad 8pix border, where the algorithm is not able to work - in this areas there is an easier border-algorithm working, which produces some artifacts (e.g. on water). Looks a bit like bilinear... but I don't really know... :P
5D3.113 | EOSM.202

50mm1200s

@masc QTCreator points me to line 361 of the file amaze_demosaic.c (on debayer folder), after segfaulting. He also has two warnings (line 364 and 366) saying: "use of GNU statement expression extension". If you need more information, just point me where to find it...

Also, IGV implementation is really nice. A Danne said, you're quite fast. Nice job.

edit: this is about the darkframe subtraction issue, BTW...

masc

Quote from: 50mm1200s on July 19, 2018, 03:30:18 PM
@masc QTCreator points me to line 361 of the file amaze_demosaic.c (on debayer folder), after segfaulting. He also has two warnings (line 364 and 366) saying: "use of GNU statement expression extension". If you need more information, just point me where to find it...

Also, IGV implementation is really nice. A Danne said, you're quite fast. Nice job.

edit: this is about the darkframe subtraction issue, BTW...
Thx! So it crashes in this line? memset(nyquist, 0, sizeof(char)*TS*TSH); No idea what could shut up amaze algorithm... :( I am lost. And I don't understand why it only crashes on export... preview is running 100% the same code.
5D3.113 | EOSM.202

50mm1200s

Quote from: masc on July 19, 2018, 03:41:39 PM
Thx! So it crashes in this line? memset(nyquist, 0, sizeof(char)*TS*TSH);

Yep. Or so does QT tells me, don't know if it's accurate...

Quote
No idea what could shut up amaze algorithm... :( I am lost. And I don't understand why it only crashes on export... preview is running 100% the same code.

Maybe because of multiprocessing? Memory allocation is different on both cases, don't?

masc

Quote from: 50mm1200s on July 19, 2018, 04:20:07 PM
Maybe because of multiprocessing? Memory allocation is different on both cases, don't?
Mulitprocessing is always running. But you could try to make amaze single threaded. Go to line 33 in debayer.c and change
if (threads < 2)
to
if (1)
Could you also test, if it happens the same with any other demosaic algorithm? You can now chose between 4 types in the export settings.
5D3.113 | EOSM.202

olofen

Quote from: masc on July 19, 2018, 10:43:23 AM
= RAW = CinemaDNG.


...but the MVL app almost look like a RAW processing app! Perhaps it gives enough of the videos as to be compared to a RAW processor?
And if so is AVI the best output to save the quality of the files? Or?
EOS 5D Mark III 1.2.3
Mac OS High Sierra

masc

Quote from: olofen on July 19, 2018, 10:41:24 PM
...but the MVL app almost look like a RAW processing app! Perhaps it gives enough of the videos as to be compared to a RAW processor?
And if so is AVI the best output to save the quality of the files? Or?
Sure - this was the main idea of the app. But, what do you do in Photoshop, if you color correct in MLVApp? If you like the look more than from Adobes RAW processor, use it! AVI has only 8 or 10 bits bitdepth. ProRes 4444 (AVFoundation on OSX) has 12bit. TIFF would be absolutely uncompressed and really huge.
5D3.113 | EOSM.202

olofen

Quote from: masc on July 19, 2018, 10:51:27 PM
Sure - this was the main idea of the app. But, what do you do in Photoshop, if you color correct in MLVApp? If you like the look more than from Adobes RAW processor, use it! AVI has only 8 or 10 bits bitdepth. ProRes 4444 (AVFoundation on OSX) has 12bit. TIFF would be absolutely uncompressed and really huge.


I want to do all sorts of filtering - parts or whole with many layers and even do special constructs. all in all work with every video just like with a still photograph. The exact look from the file coming out of the MLV app is not that important BUT what is is to have as much inrformation as possible in the file to work with

I think I will try CinemaDNG with the possibility of converting to TIFF and with a proxy of perhaps ProRes4444...

Is the TIFF files from the MLV app the same as going via CinemaDNG to TIFF? If so then I can use the MLV instead of CinemaDNG....

How about ProRes RAW?
EOS 5D Mark III 1.2.3
Mac OS High Sierra

masc

Quote from: olofen on July 19, 2018, 11:03:40 PM
Is the TIFF files from the MLV app the same as going via CinemaDNG to TIFF? If so then I can use the MLV instead of CinemaDNG....

How about ProRes RAW?
Already answered: https://www.magiclantern.fm/forum/index.php?topic=20025.msg204317#msg204317
It won't be the same and depends on how you get a picture out of the RAW CinemaDNG.

ProRes RAW is not supported by MLV App. And if it would be supported... RAW=RAW (in terms of encoded information), where shall be the difference?
5D3.113 | EOSM.202

Danne

Tiff=hardcoded white balance, the same goes for prores which also reduces color from 14 to 12 or 10bit. If you want layers on dng files run after effects or maybe lightroom.
If tiff files and photoshop works for you, just stick to that. Whatever you choose color and dynamic range information should be sufficient whatever you pick. Pay attention to white balance...

olofen

EOS 5D Mark III 1.2.3
Mac OS High Sierra

50mm1200s

Quote from: masc on July 19, 2018, 04:42:39 PM
But you could try to make amaze single threaded.
Quote
Could you also test, if it happens the same with any other demosaic algorithm? You can now chose between 4 types in the export settings.

Using bilinear demosaicing, it segfaulted on line 411 of video_mlv.c


memcpy(outputFrame, video->rgb_raw_current_frame, frame_size);


And warnings on lines 404, 408 and 409:

"implicit conversion changes signedness: 'int' to 'unsigned int'"


On line 409 it also says:


implicit conversion loses integer precision: 'uint64_t' (aka 'unsigned long long') to 'int'


The same happens using one thread ("if (1)" on debayer.c), with both bilinear and AMaZE.
There's a strage warning on application output, though:


ReturnHr(338) tid(23b8) 8007000F The system could not find the specified unit.
onecoreuap\shell\windows.storage\regfldr.cpp(1239)\windows.storage.dll!7666ED09: (caller: 7666C430)


Using LMSSE and IGV, the debugger doesn't seem to be able to find the issue. It just crashs: "The program has unexpectedly finished. The process was ended forcefully". And then points me to the debug folder.

Any idea?