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

ilia3101

@masc I've ran it on fedora too, though it needed some tiny extra package to be installed (forgot what it's called).

Quote from: masc on July 29, 2018, 12:34:24 PM
Until now we tried only x86 and x86_64 architecture. If Qt and ffmpeg runs on this Cortex, MLVApp should run as well - but I think you would be the first one trying that out. You will have to compile MLVApp on your own (but that's no big deal, if it is possible on that architecture). I travel with my old 13" MBP and a NextoDi.

I tried compiling on raspberry pi, but it seems to only have Qt 4 available by default, Qt5 would need to be manually compiled. Also getting the Qt-multimedia module is generally a pain on most distros (except the 2 that are in the compiling tutorial).

escho

Quote from: Ilia3101 on July 29, 2018, 05:04:24 PM

I tried compiling on raspberry pi, but it seems to only have Qt 4 available by default, Qt5 would need to be manually compiled. Also getting the Qt-multimedia module is generally a pain on most distros (except the 2 that are in the compiling tutorial).

Depends on the OS, you,ve flashed to the rasp, I guess
https://sternenkarten.com/
600D, 6D, openSUSE Tumbleweed

olofen

Can I use the MLV app to process Dual Iso videos?
If not what to use?  (High Sierra)
EOS 5D Mark III 1.2.3
Mac OS High Sierra

masc

Quote from: olofen on August 02, 2018, 06:54:23 PM
Can I use the MLV app to process Dual Iso videos?
If not what to use?  (High Sierra)
Yes you can use MLVApp for dual iso. Processing is 20bit (attaching low and high iso).
5D3.113 | EOSM.202

Jerchongkong

I cannot compile this in windows, how can I fix it?  ???

togg

Quote from: bouncyball on July 15, 2018, 10:05:46 AM
@togg

Upload the sample please.

Here: http://www.mediafire.com/file/sd70wi2ziuxnrbh/Extreme_hot_pixel/file 

I've cutted a sample of an MLV file that has a lot of bad pixels, mostly fixed by the aggressive pass but around 5 or more still passed on. I think the detection could be improved.

50mm1200s

@masc @bouncyball sorry for the late reply. I did not gave up on the darkframe issue, just had some work to do...

Sorry if this post is too 'verbose'. I didn't know what info was relevant, so I copied most of it.
From many tests, the function "getMlvRawFrameDebayered" on video_mlv.c always shows up on all demosaicing algos, except LMMSE. Lines 411 and 435 of video_mlv.c for Bilinear, AMaZE and IGV. See below for details...

I'm using MinGW to compile, not VS.
Tested again, with the change committed.
With AMaZE, it segfaulted on line 1496 of amaze_demosaic.c (reproduced twice):


blue[row][col]=65535.0f*(rgbgreen[indx]-Dgrb[1][indx>>1]);


Too many warnings, most of them saying "redundant parenthesis surrouding declarator". So I copied only the ones I've found to be relevant:


MLV-App\src\debayer\amaze_demosaic.c:137: warning: implicit conversion increases floating-point precision: 'float' to 'double'
MLV-App\src\debayer\amaze_demosaic.c:153: warning: implicit conversion loses floating-point precision: 'double' to 'float'
MLV-App\src\debayer\amaze_demosaic.c:331: warning: implicit conversion loses floating-point precision: 'double' to 'float'
MLV-App\src\debayer\amaze_demosaic.c:332: warning: implicit conversion loses floating-point precision: 'double' to 'float'
MLV-App\src\debayer\amaze_demosaic.c:1071: warning: implicit conversion changes signedness: 'int' to 'unsigned int'
MLV-App\src\debayer\amaze_demosaic.c:1364: warning: implicit conversion loses floating-point precision: 'double' to 'float'
MLV-App\src\debayer\amaze_demosaic.c:1364: warning: implicit conversion increases floating-point precision: 'float' to 'double'
MLV-App\src\debayer\amaze_demosaic.c:1364: warning: implicit conversion increases floating-point precision: 'float' to 'double'
MLV-App\src\debayer\amaze_demosaic.c:1365: warning: implicit conversion loses floating-point precision: 'double' to 'float'
MLV-App\src\debayer\amaze_demosaic.c:1365: warning: implicit conversion increases floating-point precision: 'float' to 'double'
MLV-App\src\debayer\amaze_demosaic.c:1365: warning: implicit conversion increases floating-point precision: 'float' to 'double'
MLV-App\src\debayer\amaze_demosaic.c:1366: warning: implicit conversion loses floating-point precision: 'double' to 'float'
MLV-App\src\debayer\amaze_demosaic.c:1366: warning: implicit conversion increases floating-point precision: 'float' to 'double'
MLV-App\src\debayer\amaze_demosaic.c:1366: warning: implicit conversion increases floating-point precision: 'float' to 'double'
MLV-App\src\debayer\amaze_demosaic.c:1367: warning: implicit conversion loses floating-point precision: 'double' to 'float'
MLV-App\src\debayer\amaze_demosaic.c:1367: warning: implicit conversion increases floating-point precision: 'float' to 'double'
MLV-App\src\debayer\amaze_demosaic.c:1367: warning: implicit conversion increases floating-point precision: 'float' to 'double'
MLV-App\src\debayer\amaze_demosaic.c:1394: warning: implicit conversion loses floating-point precision: 'double' to 'float'
MLV-App\src\debayer\amaze_demosaic.c:1394: warning: implicit conversion increases floating-point precision: 'float' to 'double'
MLV-App\src\debayer\amaze_demosaic.c:1394: warning: implicit conversion increases floating-point precision: 'float' to 'double'
MLV-App\src\debayer\amaze_demosaic.c:1402: warning: implicit conversion loses floating-point precision: 'double' to 'float'
MLV-App\src\debayer\amaze_demosaic.c:1402: warning: implicit conversion increases floating-point precision: 'float' to 'double'
MLV-App\src\debayer\amaze_demosaic.c:1402: warning: implicit conversion increases floating-point precision: 'float' to 'double'
MLV-App\src\debayer\amaze_demosaic.c:1549: warning: implicit conversion loses floating-point precision: 'double' to 'float'
MLV-App\src\debayer\amaze_demosaic.c:1549: warning: implicit conversion increases floating-point precision: 'float' to 'double'
MLV-App\src\debayer\amaze_demosaic.c:1550: warning: implicit conversion loses floating-point precision: 'double' to 'float'
MLV-App\src\debayer\amaze_demosaic.c:1550: warning: implicit conversion increases floating-point precision: 'float' to 'double'
MLV-App\src\debayer\amaze_demosaic.c:1551: warning: implicit conversion loses floating-point precision: 'double' to 'float'
MLV-App\src\debayer\amaze_demosaic.c:1551: warning: implicit conversion increases floating-point precision: 'float' to 'double'


On the second and fourth attempt it segfaulted on line 361 of amaze_demosaic.c, same warnings:


memset(nyquist, 0, sizeof(char)*TS*TSH);


So I tried again, just to be sure the issue was on line 1496 and 361, but this time it segfaulted on line 432 of video_mlv.c. What the f*ck:


uint16_t * unprocessed_frame = malloc( rgb_frame_size * sizeof(uint16_t) );


Tried again, and he segfaulted on line 411 of video_mlv.c:


memcpy(outputFrame, video->rgb_raw_current_frame, frame_size)


And 435 of video_mlv.c (same as IGV, see below):


getMlvRawFrameDebayered(video, frameIndex, unprocessed_frame);


Using IGV and Bilinear for demosaicing, he crashed on line 388 of igv_demosaic.c:


chr[d][indx]=(eg*nv+ng*ev)/(ng+eg);


Also line 489 of video_mlv.c:


get_mlv_raw_frame_debayered(video, frameIndex, raw_frame, video->rgb_raw_current_frame, doesMlvAlwaysUseAmaze(video));


And line 435:


  getMlvRawFrameDebayered(video, frameIndex, unprocessed_frame);


LMMSE does not show the same issue on video_mlv.c. Instead, it crashes on line 338 of dmzhangwu.c:


OutputRed[i+dataOffset] = OutputGreen[i+dataOffset] - DiffGR[i];


Some stuff shows on malloc.h. He repeats many times this warning:


warning: macro name is reserved identifier


There's one different warning on first lines of malloc.h:


warning: unterminated '#pragma pack (push, ...)' at end of file



I'll boot Debian now and see if I can run some memory debugger...

50mm1200s

Since I was already compiling MLVApp, thought it would be nice to test the WB branch.

With picker on 18% gray card:



With skin WB picker:



With WhiteBalance branch with the same settings as the 18% picker:



With WhiteBalance branch trying to match 18% picker:


50mm1200s

Comparison between Saturation and the new Vibrance implemented by @masc

Saturation at 75:


Vibrance at 75:


Vibrance at 100:

50mm1200s

@masc, found this bug on clipped highlights while using IGV. Here's the MLV.


Jerchongkong

Someone knows how I can compile this program in windows, what libraries are used to do it? every time I try its impossible.

50mm1200s

Differences between demosaicing on MLVApp (I will stop flooding now, sorry about that):


masc

Quote from: Jerchongkong on August 02, 2018, 09:05:11 PM
I cannot compile this in windows, how can I fix it?  ???
Quote from: Jerchongkong on August 03, 2018, 04:44:17 AM
Someone knows how I can compile this program in windows, what libraries are used to do it? every time I try its impossible.
Sorry, but with this information nobody will be able to help you. First start reading the compiling instructions.

@50mm1200s:
Thanks for all your work debugging this issue. But that really sounds very very strange. For me it sounds somethings is going wrong, before, in memory.
QuoteUsing IGV and Bilinear for demosaicing, he crashed on line 388 of igv_demosaic.c:
igv_demosaic.c crashes if you use bilinear? That should be impossible.

QuoteLMMSE does not show the same issue on video_mlv.c. Instead, it crashes on line 338 of dmzhangwu.c:
dmzhangwu.c is the LMMSE debayer function - so far so good.

amaze, lmmse and igv is copied from elsewhere - we did not implement that. And if all the algos crash, there really should go something wrong before. And I don't believe there are bigger bugs inside the algos. So if that crashes I more think something "around" of our implementation is buggy... but now it becomes difficult. I still can't reproduce that on any of mine computers. I really would like to help finding!!!

QuoteSome stuff shows on malloc.h. He repeats many times this warning:...
malloc.h??? This is a standard library...

I downloaded your file and can't get the IGV bug visible. What else did you do to have that? I just loaded the file and set to IGV.
Edit: I get something similar when loading (a wrong) darkframe and clicking wildly on any RAW Corrections... but the behavior is undefined, visible only at IGV.
Edit2: Something in the IGV debayer is strange: if I disable the debayer WB correction, the artifacts are gone. But if you load any high contrast clip it looks like sh**. Something is clipping, but I am not really able to debug the sources of IGV... sry.

Thanks for all the nice pictures... compairing the demosaic algos is very interesting, but the result is different for different clips.

5D3.113 | EOSM.202

masc

Quote from: togg on August 02, 2018, 11:56:30 PM
Here: http://www.mediafire.com/file/sd70wi2ziuxnrbh/Extreme_hot_pixel/file 

I've cutted a sample of an MLV file that has a lot of bad pixels, mostly fixed by the aggressive pass but around 5 or more still passed on. I think the detection could be improved.
Hm... I don't see bad pixels when option is enabled. I only see a lot of noise, because I have to adjust exposure in positive direction. Bad pixels would be the same in every image... this ones are filtered not bad, or what exactly do you mean?
5D3.113 | EOSM.202

togg

Quote from: masc on August 03, 2018, 09:51:04 AM
Hm... I don't see bad pixels when option is enabled. I only see a lot of noise, because I have to adjust exposure in positive direction. Bad pixels would be the same in every image... this ones are filtered not bad, or what exactly do you mean?

I had missed the "force" option, with it enabled they're almost all disappeared. To be sure I should check on a longer file and on dng export. Anyway way better than only "on", my bad!

50mm1200s

Quote from: masc on August 03, 2018, 09:38:03 AM
For me it sounds somethings is going wrong, before, in memory.

Yes, it's probably something with the memory and, since it don't happen on unix-like systems, it should be some windows-only expression or something.

Quote
igv_demosaic.c crashes if you use bilinear? That should be impossible.

No, that was a typo, thanks. I meant, bilinear crashs on 435 of video_mlv.c, the same with AMaZE and IGV. Reproduced this at least 6 times, just to be sure.

Quote
I really would like to help finding!!!

What can I do? The Valgrind idea could help finding...

Quote
malloc.h??? This is a standard library...

Yeah, but QTcreator shows it as something related to the crash. As you said, this is something with memory alocation.

Quote
I downloaded your file and can't get the IGV bug visible. What else did you do to have that? I just loaded the file and set to IGV.
Edit: I get something similar when loading (a wrong) darkframe and clicking wildly on any RAW Corrections... but the behavior is undefined, visible only at IGV.
Edit2: Something in the IGV debayer is strange: if I disable the debayer WB correction, the artifacts are gone. But if you load any high contrast clip it looks like sh**. Something is clipping, but I am not really able to debug the sources of IGV... sry.

The IGV bug happens on lastest "master". Just opened the MLV and change to IGV demosaicing.

bouncyball

Quote from: togg on August 03, 2018, 04:42:03 PM
I had missed the "force" option, with it enabled they're almost all disappeared. To be sure I should check on a longer file and on dng export. Anyway way better than only "on", my bad!
"Force" option forces searching of bad pixels for each frame, that is why it is more reliable for dynamic bad pixels, but takes lot more time.
You had to try also "aggressive" mode with "on" it removes more, even false alarmed, pixels.

Edit: I tested "On" + "Aggr" (aggressive) with your clip and it removed all unwanted stuff easily.
Edit2: well maybe some small cyan colored ones left unremoved...

masc

Quote from: 50mm1200s on August 03, 2018, 06:21:32 PM
What can I do? The Valgrind idea could help finding...
The IGV bug happens on lastest "master". Just opened the MLV and change to IGV demosaicing.

Valgrind is a good idea. If you know how to use?! I tried inside QtCreator (has Valgrind support after manual installation), but in this field I am a noob... and got nothing to work :D

Latest master, opened, IGV:
5D3.113 | EOSM.202

Danne

Cool debayering previewer. Did not know it was there. Checked with zoom function and all was working fine here.

olofen

just a notice on the timeline-percentage counting down while processing MLV files: it is sticky!!! meaning when changing to another program in mac High Sierra it does not go away - it is permanent whatever other program you decide to work with (intentional?)
EOS 5D Mark III 1.2.3
Mac OS High Sierra

Danne

Mlv App compiler now supports openmp(faster action):
https://bitbucket.org/Dannephoto/mlv_app_compiler/commits/512f6dbb819270b9b6eec857ccc1c3f31bf696c7

If compiler already downloaded it should ask you for updating of the scripts within 24hours or else download link is at the first post in this thread. Thanks to @masc for pointing out.

masc

Quote from: Danne on August 04, 2018, 01:58:29 PM
Mlv App compiler now supports openmp(faster action):
https://bitbucket.org/Dannephoto/mlv_app_compiler/commits/512f6dbb819270b9b6eec857ccc1c3f31bf696c7

If compiler already downloaded it should ask you for updating of the scripts within 24hours or else download link is at the first post in this thread. Thanks to @masc for pointing out.
Note that openmp version is still buggy!!! That is why next version is not yet released. But this next official version will have openmp! First tests on my old 2010 MacBook bring 30-40% more speed, when using "AMaZE cached" also up to 60% more speed than in last version. But here and there it is still tricky in the code...

Quote from: olofen on August 04, 2018, 09:42:59 AM
just a notice on the timeline-percentage counting down while processing MLV files: it is sticky!!! meaning when changing to another program in mac High Sierra it does not go away - it is permanent whatever other program you decide to work with (intentional?)
Yes it is intentional. Otherwise MLVApp would look like not responding and this little percentage window would be somewhere in background. You can move it where you want, if it is in front of another window. If you now what window flag has to be set, that this window is always in front of the main window, but behind any other app window, let me know!
5D3.113 | EOSM.202

50mm1200s

Quote from: masc on August 04, 2018, 07:44:01 PM
Note that openmp version is still buggy!!! That is why next version is not yet released. But this next official version will have openmp! First tests on my old 2010 MacBook bring 30-40% more speed, when using "AMaZE cached" also up to 60% more speed than in last version. But here and there it is still tricky in the code...

This might be useful: TaskSanitizer

Quote
TaskSanitizer implements a method to detect determinacy races in OpenMP tasks. It relies on open-source tools and is mostly written in C++. It launches through a custom Bash script called tasksan which contains all necessary command-line arguments to compile and instrument a C/C++ OpenMP program. Moreover, it depends on LLVM/Clang compiler infrastructure and contains a compiler pass which instruments the program undertest to identify all necessary features, such as memory accesses, and injects race detection runtime into the produced binary of the program. Race detection warnings are displayed on the standard output while the instrumented binary executes. TaskSanitizer also relies on LLVM's OpenMP runtime (https://github.com/llvm-mirror/openmp) which contains runtime interface for performance and correctness tools (OMPT). OMPT signals events for various OpenMP events -- such as creation of a task, task scheduling, etc. -- and TaskSanitizer implements necessary callbacks for these events for tacking and categorizing program events of each task in the program.

Danne

Because of the experimental nature of openmp, problems compiling on older macOS and so on I keep the alternative to compile two ways in Mlv_app_compiler.app:

IDA_ML

Quote from: masc on August 04, 2018, 07:44:01 PM
But this next official version will have openmp! First tests on my old 2010 MacBook bring 30-40% more speed, when using "AMaZE cached" also up to 60% more speed than in last version. But here and there it is still tricky in the code...

Wow, this is very good news!  If you guys manage to increase speed, this is going to be a real breakthrough in RAW video post processing.  Keeping my thumbs pressed for you!