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

IDA_ML

Masc,

Thanks for testing.

The left bright edge of the painting is pink here when i open it in MLVApp.  It could be just the preview but I am not sure.  It is strange that the artifacts do not appear on the edges of highest contrast but on moderate-contrast ones like on the laundry stand.  And yes, there is a little aliasing but this is normal for the 1x3 reading method.

IDA_ML

I have just exported a frame using the IGV algorithm.  Here is the result:




masc

Ah... I know. For dual iso clips you should disable Bad Pixel Fix. Because of all the lines the algorithm will often fail. This is without Bad Pixel Fix:
5D3.113 | EOSM.202

ilia3101

There is no reason to enable bad pixel fix almost ever, especially if it's dual ISO. No one has noticed my red pixel yet.

bouncyball

Quote from: masc on February 01, 2019, 06:08:47 PM
Using debugger the app exports in slow-motion and does not crash. LOL. As usual.
Yup :)

Open all chunks also called when darkframe mlv is loaded (no need for DF but that's how the basic MLV loading function works, which is reused there) so maybe there is hiding something...

bouncyball

Quote from: Ilia3101 on February 01, 2019, 07:23:36 PM
There is no reason to enable bad pixel fix almost ever, especially if it's dual ISO. No one has noticed my red pixel yet.
Right... ;) Except for some cameras like I had in the past (60D) with maybe 50 bad/hot pixels in every frame.

@masc: let's change it to off by default.



masc

5D3.113 | EOSM.202

DeafEyeJedi

Quote from: masc on February 01, 2019, 01:29:24 PM
Hoaa... what's going on here?! :D
My baaaaaaad... tehehe!  :-X

Quote from: masc on February 01, 2019, 10:29:18 AM
This is exactly the reason why I won't do it. Multiprocessing of inner processing is fighting against all other programs running at the same time.

Great call @masc!

Quote from: masc on February 01, 2019, 10:29:18 AMOMG! What crazy features are you using at the same time (dualiso?)?! The longest rendering time for 500GB was ~10hours for me (on my 8 years old i5)! :D

Really? That's really surprising... faster than my somewhat few years younger than yours? Only shot less than 10% in Dual-ISO for this little project.

Here are the features I used...



Quote from: masc on February 01, 2019, 10:29:18 AMThe problem aborting at corrupted frames was discussed many times here already. Mostly a corrupted file can't be handled for roundtrips, audio does not fit to video, linking does not work, etc. ... these are only some of the reasons why bouncyball and I decided to aborted export for corrupted clips. If just the last frame is currupted, this might be a a special case - but even than it leads very often to linking issues when working with Resolve or FCPX.

This makes perfect sense actually. Because even when I do restart it again and files spits out even with corrupted frames so this may rule out the reason why MLV App crashes during batch exporting? Frustrating but it is what it is and I've accepted the justifications.

Quote from: Danne on February 01, 2019, 09:11:05 AM
Is the problems happens due to mlv_dump code it should be possible to insert the "relaxed" mode skipping files right bouncyball?
If in ffmpeg the syntax could be changed to pass on missing files I believe.
Who knows where the issue lays?

Wildcard pass in ffmpeg?
ffmpeg -f image2 -i %*.jpg out.mov /*example*/

Excellent thinking. This smells like the good old days of Switch, MLP, cr2hdr... love you @Danne!

Quote from: bouncyball on February 01, 2019, 03:31:47 PM
The mlvapp import has nothing in common with mlv_dump code at all :)

Haha that was a bold statement. :)

Quote from: Danne on February 01, 2019, 09:11:05 AM
Let me make clear some "corrupted frame" aspects here.
1. mlvapp importer reads bytes from MLV but on that stage does not analyze any frame data itself for corruption.
2. errors come from the fact that _MLV_ itself is corrupted, e.g. specs are violated, header block missing or block size is not matched to the value written in the header etc etc ...
3. error is passed to higher (QT) part of the application, where the proggie (on error) spits out the message box with error and where some actions could be performed (skip, cancel etc).
So it is all about MLV corruption, not the particular frame, hence substitution with black frames is not applicable.

Thanks for the thorough explanation, BB and this also reminds me to ask does this have anything to do with shooting in Lossless 12-bit while we're at it? I'm only asking because it's happened again this morning... it looks like this.




I first thought it had to do with the file name chaging as I shot with three 5D3's and had multiple same MLV number files which then I had to change to prevent overwrite. This was all done before even touching MLV App so I highly doubt this is the issue.

Could it be related to certain large MLV files? like over 7K frames and whatnot? Again after each crash I just simply erase the last corrupted file and redo which then spits out OK.

Quote from: Danne on February 01, 2019, 09:11:05 AM
BTW mlvapp has built in brute force method (I've implemented long time ago) if the block header could not be found on common/expected address offset, proggie searches the block name until the end of file. I have one corrupted MLV like this and mlvapp loads it fine, slower though.

Good to know. Thanks!

Quote from: Danne on February 01, 2019, 09:11:05 AM
Now what can we do: introduce somewhere checking option allowing, on error, stop processing of current MLV (leave all files produced intact) and proceed to the next one without user intervnention. This will finish whole batch despite corrupted MLVs.
I guess only problem here will be with linking as masc described above. But if one let the option (I described above) checked, he/she already agreed that this could happen.

Hmmm.... that's not a bad idea after all. That's like agreeing to take the risk. As we should. Ha!

Quote from: Danne on February 01, 2019, 03:45:59 PM
Now we´re talkin´ 8)
8)

Quote from: bouncyball on February 01, 2019, 04:02:15 PM
;D

Yes, and one more thing, the real single frame corruption can be detected only when decoding wrong lossless raw data by LJ decoder (it spits error that data can not be decompressed). If raw is uncompressed we can not detect corruption until we look at the image on the screen :D

So it does have to do with the fact that I shot everything on this project in 12-bit lossless? I didn't even know I had corrupted frames with files (especially coming from a 5D3) but I was using an experimental build obviously to get the bleeding edge. hehe.

Quote from: bouncyball on February 01, 2019, 04:11:02 PM
Haha :) flickering would happen only if we will implement processing of EVEN and ODD frames in mlvapp. Then one instance of mlvapp should process the odd frames with different settings than second instance even frames ;D
:)

Quote from: Danne on February 01, 2019, 02:19:34 PM
hehe, anyway. Anamorphic modes on eosm recorded in dual iso as always comes out very, very nice. Bouncyball did some really good job here with getting the dual iso files working with all bits. One should start using the cam more often  :P

Speaking of Dual-ISO coming from EOSM while in Anamorphic mode... this was shot in 24p ISO 100/1600 @ 10mm 2.8 in 1504x640 and where'd all the aliasing go?



Quote from: masc on February 01, 2019, 07:49:51 PM
Done.

While this could be nice but I do use Bad Pixel Fix whenever I have a dead/hot pixel coming from one of my older KomputerBay CF cards.
5D3.113 | 5D3.123 | EOSM.203 | 7D.203 | 70D.112 | 100D.101 | EOSM2.* | 50D.109

masc

Quote from: DeafEyeJedi on February 01, 2019, 08:18:10 PM
Here are the features I used...


Okay. Denoiser and highlights slider need some CPU power. But not soo much. Using lossless files slows down processing too.

Quote from: DeafEyeJedi on February 01, 2019, 08:18:10 PM
While this could be nice but I do use Bad Pixel Fix whenever I have a dead/hot pixel coming from one of my older KomputerBay CF cards.
I don't think this is possible. Bad (dead/hot) pixels should always come from your sensor (or do I missunderstand?!).
Bad Pixel Fix can still be activated. ;)
5D3.113 | EOSM.202

bouncyball

Quote from: DeafEyeJedi on February 01, 2019, 08:18:10 PM
this also reminds me to ask does this have anything to do with shooting in Lossless 12-bit while we're at it?
.....
Again after each crash I just simply erase the last corrupted file and redo which then spits out OK.
Well, as you understand it is hard to understand the exact reason because of the random nature of the issue you are experiencing. Unfortunately I can not reproduce it :(.

Could be 12bit lossless as well. Sometimes this kind of footage is a bit tricky to handle due to lower white level and ugly scaling requirement for proper dual iso processing.

bouncyball

Quote from: masc on February 01, 2019, 08:37:07 PM
Bad (dead/hot) pixels should always come from your sensor (or do I missunderstand?!).
It is truth.

For MLVs taken from bad flash card the image artifacts will be far more severe. Could even be fatal for this particular MLV :).

70MM13

wow deafeyejedi, that image looks absolutely stunning!

what lens did you use?  i have a couple of friends that are interested in the eos m, and this might make a big difference...

togg


IDA_ML

Thanks a lot, Masc, for finding this easy fix.  I turned Bad Pixels off and the ugly pink artifacts are gone now completely!

masc

Quote from: togg on February 02, 2019, 12:28:41 AM
oh noooo, Canon cameras are so prone to bad pixels!! that default option is a life saver!!
No worries... option is still there! You can enable it whenever you need it.
5D3.113 | EOSM.202

Danne

Retested exports and seems ffmpeg runs fine exporting single files. Cpu working hard. Multiprocessing might not be needed as badly after all.
Also, the hsl features are super useful for correcting color.

Lars Steenhoff

When opening a session with missing files ( they are mixed internal and external drive and external not plugged in )
There is a popup for each file, It would save me some time if there is only one popup telling me that there are missing files and when I want to see them it gives me a list.

Right now I have to click many times ok button for every time I open a session like that.

DeafEyeJedi

Speaking of retesting exports... After these wonderful collaborations from all you fellow ML'ers in the past 24-48 hours, I've decided to disable the 'Bad Pixel Fix' and voila it all seems to be running better than ever.

Woke up this morning and it is in fact still rendering after overnight and all day yesterday. Seriously what gives?  :o



Just 10 more minutes to go and then I'll have to have a go with testing the latest EOSM gems that was awoken from the Great @Danne. Same also goes for Master @dfort's project on the eagerly EOSM2 that needs some porting love testings.

Quote from: Lars Steenhoff on February 02, 2019, 05:33:57 PM
...Right now I have to click many times ok button for every time I open a session like that.

Had this similar phenomenon happened to me. I just simply force to quit, while all is connected go ahead and reopen MLV App then load the Session file that you had saved for this project of yours which should do the trick.
5D3.113 | 5D3.123 | EOSM.203 | 7D.203 | 70D.112 | 100D.101 | EOSM2.* | 50D.109

masc

Quote from: Lars Steenhoff on February 02, 2019, 05:33:57 PM
When opening a session with missing files ( they are mixed internal and external drive and external not plugged in )
There is a popup for each file, It would save me some time if there is only one popup telling me that there are missing files and when I want to see them it gives me a list.

Right now I have to click many times ok button for every time I open a session like that.
How are you able to open such sessions? Do you open session with HDDs connected, then disconnect your HDDs to export the files on the HDD? This should be the only possibility, because MLVApp sorts out all MLVs which are not accessible when opening a session.
5D3.113 | EOSM.202

Lars Steenhoff

 



I just openend the last session without the drive attached.

yes it sorts it but it shows a pop up for every missing file, ideally I need only one popup at the end of the opening of the session

masc

Ah okay... so we don't talk about the export. We talk about the opening process. Right... you wrote that.
5D3.113 | EOSM.202

Lars Steenhoff

 :) true

It's not a major issue, I can just hold enter, but its seems a bit excessive all the popups

masc

I know what you mean, but it is hard to realize with current concept. Messagebox comes up when MLV open function does not find the file. But this function does not know how many files will be imported. The function which knows it, has no information about if it failed... :D Surely it is solvable...
Edit: I see a possiblity... just wait a bit...
5D3.113 | EOSM.202