Messages

Not work Transformation (((
video 5D Mark III 50fps 1920x648 aspect ratio 1.67

I set the settings:
Widht Stretch 1.0x
Height Stretch 1.67x
RAW correction - Off

converts anyway with color and narrow frame

what to do?

You forgot to write how you export. I bet not using ffmpeg. Stretching is a ffmpeg only option.

Hello everybody! Trying the latest version, when i use darkframe subtraction randomly crash during export. About one clip over 4/5 randomly.
Someone can help me?

It is a known "Windows only" bug, which is not yet solved. None of the devs was able to reproduce it yet. https://github.com/ilia3101/MLV-App/issues/96
If it occurs on your system, you can try to debug. That could really help. 50mm1200s also tried that and gave many information...

Question : which solution is used for anti-aliasing ? Is it something related to optical flow ? Because it's warping a lot. Or is it the same solution used by Danne ?

Smooth aliasing filter works with optical flow and works best for scenes with only a little movement. Dannes script solution works with enfuse and works best for clips without movement.

Hello, I can't access to the latest version. There is nothing when I click to the link...

Which link do you use? Both working here...
https://github.com/ilia3101/MLV-App/releases
https://ilia3101.github.io/MLV-App/

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...

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!

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

Latest master, opened, IGV:

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?

[Edit]

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

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.

Using 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.

LMMSE 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!!!

Some 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.

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).

Sadly, there is NO 12 bits ProRes in FFmpeg.
But You, as a software developers, can help to fix that:
https://trac.ffmpeg.org/ticket/7163

Sadly true. But your link is about decoder, not encoder. 12bit prores can be encoded via AVFoundation on macOS only.

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.

What are the minimum hardware (and software? Linux?) requirements for running the MLV app converting MLV files to H 264 files?

MLVApp should run on any computer which is able to run Windows 7 (or newer) and OSX 10.8 (or newer). For Linux: our AppImage should run on Ubuntu 14.04 LTS or newer (maybe others too which use similar versions of packages). If you compile yourself it could run on many different distros (you just need ffmpeg and >=Qt5.6).
Hardware plays nearly no role: no GPU needed for example. So it should run also on very old computers and notebooks.

Ah, what a shame @escho... here some km in the north of you we have seen a very little more. We also had some clouds but I don't have the right gear to make good photos...
You all got nice shots!

I am very interested in the results! 

Thanks @Ilia!
Whitebalance branch is 11 commits ahead, 211 commits behind master. That makes it not easy to merge. I have a little fear.
If I remember right, it was working good for daylight clips, but was way to yellow for artifical light clips. The clip where I had big problems is deleted and I don't find it anymore... maybe you still have it?
https://github.com/ilia3101/MLV-App/commit/0e9025ec39407d8796534ad109a5c460c60caf9f
https://github.com/ilia3101/MLV-App/commit/6d0d21d183ce36d59ae7155194ba43b91d8ba37a

@theBilalFakhouri: do you have a 700D clip with bad colors, and a note in which SW it looks better? I never saw one... the 700D clips I have here are looking good in MLVApp.

Very nice @escho! You'll try to get some nice pictures tomorrow of the lunar eclipse?

[main reason]

Hello @masc @Ilia3103 @bouncyball  and everyone

The main reason why I don't use MLVApp for quick color grading or exporting to compressed format like H.265 is the weird colors compared to other software (I am using 700D). Back to this problem the causes of this was the color matrix right? MLVApp uses color matrix from 5D2 which present nice colors for this camera.

What should I do for implementing the color matrix for 700D in the app ? isn't it implemented for all cameras ? Can you give me where is color matrix has applied for 5D2 and what should I do to get 700D's color matrix in MLVApp in the code? Please .

I am wondering also if this difficult to apply ? and is there problems for that (Applying more than color matrix for each camera) ?
Thankss!

The camera matrices are implemented in camera_matrices.c, but are completely commented out, because there is no defined way to apply them - see Ilias comments in the code.
WB multipliers are set from 5D2 in processing.c (defined in line 18-22).

All camera matrixes are implemented and used in experimental WhiteBalance branch, but this branch has it's quirks and also has not updated a while. You can try your luck there

That was a try... but then 5D2 clips were ugly (which were perfect before). Don't know what exactly was the difference, but maybe only a small thing was wrong here - if you like you can try to debug there...

Hi guys!
Question: ¿When do you recommend to do the sharpen? ¿Before or after the export into pro res 4444)? Then I will import the clip to Adobe Premiere and use Lumetri to apply some lut's or some other color correction.

You asked this already and I answered:
https://www.magiclantern.fm/forum/index.php?topic=20025.msg202442#msg202442

@50mm1200s: did you compile with Visual Studio compiler? Normally we use MinGW (comes with Qt normally) - that should be different. But would be nice to know that it compiles with Visual Studio as well

I never used valgrind... but if you know how to use it... would be very cool if you could help

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

Code Select Expand


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


And warnings on lines 404, 408 and 409:

Code Select Expand


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


On line 409 it also says:

Code Select Expand


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:

Code Select Expand


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?

Thank you so much for debugging @50mm1200s. But that sounds all very strange. There is another problem on Windows with caching: I did not understand the problem Windows has there... on Unix all is fine. I will create a issue task on GitHub to save all your information. So we can collect all and read it easily. Maybe an idea comes one day...
https://github.com/ilia3101/MLV-App/issues/96

For line 409 I changed one parameter type. Maybe that helps. But I really don't understand the other warnings in line 404, 408 and 409. Is that really in video_mlv.c?

Found this neat open source software. Might be useful of everyone working with LUTs:
https://lattice.videovillage.co/

Nice. But open source? Download costs 199.99$. Or did I not look right?!

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?

...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.

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

Code Select Expand

if (threads < 2)
to

Code Select Expand

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.

Few years ago MlRawViewer did this pretty good but now it is abandoned... ((

...if you found a computer where it was working. I never had one until it was discontinued. The good thing at MLVProducer & MLVApp: they run on nearly every computer!

@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?

Code Select Expand

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.