v1.2 DUAL ISO problems are back..

[gac123]

so saturday i recorded the first show of my friends in dual iso seeing the v1.1 version fixed the dual iso problem, i was quite comfortable doing this

upon opeing mlv app i was pleasantly greeted with the "there's a new version" popup, so i decided to get the new and improved..

~8 hours later the 1 hour show was converted and there are problems every x frames... from a small blue line appearing at the top to (overexposed) highlights not being "un-dual-iso-ed"

see https://imgur.com/a/eXHQPtS

so i re-export with v1.1 (and 8 hours later), no such problems, but (doh!) i forget to export with clog, so olé i'm exporting again for another 8 hours :) (how is the multi threaded thing moving along? :) )

[masc4ii]

Could you upload a clip for testing such issues please?

For the multithreading topic: we got more problems with that than it accelerated anything so this is stopped. Dualiso algorithms have to be written new from scratch for that.

[gac123]

is there a way to cut a split mlv file? (total size is about 86GB)

maybe the issue is the same with my previous test clip (found here: https://mega.nz/#F!V1IiEKqC!K-YCjrQ7LOKwdXX5fv17xQ)

[gac123]

just tested it with my previous test clip, export is fine with v1.2

[masc4ii]

You could cut it with MLVApp. Use CutIn&CutOut and export as MLV.

[gac123]

done! i've compared my previous v1.2 export with the cut version on v1.2 and the results are not consistent

the errors are not seen in the preview, only in the export with prores 4444, duals iso on, and tonemapped alexa log c

edit: files also reside on that mega.nz folder edit2: not consistent meaning that the one export (same settings, same version app), might not have the same problems on the same frame, there are still problems overall, but not consistent frame-specific it seems

[gac123]

sorry, seems v1.1 does have the same issues (but not on the same frames as v1.2, seeing the cut export on v1.2 VS v1.2 also doesn't have the same exact problems consistently I was probably being naive)..

[bouncyball-git]

OK, will check again :smile:

[gac123]

yea, i just drag and dropped the v1.1 export into the timeline on a frame where the error was from the v1.2 export and it was perfect so i ASS-U-ME-D v1.1 didn't have any problems, based on the previous testing we did ':-)

[bouncyball-git]

I guess those inconsistencies may be only because of open mp. Gotta check this by turning off, one by one, every loop pragmas.

Edit: open mp really gives boost about 2x for dual iso so it would be sad to turn it completely off.

[gac123]

did some more testing... seems the errors in frame are gone when exporting dng uncompressed!

though there a new problem cropped up.. first I tried exporting dng lossless but I get the error "Could not save: ...dng How do you like to proceed?"

exporting dng uncompressed went without a hitch

[bouncyball-git]

Hm... it is really strange b/c I can't see any direct connection between lossless export and dual iso inconsistencies.

Lossless DNG has a quirck on some footage and I can not do anything about it (lj92 lib encoder issue). So your best bet always uncompressed.

However the issues you described have no relation to compression at all...

[gac123]

maybe it's handed off differently to the encoders VS cDNG ?

[bouncyball-git]

Nope. I wrote this so I'm sure it handed of the same way. Difference is: for lossless, raw feed is going to compressor and for uncompressed just to bitpacker. Inconsistencies' happening way before those procedures, during low level raw correction/processing.

btw do you use some other processing e.g. pattern noise or something?

[gac123]

oh no.. so after reexporting the whole thing again but this time in uncompressed cdng i've noticed here and there some highlights with "un-dual-iso-ed" artifacts so idd the problem is happening way before the hand off, it's just not so severe via cdng uncompressed

[bouncyball-git]

OK. I checked v1.1 vs v1.2 and now know what was my mistake (I changed a LOT since v1.1). It does not mean this will correct all of the issues v1.1 also had (e.g. some stripes in highlights), but there is some regression from v1.1 for some clips and it will be corrected.

[bouncyball-git]

@gac123: You can try the latest ver.

[masc4ii]

@bouncyball-git : you still know this? It is back... :( (2nd last master commit used)

[gac123]

@bouncyball-git sorry, github is very confusing, where do I find the latest? on the releases page it still only shows v1.2

[gac123]

ok, so i'm trying to build it myself (first time in my life) on win10pro64, installed qt, downloaded mlv-app-master.zip, extract, open mlvapp.pro in qt, add -j4 in command line arguments, extract qt\FFmpeg\ffmpegWin32.zip in same folder,

Build>Build All -> 453 issues Build>Build Project "MLVApp"-> 453 issues Run qmake -> no issues, not sure what it does lol

Guess I'll wait for someone to build it :) (no automated build? nightlies type stuff?)

[masc4ii]

You tried to build with MSVC2017. This does not work. You need MinGW version. (Microsoft does not understand many of the standard C things as you see)

[bouncyball-git]

@bouncyball-git : you still know this? It is back... :( (2nd last master commit used)

Give me that MLV please.

[masc4ii]

Give me that MLV please.

Okay, I'll upload this afternoon.

[gac123]

such a noob at this.. closed qt creator, i've downloaded and installed mingw (all basic components), deleted the pro.user file, restarted qt creator with mingw as default, reopend the mlvapp project, test run, build release/debug/profile, all end in errors, no idea what to do next, maybe the steps required to build this or any app from a clean machine requires maybe a few more than just -install Qt5 (minimum 5.6) -unpack ffmpegWin.zip in platform/qt/FFmpeg (and copy it later into build directory) -open platform/qt/MLVApp.pro in QtCreator -go to tab project, add command line argument -j4 (for quad core) -Build and Start

seemed so simple, i've been trying different stuff and researching online for hours now.. ugh

[masc4ii]

Install Qt MinGW version (and uninstall Qt MSVC). It seems you still run Qt MSVC version (watch your error output: if you still see something with MSVC2017, you still compile with MSVC). Installing standalone MinGW won't help you, or you configure your system manually (that is possible, but no fun). There are only the few steps to do, yes.

[masc4ii]

If you use Online installer, it should look like this (version don't cares if >5.6, but MinGW is important).

[gac123]

wish it were so easy... i first removed everything, reinstalled qt with only the option you show, open project, projects tab, build & run>desktop qt5.10.0 MinGW 32bit>Build(don't touch anything)>Run(only add the Command line arguments -j4) then i go from the top menu Build>Build Project "MLVApp" -> stops at 54 issues

ugh²?

[masc4ii]

These are warnings, no errors. (or is there any red line?) Press green play button and have fun.

[gac123]

Oh, Build and Run! :) works and already test exporting a piece of the footage

I do already notice that blue line at the top in the preview window

[gac123]

so.. bad news, the export (dng uncompressed) already starts with an almost black frame

but while doing other stuff my computer crashed on the podhd audio device driver (so annoying, but i need it for playing guitar), so i don't know which frame this was exactly

[bouncyball-git]

This is interesting. Looks like dng header corrupted.

[gac123]

here is the file

M28-0123_1_2018-10-28_0001_C0000_002409.zip (no dng allowed.. github)

edit: i'm an idiot, because i've used the resolve naming scheme, i do know which frame this was from d'oh

[masc4ii]

Here is the MLV with the wrong highlights after dual iso processing: https://www.dropbox.com/s/g3w0g93qilhqiyt/dualIso12Lossless.MLV?dl=0

[masc4ii]

If I remember right, in the past this was caused by some wrong limiting, if clip was recorded with less than 14bit... do you remember too?

[masc4ii]

@bouncyball-git : found it: https://www.magiclantern.fm/forum/index.php?topic=20025.msg203364#msg203364

and

https://github.com/ilia3101/MLV-App/commit/82b0264eda5c856c1081ecb37dea48fe5de0d14f

EDIT: could solve it by just dragging on the RAW white level slider... but is that as expected? Is there something wrong in the clip or in our app?

[bouncyball-git]

The code you refer to is changed almost entirely. OK will check this file.

[bouncyball-git]

For me, without any change, if white level set to 5600, car light becomes normal, flare above remains violet and when highlight reconstruction is switched on green color kicks in. Can you try this?

[bouncyball-git]

This is the latest scale algo (it can not go above 16200):

    int32_t scaled_white_level = 16200;
    double scale_ratio = (double)(scaled_white_level - raw_info->black_level) / (double)(raw_info->white_level - raw_info->black_level);
    raw_info->white_level = scaled_white_level;

#pragma omp parallel for
    for(uint32_t i = 0; i < pixel_count; ++i)
    {
        image_data[i] = (uint16_t)((double)((image_data[i] - raw_info->black_level) * scale_ratio + raw_info->black_level) + 0.5);
    }

And it even has minimal rounding error.

[masc4ii]

...and when highlight reconstruction is switched on green color kicks in. Can you try this?

Yes, that is a known problem with my highlight reconstruction algo. It is threaded, but it shouldn't be. So for areas without highlight problem a false color is selected. I could make it slower, than in would work better.

[bouncyball-git]

Well I was wrong and scaled vales could still reach upper values then white level. So I've added back my commented out code which finds lowest and greatest raw values and scales data/levels accordingly. After that we almost get the correct picture out of the box or it quite manageable with w/b level sliders. Please check.

[masc4ii]

Works wonderful for this clip!

[masc4ii]

I am not sure if it has something to do with this change, but last time I tested this clip it looked cleaner, now there is a lot of noise:

[bouncyball-git]

S..t :). That's why I commented this code out... gonna take a look again...

[bouncyball-git]

@masc4ii

Well I'm not sure about anything any more ;) but please try it again.

[bouncyball-git]

@gac123

Please try the latest win64 version.

[masc4ii]

Now the car clip and danne's clip are both working!

[gac123]

@bouncyball-git mostly issues with the preview; (exporting the thing now to see if i spot other things in the uncompressed dng export)

issues.zip

frames almost completely black in preview (frame 2379 dng uncompressed ok, see attached issues.zip)

purple line in preview (frame 4204 dng uncompressed ok,see attached issues.zip)

[gac123]

sorry.. black frame still exist M28-0123_002378.zip though the preview is ok

not consistent, if i scrub back and forth a few frames it might appear black as the output this happens multiple times accross the video.. i'll export the test i did as mlv without raw corrections (fast mlv) on the mega drive M28-0123-2378-4205.MLV https://mega.nz/#F!V1IiEKqC!K-YCjrQ7LOKwdXX5fv17xQ (it's uploading 1,5gb ETA~15min)

and more inconsistencies.. the cut "untouched" clip has problems on different frames, etc.. edit: file is uploaded..

[masc4ii]

and when highlight reconstruction is switched on green color kicks in.

Could you try now? Now one highest green is searched for the frame, not per thread. Should be better now...

[gac123]

like so? even more ff'ed up :)

[gac123]

ok, so i'm uploading the original mlv that came out of the camera on the same mega drive under the folder M28-0123, it might take an hour