Author Topic: MLV App 1.12 - All in one MLV Video Post Processing App [Windows, Mac and Linux]  (Read 604284 times)

garry23

  • Contributor
  • Hero Member
  • *****
  • Posts: 2208
I’ll stop using  ;) :) in the future.

Over and out.

a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 12562
Silent pictures contain the complete image buffer delivered by Canon firmware (including black bars), while MLV frames contain a cropped section, not including black bars. Last time I've checked, mlv_dump was handling both types of files correctly (edit: tested two samples linked earlier, they both work fine with mlv_dump).

The tricky part is that raw_info structure is copied directly from current LiveView configuration - that is, it includes the active area offsets for a complete LiveView frame. As the MLV video frame (from mlv_rec/mlv_lite) is cropped, its active area offsets should be updated, and - since the black bars are not normally included in the recorded image - those offsets would be normally 0.

In mlv_dump, this is currently handled as a special case: if the frame size from the RAWI header (xRes x yRes) is smaller than the complete raw frame size (raw_info.width x height), that must be a cropped section of the entire frame. Since the black bars are not included in the recorded image, active_area is assumed to cover the entire recorded frame (that is, active_area offsets must be rewritten - "zeroed out" - by the MLV converter). If the frame size from RAWI matches the one from raw_info, that means the recorded image contains the complete raw frame, including black bars, so the active area declared in raw_info is considered valid (and should be used for conversion).

The offset fields from RAWC are supposed to show where the complete LiveView frame (possibly binned/cropped by crop_rec, x5 zoom, Canon's 1080p / 720p / crop mode etc) is placed, relative to a full-res image (FRSP or CR2), but these are not implemented yet.

The position of the cropped image (saved by mlv_rec/mlv_lite), relative to the complete LiveView frame, is given by VIDF cropPosX/Y (restrictions: we can only crop multiples of 8 pixels horizontally - because of 14-bit packing - and multiples of 2 pixels vertically, in order to keep the same Bayer layout). The "pan" offsets (panPosX/Y) were meant for smooth digital panning within a complete LiveView frame frame (not implemented yet).

In any case, I don't see a good reason for changing the silent picture code - it works as expected, if you ask me. Changing the active_area offsets should have been done in mlv_rec/mlv_lite from the very beginning, rather than requiring MLV converters to rewrite these offsets - but now it's probably too late to make this change.

In other words, the active area metadata in a silent picture MLV is correct, while the one from a mlv_rec/lite MLV is invalid and must be "zeroed out" (recomputed from scratch) by the MLV converter. I don't see a good way out of this, other than using the above workaround (special case) in MLV converters.

davvore33

  • New to the forum
  • *
  • Posts: 3
Hi everybody, got a news, I've created the package build for Archlinux for MLV.app, you can find it here https://aur.archlinux.org/packages/mlv.app/

if you want you can mention it on your website or something

togg

  • Senior
  • ****
  • Posts: 423
@togg:
1) how did you get this picture? What exactly does it show?
2) no need for this
--> you define the bad pixel map for any clip. This map is saved as .bpm in the MLVApp folder. As soon as you activate bad pixel map fix for any other clip using the same camera raw stream settings, the same .bpm will be used again. So ideally, you create this map once for your setting and use it forever for all future clips (in the same setting).

1) it shows a set of hot pixel that I have selected in another picture on the same project that are displayed misaligned in other clips, but still work as intended. It's hard to explain ahah
.
2) mmm I'm not sure this is even working on my side. I don't have a .bpm file on the MLVApp folder and I'm almost sure than when I opened another project there was no past memory.

masc

  • Contributor
  • Hero Member
  • *****
  • Posts: 1801
@togg: the .bpm is auto generated as soon as you start telling MLVApp where the pixels are.


@davvore33: great news! Thank you! Yes, we'll add a link to the repo.
5D3.113 | EOSM.202

2blackbar

  • Senior
  • ****
  • Posts: 470
I posted it before and recently i posted it in EOS M topic but i think it more belongs here. i get quite big difference in colours when importing 5D2 footage into mlvapp VS canon M footage, here are the same scenarios filmed with 5D2 and M.
DNG FRAMES :
Heres 5D2 frame:
https://drive.google.com/file/d/1RKpYa74qClOBkwEOspcC9jj3HnrG997T/view?usp=sharing
M frame:
https://drive.google.com/file/d/1OiF8FNmcuHAJs1kqnnuhw2NRrnaECH_5/view?usp=sharing

MLVAPP:
5D2:

M:

ADOBE LIGHTROOM ( looks very similar on both so theres no issue here)
5D2:

M:


So there is something going on when debayering in mlvapp and it affects not only tonemapped conversion but logs too, im not sure what it is but its there i can see that 5D2 has weak reds, they look orangey, look at the reds above yellow paint VS M image from mlvapp which looks correct.Those paints above yellow are reddish not orangey like on 5D2 and no white balance can fix this, and if it does then everything else looks off.

masc

  • Contributor
  • Hero Member
  • *****
  • Posts: 1801
I think I have a déjà-vu. Didn't we already talk about exactly these images a while ago? If I remember right, the conclusion was: in MLVApp we use camera matrix values from the RAW metadata and Adobe seems to use own matrix values. But I am not sure if I remember right... should be "some" pages in this thread ago.
5D3.113 | EOSM.202

2blackbar

  • Senior
  • ****
  • Posts: 470
It was but Id like im using tonemapped  and camera matrix most of the time, colors dont look that good without it. But i tried it , changing different methods like srgb and not using camera matrix and it really doesnt fix the colours whatever i do in mlvapp, i have to use HSL curves to bring back reds and squash the orange.
Theres just no red in that 5D2 image from mlvapp, its like orange and its strange.IT affects the sking and its the reason i dont film with 5D2 that much.
I brought it up cause maybe there is something thats causing this difference especially if in lightrooom both look the same.

togg

  • Senior
  • ****
  • Posts: 423
@togg: the .bpm is auto generated as soon as you start telling MLVApp where the pixels are.



OK I see it now! I mean I see it working. Even if I am unsure where the map is located, but all good! Great feature.

masc

  • Contributor
  • Hero Member
  • *****
  • Posts: 1801
@2blackbar: if our suggestion is right, you just need to find the correct matrix. We use the matrix coming from the camera. No problem to exchange it in the source code.

@togg: The maps can be found in the same path where MLVApp executable is located.
5D3.113 | EOSM.202

ilia3101

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 936
@2blackbar the 5D2 has weaker red saturation compared to most cameras when using a 3x3 matrix, this is an issue in all raw converters that use these same matrices by Adobe. However Adobe's own profiles include some hue-based adjustments on top of the matrix, which we don't use, but that's how they correct the reds I believe.

2blackbar

  • Senior
  • ****
  • Posts: 470
Ah i knew somethng was off, do you know where i can look up the hue adjustments to apply in mpvapp?
are there more cams affected by this besides 5d2?

ilia3101

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 936
I don't think you can directly translate the hue adjustments in Adobe profiles to MLV App's hue adjustments, as Adobe does hue adjustment in some way which we don't replicate exactly. What you do manually is probably no worse than what Adobe has in their profile. This stuff is just a bodge by Adobe to try and improve on 3x3 matrices imo.

bouncyball

  • Contributor
  • Hero Member
  • *****
  • Posts: 819
Hi everybody, got a news, I've created the package build for Archlinux for MLV.app, you can find it here https://aur.archlinux.org/packages/mlv.app/
Yay!
Finally MLVApp is in AUR.
Thank you.

bouncyball

  • Contributor
  • Hero Member
  • *****
  • Posts: 819
Care to look into it Bouncyball  8)? silent.c a good start I guess?
Haha! I changed my mind :P. I'll better stick with fixing mlvapp.

@a1ex: Thank you for comprehensive information (as always).

Danne

  • Developer
  • Hero Member
  • *****
  • Posts: 7129
Cool. It would be a great addition to have it working in mlvapp :).

bouncyball

  • Contributor
  • Hero Member
  • *****
  • Posts: 819
@theBilalFakhouri

I've tested 700D silent mlv shared by you and the story is:

MLVApp exports DNGs without black areas exactly as mlv_dump does, e.g. correctly.
It's just the mlvapp also happens to have :P image preview/export feature and uses whole buffer for this as it was expected.

Stay tuned... (never loaded silent pic mlv until now)

bouncyball

  • Contributor
  • Hero Member
  • *****
  • Posts: 819
Well, here is the next part of the story:

The image buffer of silent pics includes OB but Image buffer recorded by other mlv recorders does not, hence, as a1ex mentioned, active area metadata is wrong. When exporting DNGs, this situation handled by rewriting active area metadata by software (mlv_dump, mlvapp). But, the truth is that whole image buffer including OB area goes into DNGs (hence nothing is done to image buffer itself). Instead the DNG header active area appropriate fields filled with correct values. When DNG is opened in some processing software it reads only active area into buffer.

Mlvapp operates with whole image buffer from any mlv and uses it during debayer. So to correct this "misbehaving" it needs to read only active area which is not implemented. Do you really need this feature to be implemented in raw part guys? ;) or maybe crop OB area during postprocessing?

BR
BB

Danne

  • Developer
  • Hero Member
  • *****
  • Posts: 7129
Yes, needed ;). Silent module is really cool, deserves the fix imo.
Will I use it personally. Maybe not a lot right now but who knows about the future.

masc

  • Contributor
  • Hero Member
  • *****
  • Posts: 1801
@bouncyball: 100% agree all of what you wrote. Correcting that means changing many many functions, in all parts of MLVApp.
Do you really need this feature to be implemented in raw part guys? ;) or maybe crop OB area during postprocessing?
This is what I also thought about... we're talking about 3 clicks in a NLE vs. weeks of hard work correcting that few black pixels... surely a nice to have for the future.
5D3.113 | EOSM.202

bouncyball

  • Contributor
  • Hero Member
  • *****
  • Posts: 819
Yes, needed ;)
Haha! Well, we'll think about it :)

bouncyball

  • Contributor
  • Hero Member
  • *****
  • Posts: 819
@masc

Yes, it's really pointless to do this in the raw part of the mlvapp. Sadly we do not have crop functionality implemented in post processing either. FFMPEG crop option could be implemented during export but this would be just half of the job done.

Danne

  • Developer
  • Hero Member
  • *****
  • Posts: 7129
I think silent module is something to incorporate in Mlv app. That is, you find the the time and interest B. What's a week in code world really ;).

Why pointless @masc @bouncyball. One big reason I didn't continued using silent module was this uncropped output in mlv so I went and worked some lua scripts using movie mode and crop rec instead.


bouncyball

  • Contributor
  • Hero Member
  • *****
  • Posts: 819
Why pointless
Uh, I meant in the RAW processing part of MLV app (e.g. reading rawdata). But in RGB domain during image processing it makes sense.

Danne

  • Developer
  • Hero Member
  • *****
  • Posts: 7129
Yes, seems really hard through raw pip  8).