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

50mm1200s

Quote from: Teamsleepkid on July 21, 2018, 02:49:05 AM
prores raw would be awesome because its like raw and a proxy in the same file (you can play it back with regular hardware). if we could output to prores raw that would be cool. also if i could put my a7sii footage through and have it come out prores raw that would be cool too. no app for that yet on the market. i know the a7s footage wouldn't be raw but it would be the same file format as my eosm footage and that would be awesome. please don't consider this as a request or demand just talking trash.

You cannot convert non-raw data into raw bayer data. I think you folks need to read more about what a Raw image is, so you can understand the process.

masc

Quote from: 50mm1200s on July 21, 2018, 12:54:09 AM
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?

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?
5D3.113 | EOSM.202

50mm1200s

Quote from: masc on July 21, 2018, 11:05:34 AM
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

One of the outputs seems to be BS from the debugger:
https://social.msdn.microsoft.com/Forums/en-US/aeb5b9a7-d23a-43bb-a8c7-131b853d05de/loads-of-senseless-debug-info-show-up-in-the-qt-application-output-window-when-i-run-a-simple-test?forum=windbg

So all warnings up to now are related to memory issues. Could Valgrind detect it, perhaps?

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

Cool, I'll see if I can test with the new parameter and confirm the video_mlv.c issue.

masc

@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 ;)
5D3.113 | EOSM.202

bouncyball

Quote from: 50mm1200s on July 21, 2018, 03:14:10 PM
So all warnings up to now are related to memory issues. Could Valgrind detect it, perhaps?
Cool, I'll see if I can test with the new parameter and confirm the video_mlv.c issue.
Now it's rolling to the right direction! Cool man! Thanx! You are one step closer to become MLV App dev :D (what we're gonna appreciate very much).

bb

bouncyball

Quote from: masc on July 21, 2018, 04:34:44 PM
But would be nice to know that it compiles with Visual Studio as well ;)
I tried it once but experienced fiasco. Very interesting if it's possible w/o a big PITA.

bouncyball

Quote from: 50mm1200s on July 21, 2018, 12:54:09 AM
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'

Makes no sense :(

All vars/parameters are with correct types there. No any type conversion is done.

Seruji

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.



masc

Quote from: Seruji on July 23, 2018, 11:35:04 AM
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
5D3.113 | EOSM.202


theBilalFakhouri

Hello @masc @Ilia3103 @bouncyball  and everyone :D

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

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

Danne

Seems very hard to get cameraspecific color matrices workinf in Mlv App. I think Ilia built a custom one derived from 5D mark II camera files. I wonder if a "correction" 3D lut could help here.

bouncyball

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

masc

Quote from: theBilalFakhouri on July 26, 2018, 06:32:48 PM
Hello @masc @Ilia3103 @bouncyball  and everyone :D

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

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

Quote from: bouncyball on July 26, 2018, 07:12:49 PM
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...
5D3.113 | EOSM.202

ilia3101

Ok calm down I've heard a lot of complaints about the wrong colours.

Some things:
1. I would like to bust a myth - MLV App does not use any colour matrices at all right now, no "5D2 matrix for all cameras" things going on, that is just not true and I'm not sure how the myth started. Maybe it's because the white balance multipliers are generated by data I extracted from 5D mark II photos using exiftool, however that does not affect colour in any deep 5D mark II way, they simply specify the channel multiplication factors and that is it. I'm really surprised they even work considering it is unknown what colour space they are for.
2. That(fixing the colours) is actually the processing improvement I was talking about some time ago. I have been a bit demotivated though, as every time I start working on it it just gets fiddly or crashy or something is wrong with the colour(most often this). The extreme hotness of summer combined with that makes for a perfect giving up vibe.
3. @masc @bouncyball Is the WhiteBalance branch still mergeable? I don't know how to do it locally in git sorry(I can only ruin the whole github repository :D), could one of you try it out?
4. @masc Could you show a sample(s) of where WhiteBalance branch looks worse? I was thinking it might do. If this gets put in to the app, I will make sure to add an "MLV App classic" processing mode just to keep how it was before for those who had good results with it.
6. camera_matrices.c is obsolete version of what bouncyball's camid does and will be removed. Thank you for the reminder.

masc

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.
5D3.113 | EOSM.202


theBilalFakhouri

Thanks for all for clarifying what's happening I will provide tomorrow some clips in different WB situations. @masc Sometimes the colors looks good but not natural as the camera showed it.

Edit: Okay wait the colors isn't that bad I will feedback tomorrow with some comparing photos.

olofen

What are the minimum hardware (and software? Linux?) requirements for running the MLV app converting MLV files to H 264 files?
EOS 5D Mark III 1.2.3
Mac OS High Sierra

ilia3101

What kind of hardware and software are you thinking of running it on??? I don't think hardware and software support has ever been a worry with MLV App.

It will run on any Linux distro as long as ffmpeg and qt5 work on it (you will have to compile yourself if you have a 32 bit). I have used it on a laptop from 2006 before.

Danne

@Ilia3101
In processing.c this:
/* Measurements taken from 5D Mark II RAW photos using EXIFtool, surely Canon can't be wrong about WB mutipliers? */
static const int wb_kelvin[]   = {  2000,  2500,  3000,  3506,  4000,  4503,  5011,  5517,  6018,  6509,  7040,  7528,  8056,  8534,  9032,  9531, 10000 };
static const double wb_red[]   = { 1.134, 1.349, 1.596, 1.731, 1.806, 1.954, 2.081, 2.197, 2.291, 2.365, 2.444, 2.485, 2.528, 2.566, 2.612, 2.660, 2.702 };
static const double wb_green[] = { 1.155, 1.137, 1.112, 1.056, 1.000, 1.000, 1.000, 1.000, 1.000, 1.000, 1.000, 1.000, 1.000, 1.000, 1.000, 1.000, 1.000 };
static const double wb_blue[]  = { 4.587, 3.985, 3.184, 2.524, 2.103, 1.903, 1.760, 1.641, 1.542, 1.476, 1.414, 1.390, 1.363, 1.333, 1.296, 1.263, 1.229 };

How did you find these numbers? How can I find them for let´s say eos 100D?

masc

Quote from: olofen on July 28, 2018, 11:37:32 PM
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.
5D3.113 | EOSM.202

olofen

Quote from: masc on July 29, 2018, 10:02:50 AM
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.

I am planning (if possible...) to use a small single board computer, an Odroid-xu4 https://www.amazon.com/ODROID-XU4-Single-Board-Computer-Gigabit/dp/B0163GEA64 or similar while travelling. To be able to convert the MLV files to H264 too see the actual movements in realtime of the videoclips at the place of filming. Without having to bother with a big laptop or such....

...or perhaps you have a better portable solution?!
EOS 5D Mark III 1.2.3
Mac OS High Sierra

masc

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.
5D3.113 | EOSM.202

ilia3101

Quote from: Danne on July 26, 2018, 08:51:01 PM
@Ilia3101
Here are a few examples:
https://www.magiclantern.fm/forum/index.php?topic=20025.msg201167;topicseen#msg201167

Thanks for that, looks very wrong. I also looked at WhiteBalance branch code recently and it seemed all wrong in there too :D I can't imagine what went on for me to have wrote that and thought it made sense.

Quote from: Danne on July 29, 2018, 01:17:15 AM
@Ilia3101
In processing.c this:
/* Measurements taken from 5D Mark II RAW photos using EXIFtool, surely Canon can't be wrong about WB mutipliers? */
static const int wb_kelvin[]   = {  2000,  2500,  3000,  3506,  4000,  4503,  5011,  5517,  6018,  6509,  7040,  7528,  8056,  8534,  9032,  9531, 10000 };
static const double wb_red[]   = { 1.134, 1.349, 1.596, 1.731, 1.806, 1.954, 2.081, 2.197, 2.291, 2.365, 2.444, 2.485, 2.528, 2.566, 2.612, 2.660, 2.702 };
static const double wb_green[] = { 1.155, 1.137, 1.112, 1.056, 1.000, 1.000, 1.000, 1.000, 1.000, 1.000, 1.000, 1.000, 1.000, 1.000, 1.000, 1.000, 1.000 };
static const double wb_blue[]  = { 4.587, 3.985, 3.184, 2.524, 2.103, 1.903, 1.760, 1.641, 1.542, 1.476, 1.414, 1.390, 1.363, 1.333, 1.296, 1.263, 1.229 };

How did you find these numbers? How can I find them for let´s say eos 100D?

Those numbers specify multiplying factors from camera white balance (which is the same kind of green for all of the ML cameras it seems) to different temperatures, it does not affect colour in a colour space ey kind of way. If you used a 100D to extract those numbers you should get the same results, the colours wouldn't improve.
I took pictures in 500k white balance increments then used exiftool to get those numbers, I don't remember what the exif tag was called.

It's nothing to do with camera colour, it's just a super unscientific way of doing white balance.

Quote from: Ilia3101 on July 26, 2018, 08:21:24 PM
the white balance multipliers are generated by data I extracted from 5D mark II photos using exiftool, however that does not affect colour in any deep 5D mark II way, they simply specify the channel multiplication factors and that is it. I'm really surprised they even work considering it is unknown what colour space they are for.