Messages

Thank you. Very interesting. VirtualDub is working for you in Wine? I get very big problems... when processing it hangs always after 3th..5th frame - for hours with 0% CPU. No idea why. What plugin do you use to export prores from VDub?

Our little christmas present for you all: v1.4 is out.
+ Added gradation curves for Y, R, G & B
+ Added diagram elements for Hue vs. Hue, Hue vs. Saturation and Hue vs. Luminance
+ MLV uncompress export
+ Select between different rescaling algorithms on ffmpeg export
+ Added LUT strength slider
+ Some bug fixes and some minor changes
https://github.com/ilia3101/MLV-App/releases/tag/QTv1.4

Great! Can you tell something more about your workflow? It looks so good on youtube - my videos have more compression artifacts than detail on youtube. How did you upscale, export, ...? Did you use an editor for cutting (or at least for the texts)? Did you denoise somehow?

Wow masc. That was something else. Is there anything you can´t do dude  ?

LOL... thanks... but yes, there is enough I can't do... hehe. For example I don't get the histogram bigger without loosing one quarter of playback speed

Whenever I'm doing any I/O operations, the destination always defaults to the same incorrect location.  It's a real problem for me because I'm constantly saving and loading receipts (while I await the much-needed receipt slots!), and it totally breaks down the workflow to have to navigate to someplace other than the CF card to do this.

Can mlvapp remember where you saved last, and default to that until you choose another location?  It would make things a lot smoother, especially when using keyboard shortcuts.

Please describe exactly what you are doing! I save sooo many many destinations for soooo many functions in MLVApp since many versions... so this sounds really strange and I don't know exactly what you mean. I never have to navigate in any function I tested, if using the same folder again. So I think you are a bug victim

I have to check but does the minimize state get restored on restart?

Yes it does.

I mean the ability to select a state that will be restored at restart. Like preferences but for the raw corrections. Without passing from a saved project.

Preferences for parameters can be exported and imported as receipt.

@Lars: you found the ability to minimize the edit groups? Why completely hiding them? The current order is mostly identical to the processing pipeline, so why changing the UI? It would not change the processing, and you would not get what would be expected when changing the order.

@togg: sry, I don't understand. Default start? Standard process? Could you please explain more precisely?

So, having the edit area in a floating window on another screen is just perfect for me!

I made the edit area floatable and moveable now. But I have no idea, what bugs this brings. So please - who is able to compile - test it carefully.

Having a fullscreen viewer is great for critical grading.

Fullscreen is not possible - unfortunately Qt is very buggy here. I implemented it a year ago using the Qt fullscreen functions. But it is hidden since that because it works really bad. It was bug free on OSX single monitor systems. On some other systems all input devices get blocked in fullscreen and you just can shut up the app... if you have more than one monitor, it was even more strange. That's why also another extra window would not be fullscreen. The closest you can get is pressing "A S E" and maximizing the app.
And here again: if there is someone who can help me with such Qt problems: please contact me!

PPS: is there a way to define the output filenames when doing an bunch of clips, such as naming each clip in the editor?  I don't see any obvious way to do it...

Nope. Renaming is only possible if you export one clip.

PS: I'm happier with mlvapp than resolve for great results and much better control system!

thank you. We do our very best...

Yes, for me it goes from 5 fps to 7-8.
I couldn't find the option to decompress MLV, is it already in?

For this you'll have to compile yourself, or wait for next release...

@70MM13: there are many many dependencies between all panels in the frame... relatively easy would be adding a 2nd window, which shows the viewer a 2nd time. But this again costs some fps...

it is the option that you have in the Finder info for the software and yes it is working, I've tested it only with small files but I'm almost sure of it.

GREAT! Never saw this one! That indeed works!

Still strange that for the highlight recovery button to kick in you have to lower the exposure and in some way affect the whole image.

Highlight reconstruction in MLVApp does only reconstruct highlights and does not affect some brightness as in Resolve. That means, areas where the green channel was clipped (99% of damaged highlights) the green channel is recovered from red and blue. Clipped green with lowered exposure leads to pink highlights.
OFF:


ON:

some more informations can be seen on resolve: https://i.imgur.com/jhUgocW.png

Hm... slightly more contrast, but wrong colors (cyan to magenta in the upper right).

Damn, that's why they put a open in lower resolution in the first place, I think I'll use it. There's not that much text on screen.

Where do you find this? Is the App somehow opened in LowRes then? If it is just the simulated resolution in OSX: this doesn't make it any better, because rendered area (in cm) on screen is more or less the same.

@togg: I played with your MLVs and get this out of it:


See the sliders. I had to adjust the RAW white level to get a correct sky. Indeed, highlight processing is very complicated. It just works, if the white level is set correctly. The value read out from the MLV might be wrong, what leads to strange colors in overexposed areas.

For framerate: the more (screen)pixels the software has to calculate, the longer it needs. So if the window is small, it will be faster. Retina or other highres screens are very bad, because more pixels (4x @ retina) have to be calculated. OSX does this in background without the need of further code, so we can't do much here.
Maybe the screen is the difference between your numbers and mine: my screens are mostly around FHD, the old MBP has 1280x800.
Another speed brake is "lossless". Not using it can bring up to 2x more speed, because decoding is not needed.

The same for MLVapp I would love to see and gpu accellerated version...

You shouldn't wait for that. Start implementing it and help us. Until now nobody was willing to do that for us and we don't know writing GPU code. It is very different... and has to be learned.

... or a new version that uses caching for smooth playback on the second loop.

We'll see what we can do here. But it has not highest priority. Implementing this was very painful in the past (never worked fine on Windows) and it will become ~100% more complex to how it was before in terms of cache organization. Current status can be found on github issue page.

[Edit]

Thanks for your report, togg.
1) Maybe bouncyball can tell something about that...

2) MAPPs are batch created when exporting files (e.g. if you export proxy for all files first) or for single file (non batch) if you just open it.

3) MLVApp don't uses any GPU. That is why it works on nearly every computer, instead of most other software. If you use it on a non-retina display it should be ~1.5x faster. If you need faster preview, export the clip or use MlRawViewer. Compairing to MlRawViewer is not really fair, because of the lack of many many functions. Resolve on my systems has the same speed (more or less) and heats the GPU additionally.
For FHD on a MBP 2013 i5 2.4GHz I get 13fps, on a MBP 2010 Core2Duo 2.4GHz 7fps, on a iMac 2011 i5 21.5" 23fps.

4) ?! = 3)?

5)

Multhithread kicking in when not needed.

I don't think so. Multithreading is no fun, so we implemented it only where it is needed.

And even so raw correction where possible at the same speed even before multithread.

And that's also not true. We benchmarked it often enough I think.
Complete processing pipeline, most debayers and a part of RAW corrections use multithreading, as well as ffmpeg.

6) Really? For what reason is that useful? Use the fps label from playback. The pipeline is identical, only the output is viewer vs. ffmpeg/AVFoundation.

7) I did not find any possiblity to realize that. We can chose between:
   a) Window is not at OS foreground, but will be lost after first click somewhere in your OS
   b) What we have
   Maybe someone knows programming with Qt and can help...
Edit: yay... I finally found another solution after searching for it the 1000th time.

Highlights: Have you tried: exposure -2, lighten +50, highlight recovery on? For me, this mostly looks better than Resolve.

Some new stuff to test for you: I tried to implement something similar but more flexible like we have in Lightroom - these HSL elements. In LR you have a couple of sliders, in MLVApp we have free diagrams now to paint curves in. I am not sure if my processing algorithm is correct (it just looks (mostly) similar to what LR does). For Hue vs. Luminance LR does somehow blur the edited areas - I don't blur it in MLVApp.

For now you'll have to compile MLVApp with these features on your own. If we don't find too awful bugs, we could make a release with that soon. Noisy or moiree areas look not so well... I have no idea how to improve that.

Here are coming the pictures as MLVApp PNG export, 1:1 graded as in the youtube link (I just added full sharpening to get more detail in the photos, even if it looks ugly...):




And here the dngs:
https://www.dropbox.com/s/gai6b4danvwuegx/seychelles_dng.zip?dl=0
But I don't see an overexposed area in those pictures - maybe some single pixels are (zebra function told).

Thanks @all.
I know what you mean: getting the contrasts recorded is a hard fight on the seychelles. The white pouder sand is extremely bright and often flat, shadows are extremely dark. I recorded all clips (nearly) at full open aperture and 1/50sec, to get as much as possbile from this fullframe look. Surely this also costs some contrast. When recording I decided mostly to record at -2/3EV, to save the highlights and getting therefor a little more noise in the darks. But in the post that looks very unnatural, so I had to lighten it up again a little. Some smaller areas are too bright then, right.
Oh yes... it looked much better bofore uploading to youtube, but this is no secret. Maybe also this costs the last little contrast in some areas.

In the month of May, I spent my vacation in the Seychelles. It took weeks to scroll through the 550GB of MLV files I recorded there... the final holiday video was finished in the last summer days. Now Ilia brought the new color processing to MLVApp. I tested with some clips and was so impressed by the colors, so I decided to create another shorter public version. Here it is:

I am not 100% satisfied by the smoothness of my glidecam movement - I probably should have balanced it better. But the climate has been a heavy burden on the Glidecam too. After one week the ball bearing was rusty and my only chance to repair was to steal some drops of hydraulic oil from my rental car... 
Gear used is: 5D Mark II, EF 16-35 2.8 L II, EF 100mm 2.0 and a GoPro 3 for the underwater and cycle clips. All clips from the EOS are processed and color corrected using MLVApp only.

Make sure to watch in maximum resolution youtube offers... the compression is... ARGGHH

Wow, how easy / quick did you find it? I'm using lightroom to colour at the moment.

If you use lightroom, you shouldn't have bigger problems with MLVApp, because nearly everything is at the same place. Export works way faster and no need for intermediate formats. Just load MLV and export graded ProRes.

I'm curious to know: that strange contour of the falling sun – was that real stratification of atmosphere, or that's a kind of dual-iso artefact?

The build used by ilia doesn't support dual-iso (as I know)...

[Edit]

Agree that master curve is where one go first. The separated color curves are there to color correct(more control) but of course optional.

Wtf. The separated curves are already there @Lars Steenhoff!

Yes... but Lars asked to have 4 separate diagrams.
When I find time I'll also fix them for retina screens... dragging is not possible atm as expected. On non retina it works fine.
Edit: fixed.

Wonderful @Ilia! I really enjoyed watching this! You used the "Film FJ" filter?

Maybe something useful here:
https://patchwork.ffmpeg.org/patch/10104/
https://pypi.org/project/openlut/

Thanks Danne, but it is no LUT. The processing is very simple, and the diagram needs a cubic spline function in background.

yes thats what I mean

Haha... hm... sure it is possible. But the most of the time I needed, to get it working as it is now, was getting all 4 diagrams into one. :-D Better to start another new class for this than patching the existing one.
But why would you prefer 4 diagrams? All the apps I know combine the curves...
First I would like to get the stupid 1D cubic spline functions working correctly. If someone is good in math or knows a good free and easy C library for that, please let me know.

can you make an option to show them as 3 seprate curves?

you mean 4 curves in 4 diagrams?

My feature request list:
- visualize Cut In/Out position on playback timeline
- Create Virtual Copy (like in Lightroom)

For visualizing cut in and out, I would need a special graphics element, which I don't have. And I had no luck so far to create this one.

@domasa I like the idea of multiple versions of one file a lot. Instead of saying "file already in session" would be nice if "add another copy?" What do you think @masc? Also would be nice if they got grouped together.

Virtual copy could be realized somehow, but will bring a couple of problems. In past I this was no fun for me, why I decided to forbid it with the message "file already in session".

The only big thing that's missing for me now is receipt slots.

Sry... I know and thought a lot about it already... but I still have no good idea for this.

Curve tool! Awesome!

Yes... since some hours first version of curves tool is added. But there are still bugs in the code... (some problems with cubic splines, and selection and dragging problems on apple retina displays).