MLV App 1.14 - All in one MLV Video Post Processing App [Windows, Mac and Linux]

[masc]

@cmh: ProRes444 with ffmpeg is always 10bit, and with AVFoundation 12bit.

@2blackbar: don't see a change. Your code snippet is in the code of raw2mlv. raw2mlv says it can't find the MLV file? How that? As far as I know it generates MLV files and doesn't search for them. And what is version 1.1? Without a file we can't test...

[2blackbar]

I see it im matrices too, ill compile and test it, but it just doesnt work in new reelase, i compiled modified raw2mlv myself for previous releases, pixel 2xl matrices had swapped values  so i edited those to make them work and they worked until now, so i have to use old version of mlvapp cause when i simply copy old raw2mlv then it just give me issues with cant find mlv the file.
But in meanwhjile heres the file from pxel 2XL, can you convert it and see the image in newst mlvapp 1.1 ?
https://drive.google.com/open?id=1ZyWEty62iFkiSTmKAozqRQQ_wZCpjP2O
Ok , cant compile, structure has changed
My compiled raw2mlv that worked with pixel2xl dngs , but copying it to new mlvapp 1.1 folder wont make it work somehow
https://drive.google.com/open?id=1nPcOSacgGXDEsXLJ4MYVWqFItqpWUgT5

---
Ok now i copied old raw2mlv to new mlvapp1.1 folder but with all dlls from old mlvapp aswell, and it worked.
So all is good here, but that new raw2mlv is not working with pixel2xl files tho.

[masc]

Conversion works without any problems. Only problem I see so far: there is indeed a problem with the camera matrix values. You have to switch to "Don't use camera matrix", then you see an image. But colors are bad without calibration.

Any raw2mlv should work with any MLVApp version allowing to transcode. Reason: the interface never changed.
Edit: the colors are changed...

[ilia3101]

So all is good here, but that new raw2mlv is not working with pixel2xl files tho.

In what way doesn't it work? Program doesn't run?

@masc the colour problem is that blue and red channel get swapped, because pixel Raw photos start at Blue bayer pixel, while all MLV cameras start with Red pixel. MLV App never took this in to consideration, and the MLV format is quite stupid at how it indicates which pixel the bayer pattern starts at. The field cfa_pattern is supposed to tell us that, but all I know is that a value of 0x02010100 means red (very cool number right?). Who knows what value would represent blue.

[masc]

@masc the colour problem is that blue and red channel get swapped, because pixel Raw photos start at Blue bayer pixel, while all MLV cameras start with Red pixel.

Okay, thanks. That's what I thought too.

[2blackbar]

It PARtially works with that new raw2mlv but only when i choose to not use cam matrix and colors are swapped ,  i swapped them back into right place when compiling for myself but this new version of raw2mlv i cant compile.
In that version that i compiled you dont have to do "not use cam matrix" , it works right away with "use camera matrix".And all i did to it was editing matrices file, swapping values for channels in pixel2xl profile.

[ilia3101]

As a temporary solution (until I sort out mlv format cfa_pattern) – I can make raw2mlv crop a few pixels on the left and right to make it always start at red (no more than 8 pixels of horizontal resolution will ever be lost). Would this be ok for you?

[2blackbar]

Its not really that important cause old raw2mlv works fine and only i have that issue, but if its gomna help with other profiles then maybe its worth the hassle.
Ah, i also forgot i customised MLVApp medium compression ratio for h.264 so it has better quality, id have to recompile myself again.

[cmh]

I used to raise cdng exposure to 1.26 in the raw tab to match prores in Resolve but I realized that MLVApp leave the BaselineExposure exif tag at 0 compared to various Ursa mini shots I got where it's always set to 3.09 (and 0.76 on a Digital Bolex D16 according to the internet).
A quick fix that overwrites the original files with a value of 1.26, it's a pretty quick operation:

Code: [Select]

exiftool -BaselineExposure=1.26 -overwrite_original *.dng I tried few samples provided on the forum (7d 14 bits and 5d III 10 bits) and various gamut/color space: it's still 1.26, it seems consistent.

[masc]

Thanks for the post. When exporting cdng, MLVApp applies only RAW corrections and stretch factors - but nothing else. If you use a Mac, you could write a quick script and run it via post export script feature automatically. I don't know a way to write this value directly to the dng file without another tool. Maybe someone else knows a way... ?!

[cmh]

MLVApp do create tags (related to black levels, camera and lens info for exemple) in dng.c and I can see some reference to BaselineExposure in dng_tag_codes.h.
I'm not qualified to say wether it's feasible in MLVApp or not but I think there's good hope.

[Danne]

What is the tag set to when exporting a cr2 into dng with adobe dng converter?
It's read by acr but is it read in resolve?

[masc]

dng.c line 638 should be the line to change, if you mean BaselineExposure is the correct value.

Code: [Select]

{tcBaselineExposure,            ttSRational,RATIONAL_ENTRY(basline_exposure, header, &data_offset, 2)},But what is the data type rational?! Our exposure value is of type "double".

Code: [Select]

#define RATIONAL_ENTRY(a,b,c,d) (d/2), add_array(a, b, c, d)

[cmh]

It's bouncyball code, maybe I should pm him later to see if he's around.

I see some other stuff line 579:

Code: [Select]

        /* Baseline exposure stuff */
        int32_t basline_exposure[2] = {mlv_data->RAWI.raw_info.exposure_bias[0],mlv_data->RAWI.raw_info.exposure_bias[1]};
        if(basline_exposure[1] == 0)
        {
            basline_exposure[0] = 0;
            basline_exposure[1] = 1;
        }

I need to reinstall qt and a dev environnement, that will take some time with my subpar internet.

[Danne]

It´s a simple exposure correction tag. Just change to the hardcoded one and compile. However before releasing any official changes make sure 1.26 is the correct number. No use adding this tag if it´s not properly checked. I think converting a CR2 to dng in adobe dng converter would reveal this. Anybody checked?

[cmh]

Not yet but you're right the 1.26 value is eyeballed by comparing prores and dng files on the vectorscope.

[cmh]

ACR converted files have a value of 0.25 (various iso tested).
edit: let me check what happened in Resolve...

Both the converted CR2 and the cdng needs a raise of exposure of 1.26 (approximately) to match untouched prores (rec709 tested for consistancy but whatever, it's the same for all of them).

[Danne]

I used to raise cdng exposure to 1.26 in the raw tab to match prores in Resolve but I realized that MLVApp leave the BaselineExposure exif tag at 0 compared to various Ursa mini shots I got where it's always set to 3.09 (and 0.76 on a Digital Bolex D16 according to the internet).
A quick fix that overwrites the original files with a value of 1.26, it's a pretty quick operation:

Code: [Select]

exiftool -BaselineExposure=1.26 -overwrite_original *.dng I tried few samples provided on the forum (7d 14 bits and 5d III 10 bits) and various gamut/color space: it's still 1.26, it seems consistent.

Are you matching prores from ffmpeg produced content here in Mlv App? Isn´t it a flaw in the prores setting then? It could be a number of things from rec709 curve, gamma etc. Think it will be difficult to achieve perfect raw/prores exposure etc out of the box.

[cmh]

Most definitly but it's not gamma and color space related, I've tested alexa cineon linear bmd they all need that exposure fix. Let me check other codecs real quick (but I think we would have noticed it before if dnxhr or h264 lowered the exposure by more than a stop).

[Danne]

How will a comparison between a cdng file produced from a MLV recording against a CR2 - dng produced in adobe dng converter look? Tested with exact same settings and on the same test scene.

[cmh]

I did those tests, I got prores and h264 files (both rec709 profiles but I already checked other profiles, +1.26 exposure is still needed).

• MLVApp cdng have a BaselineExposure 0 tag and need +1.26 exposure to match them.
• Adobe dng Converter files have a BaselineExposure 0.25 tag and require +1 ish exposure to match them.
• CR2 files doesn't have any BaselineExposure tag ofc and, imported directly into Resolve they need +2.26 exposure.

While not perfect (due to framing missmatch, color temp shift and probably debayering differences) 1.26 seems consistent for MLVApp generated cdng files.
edit: let me do a screenshot real quick. Well a video then it will be easier.

Code: [Select]

https://youtu.be/YZAFH2MgE_k

[masc]

I would not hardcode 1.26 to MLVApp. I would try to get the exposure slider value into the cdng. Then you can create your own default receipt with any value you like, import your MLVs and export them straight away with your preferred exposure value (e.g. 1.26) and get the right exposure in Resolve.

Danne is right: there are so many algorithms behind many parameters. And just because they are called the same and the numbers look similar the realization might (and will) be very very different. It can be anything, not just exposure. Who tells us e.g. Adobe or Resolve calculates profiles the same way?

[Danne]

If the adobe dng needs + 1 to match prores i'd say 0.26 is what to be added to to mlv cdng. Any other matching should be done manually.
Take this with a grain of salt. Still haven't seen any visual comparisons.

[Kharak]

I too recommend that you don't hardcode any exposure change to the DNG. But optional or a slider, that would be great and even other metadata.

[cmh]

It could be two explicit tickboxes at export or something, like "BaselineExposure 0.25" with an helper dialogue "match adobe dng converter exposure for canon cameras" and "add BaselineExposure + 1"  with the dialogue saying "match encoders exposure". Then I don't request anything just wanted to point out the discrepancies between various dng files in resolve.

The exact value has to be determined, 1.26 in resolve seems to match but I haven't checked other NLEs (baselight, vegas, adobe's products, apple's stuff, etc).

Edit:so far the tag matches various canon cameras but ofc it will be different depending of brands and models.