Messages

Nice!
Question. Aborting export stops processing and erases ongoing file. I would prefer if the file was stopped and then kept for previewing purposes.
I sidestep working is to force quit Mlv App instead of aborting which seems to send a kill ffmpeg signal and the file will be stopped but viewable.

Can be changed easily. Maybe I create a checkbox in menu for that. For now, see MainWindow.cpp line 2349 in current revision - comment it out and you're done.

Edit: I'll just deactivate this and then all 4 different export pipes do the same.

This week I found a bug related to focus pixel fix feature and got it fixed now.
-> if "Create Mapp Files" was enabled or/and a Mapp file was already created, "fix focus pixels" did not work always.
-> Workaround: disable "Create Mapp Files" and delete Mapp files, load MLV again
-> If you are able to compile MLVApp, using Mapp files + fix focus pixels works now. Or just wait for next offical release.

I don't think the card is the problem. KB 64GB 1066x is very fast, I have the same and it works fine. You wrote you use a external monitor. This should be the problem. Have you tested without monitor? If a file is corrupted, you won't get it fixed in most cases.

what I did : import in MLV app, change to "don't use camera matrix" and choose the "film" preset, export in CinemaDNG Uncompressed, import in AE, color grading with Camera Raw, dynamic link with Pr and export in 4k so youtube doesn't destroy it ^^$

That makes no sense: if you export in MLVApp to dng, all settings (except RAW corrections) will get lost, because dng is a RAW format. Camera Matrix and Profile Film will only be visible in a non-RAW format like ProRes, H264, ...

You can access ML menu without touchscreen, just with the buttons. Use trash button and play button. So no need to pop off the magnifier.

...if working all cases.

That is the question to find out now

Ok, is this a boost to already created pixel maps? Or could it be used on any file containing focus pixels? Will check some more tonight.

This is just another (third) interpolation method to use the pixel maps. Especially in tree's it looks much better...
Methods in MLVApp: 1,2,3. 3 is the new one.

I found a quick temp fix for the interpolation method from @Rewind. See here. Whyever this helps, because after line 185 those values should already be 0..1. Maybe someone understand this and has a better idea, how to fix. But all artifacts are gone with this for my test clips. Would be cool, if someone else could compile and test. The result is worth it! Looks indeed better than the other two methods.

Thank you @Rewind. I commited the code to MLVApp repos and added 2 more buttons (interpolation method "3") for bad and focus pixels. It seems to work fine for 14bit footage. For some 10bit clips it looks wrong. No idea why.

Edit: okay... maybe has nothing to do with bitdepth. Does not work with most of my EOS M clips. Some testclips from other cams work. Strange.

[1. When shooting 14 bit raw in non-crop mode, focus pixels are located only in center part of the image.]

In order to evaluate how focus dots removal works in popular raw processors (MLVFS, MLV App, MLV Producer) I'm using this improvised test chart:


14 bit raw video (1736 x 976) shot on Canon 650D with mlv_lite module in non-crop 1080p mode.
PDR (Pink Dot Remover tool) with updated dot data and altered interpolation algorithm used as a reference guide.

A couple of observations and suggestons:

1. When shooting 14 bit raw in non-crop mode, focus pixels are located only in center part of the image.
No matter what AF points pattern used, what AF method selected in Canon menu or AF disabled, all the focus pixels are concentrated in central 290 pixels height area:


Therefore, assuming focus pixels all over the frame (like actual fpm tables does) we introduce color artifacts in areas which were clean originally. This behavior should be avoided:


Suggestion: let's update fpm tables the way they don't affect the top and bottm parts of the image.
Focus pixels should be treated only in 290 pix height central area in order not to ruin the originally clean image.
Above is applicable to 650D and may vary by camera models. If this is the case, may be we should detect camera model and limit the FP affected area accordingly, or even let user decide where to remove those pixels by dragging some selection area.

2. Interpolation algorithm works better if takes into account only horizontal and vertical neighbour pixels, avoiding diagonals.
Let's call it "cross" method for now. I've already mentioned this back in 2013, and this idea may sound strange at first, but here are some fresh examples. Judge for yourself:



While this is obviously exaggerated extreme test (although shooting let's say a book page in movies is not so rare), almost all real-world scenarios became a bit cleaner and seems more calm, when this "cross" method used.
So my second suggestion is: Let's introduce this interpolation method as an option in UI, so the user may decide which one is better in a given situation.
This applies to MLVFS and MLV App. MLV Producer uses its own method which is better and very close to what PDR does (is it the same?)

DNG's used for examples:
Original
Treated by MLV App / MLVFS
Treated by PDR

Modified interpolation algorithm explanation and code (java)

I tried out your code in MLVApp now, but I can't get it to work. When thinking about it... does this work on RAW data? I guess not... This is for debayered image data, right?


I converted your code to this C function, which is executed for each pixel in the map:

Code Select Expand

static inline void interpolate_rewind(uint16_t * image_data, int x, int y, int w, int h)
{
    if ((x < 3) || (x > (w - 4)) || (y < 3) || (y > (h - 4))) return;

    // 1. Retrieve vectors from 7x7 kernel
                // d[0] — vertical vector
                // d[1] — horizontal vector
                // index reference:
                //        paper     -3 -2 -1 0 +1 +2 +3
                //        actual     0  1  2    3  4  5
    int d[2][6] = {
        {image_data[x+((y-3)*w)], image_data[x+((y-2)*w)], image_data[x+((y-1)*w)], image_data[x+((y+1)*w)], image_data[x+((y+2)*w)], image_data[x+((y+3)*w)]},
        {image_data[x-3+(y*w)],   image_data[x-2+(y*w)],   image_data[x-1+(y*w)],   image_data[x+1+(y*w)],   image_data[x+2+(y*w)],   image_data[x+3+(y*w)]}
                    };

    // 2,3 — We don't need these stepse because of diagonal af dots arrangement

    // 4. Normalizing vectors
    // vertical norm.
    d[0][2] = d[0][1]+((d[0][2]-d[0][0])/2);
    d[0][3] = d[0][4]+((d[0][3]-d[0][5])/2);
    // horizontal norm.
    d[1][2] = d[1][1]+((d[1][2]-d[1][0])/2);
    d[1][3] = d[1][4]+((d[1][3]-d[1][5])/2);

    // 5. Deltas and Weights
    int dVert = ABS(d[0][2]-d[0][3]);
    int dHoriz = ABS(d[1][2]-d[1][3]);
    int Delta = dVert + dHoriz;

    float wVert = 1-((float) dVert / Delta);
    float wHoriz = 1-((float) dHoriz / Delta);

    // 6. Calculating new pixel value
    float newVal = wVert*((d[0][2]+d[0][3])/2) + wHoriz*((d[1][2]+d[1][3])/2);
    if( newVal > 65535.0f ) newVal = 65535.0f;
    if( newVal < 0.0f ) newVal = 0.0f;
    image_data[x+(y*w)] = (uint16_t)newVal;
}

Edit...: I see this code works nicely on 14bit RAW data... those dots happen for 10bit. Someone has a guess why?

MLVApp has two different methods, select between them with the interpolation method buttons (1,2). Maybe @bouncyball can explain what mode uses what algorithm... around and median?! No exact idea

In theory 1x3 mode must not have a crop factor (okay, very little crop: 1664 columns from 1736). We just crop it slightly to not get too much corrupted frames and to be able to record longer clips.

Nice to see some eosm movie published. I would be interested to see some anamorphic shots of this kind. Maybe sharpen in post. I suspect aliasing will be much less noticing and also no need for upressing footage in post.

I did that a while ago... I think you know the clip already... but if someone else is interested. Recorded in 1x3 2.35:1 anamorphic mode, slightly sharpenend !after! rescaling (to not rescaling/increasing sharpening artifacts).

... I don't mind if it goes a little blurry or pipxelated. ...

It will get very blurry and ugly.

it is very importand to see the waveform/rgb parade etc while color grading.i find the waveform window very small. is it possible to increase the size of it or give and option for floating or something like that

@andy kh I agree it would be nice if the waveform expanded with the sidebar, but I think masc didn't like it getting pixelated (I think I remember this from some discussion in 2017 ).

Correct, Ilia. In general: no problem to make waveform / rgb parade larger... if +5sec per image is fast enough... until now I did not like this at all, because nobody could work with this - that is why this does not exist Or we could just stretch it - but then you could count pixels and won't have more information.

Whyever this is needed. Through the include chain this should be included more than once already - and unix hasn't this problem. But commited it now, so hopefully this makes no more problems for everybody on windows. Thank you for trying out.

On Windows 10. QT 5.9.1. QTCreator 4.7.0. Using MinGW to compile.
Errors:
...

Sounds like the compiler on windows is too stupid to use the given includes.

Code Select Expand

#include "stdlib.h" or

Code Select Expand

#include "stdint.h"  is missing in the file. No exact idea here and can't try.

Known issue for cameras other than  for 5d mark III.

Huuu?! This has nothing to do with 5D3. Can and will happen with any camera, also with 5D3.

Sounds like you are not in video mode, but in photo mode. But more info would be nice...

@masc Are you able to compile master? I think this commit broke it:
https://github.com/ilia3101/MLV-App/commit/88e803d1033640953edd284de4bccdae88645c63

frame_caching.o: In function `get_mlv_raw_frame_debayered'
undefined reference to `wb_convert'
undefined reference to `CA_correct_RT'
undefined reference to `wb_undo
error: ld returned 1 exit status

Yes, I can compile here on OSX. What OS do you use? (If it is not OSX I am sorry... I am in holiday and no Win/Linux in the near.)

in mlvApp when i resize lets say i shoot in 1920 by 818 which is 2.35:1 and export in dnxHD format in 1080p the the height is stretch which is not the same case with resolve or premiere pro
so upcaling or resizing not possible in mlvapp

dnxhd is extremely limited in options. If I remember right 2.35:1 was not possible at all. Maybe better use another codec.

So, there is no lossless RAW recording on 5DII with any modules for ML ? Theres 14 bit and 10-12 experimental modules uncompressed RAW, or am i missing something ?

Yes and yes.

[1120x1900]

I did following(ananorphic rewired mode). If selecting 16:9 10 bit you´ll get 1120x1900 but if you select 12bit it will instead do 1164x1800. Hit menu button if changing bitdepth. Test if 12bit is corruption free with 25fps.

Really? But 1164x1800 is 17.5x9 ... is that correct?

Hm... maybe it is easier to insert a openfx interface - then one could load such plugins. But I have no idea how openfx works
The good thing on CA_correct_RT (from RawTherapee) is, it is just one single C function with some easy parameters (after my modification) and no dependencies at all.

I wouldn't call 5MB huge in this day and age where a web browser is three times bigger than an entire operating system.

The MB don't care at all. Lines of code, dependencies and coding interface cares... and this is more than huge from what I saw. (At least I didn't got how to handle it.)

@Kharak: no problem to go back: on firefox mobile, click the menu dots, then click "Desktop Page" (or similar). Then it looks like before. In chrome app there should be something similar too...