Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - masc

Pages: [1] 2 3 ... 52
The link is correct, but not trail. Use the open source version. When installing, you'll need 5.13.1 for Windows with MinGW7.3.0 and QtCreator (then you'll get a Win64 build). All other options won't be needed (if I remember right). If something is missing, it is always possible to install it later.
With that you'll be able to compile the same version you can download from our download page.

@jimiz: thanks for testing... but these things won't be the problem. ffmpeg is identical. Your drivers are identical (for 1.8 and 1.9). Code of MLVApp is identical between win32 & win64. The only thing what's different now is the compiler and the Qt dlls for the new win64 build. And the only way to find the reason will be installing Qt (which includes a debugger), start MLVApp from Qt with debugger, let MLVApp crash, and then look where it happens (debugger shows the position in code). With this information we maybe (and hopefully) could solve it... But it will only be possible to solve on a system, where the crash happens.

v1.10 will only be better, if we find the reason. Without a fix, I bet it will crash the same way.

Found an old Win7Pro laptop... no crash with win64 1.9 versions.

@liquidether: thanks for the report. I will do some research. These are the points I always ask for testers... ;)
Edit: found and fixed for the future.

@ngemu: it was explained in detail last week or so in this thread. I added the information to MLVApp Wiki.
If you just select a preset you'll have the same as in v1.8.

same problem...
I'v reistalled the dirvers video..  but no change...x64 crash on any MLV import... (only this 1.9)      32x work fine..

but I have win7 (64) not 10....
On a system like this someone should install a debugger and tell what's happening. No crash on all my systems, so I can't help at all.

Qt 5.9.8 , MinGW 5.3.0
How you guys compile MLVApp? I read about it after installing qt , opening then press Build and Run , but the output here isn't same as released versions , also I can't run my compiled MLVApp without qt creator , could you explain your steps @masc @bouncyball for compiling ?
So you compiled a 32bit version. Out of the box the app just works in QtCreator. This is correct. If you like to run the app standalone, you have to "deploy". This means you'll have to search through the Qt folder and find the needed dlls.
Newer versions do the deployment with a tool, for older versions you have to do it 100% manually. Maybe you find another webpage with more information about this. I did manually in past, but it is so long time ago... forgot where I found the information howto. Just search for "deployment".

@theBilalFakhouri: what Qt version have you installed? I have Qt 5.13.1 with MinGW 7.3.0 on WinPro 8.1.

But as written: for the Win32 version really nothing changed in terms of audio playback at all.

Would be great if someone who has a crashing MLVApp could install Qt and use the debugger - just for telling me in which line and file the crash happens. No need for coding skills.

Sorry guys. Can't reproduce. All works fine here with Win64 version. No idea where to search. No additional lib or driver is required. Just Windows.
Before we had a "static" version, which included all those files in the exe. This somehow doesn't work anymore. So we had to find a new toolchain for 64bit, which links dynamic now. So you have all the dll files now.

win10 (64) 
Mlv app 1.9 (64bit) Crash  ??? ;)

Mlv app 1.9 (32bit) works
And how do you get it crashed? The same way as jimiz? Some more info would be helpful.

win7 (64) 
with 1.9 x64  any MLV import, no video compare..and crash program... (long last 1.8 was all ok)
Could you uplaod a short MLV sample? Can't get any crash here. What do you mean with "video compare"?

Thanks guys.

Sound playback isn't working in MLVApp 1.9 unfortunately on Windows (I tried both 32 & 64 bit) , maybe there is a problem with compiling
Sound works fine over here on both Win versions. Have you enabled output? We changed absolutely nothing for sound playback, toolchain for Win32 version is also identical to v1.8.

For all users who were waiting for so long... v1.9 is out:
- Processing upgrade: tonemapping function, gamut and gamma can now be set individually
- Log profiles now have correct gamuts, in addition to the curve. Can match your Alexa very accurately.
- Added multithreaded AVIR rescaling for AVFoundation export, single frame PNG export and viewer
- Added sharpen mask slider (sharpen just edges)
- Added "move to trash" for MLV clips + MAPP files in session
- Added a dialog which shows all installed and the currently used focus pixel map(s)
- Added a new tonemap function "Reinhard 3/5"
- Space button on last frame starts playback from beginning
- Some bug fixes and some minor changes

Isn't it easier to run second MLVApp in Background and make communication between the Main MLVApp and the Background copies (Instead of doing it manually in my case , I mean split the work between MLVApps copies from XX frame to XX frame) ? for good Multiprocessing and Multithreading at the same time without re-coding algorithms , Or you just want good algorithms for these things for not complicate the things more ? Not sure I am not a coder.
This is more or less what we did in past. Not with MLVApp copies, but with copies of pipelines. Partially you must allow access only to one single pipeline to certain memory spaces (e.g. file reading, parameter settings,...), so you'll have to lock and unlock some sections, this makes the game very difficult. Hard to explain in an easy way for non-SW-developpers. It is way easier if the user runs multiple instances of a program manually.

Another Question about only single threaded stages in the pipeline , These single threaded stages must be single threaded ? or more knowledge required to get it working multithreaded properly ? . .
These are algorithms implemented for being single threaded. Examples are Dual-ISO, Recursive Bilateral Filter "RBF" (for highlights, shadows, clarity and denoiser). Maybe it is possible to get it multithreaded somehow - but not with our existing code. So someone should understand how that has to work and write a own multithreaded implementation.

Edit: especially for the RBF filter it would bring a lot of speed. I found this algorithm here: There are ways for getting it faster (see diagrams). Problem: the algorithm is for RGB24 (3x8bit) by standard. With some effort I managed to get it to RGB48 (3x16bit) with some changes in the code. But this luck I just had for the simplest "standard/original implementation", not for the SSE and AVX versions. And - really - I have no idea at all how that works.

This idea is so old as MLVApp itself. One of the very first versions was working this way. Then we decided to render a frame with multiple threads - as far as possible. Both strategies will fight against each other in terms of CPU power, and will partially lock themselfs when being called from one app. This is why the "multiple frames at one time" strategy was removed. There were many thoughts behind that. I can't and won't write down all that again. You'll find it here in the thread and on github (about 1.5 years ago).

The advantage of the current strategy is fast(er) playback. The disadvantage is, that if a algorithm (part of processing pipeline) can only be rendered single threaded, you'll waste your power. We know that. The current Dual-ISO algorithm is just single threaded. If someone likes, you're welcome to implement a multi-threaded version of it. When we tried in past, we failed.

If it helps having multiple instances of MLVApp, this is by far the easiest way to minimize the rendering time. All other solution would mean to re-implement processing and piping nealry from scratch.

Cs 3x3. Nothing wrong with sharpness there. Slight color shift though towards green.
Sharpness is little less, especially with 1080p footage. For the green color shift try out RAW black level... +-1 fixes this - whyever.

o0o0o0ohh that's a gnarly piece of vintage!

That's incredible. Big shout out to @Danne! Was this shot in 2.35:1 re: AR?

Copy that. Will do. Didn't realize AVIR even existed within MLV App.  :P
Oh yes... love these lens(es) from the first minute! ;) Tried here the 35mm 2.4, but have two others to try out (50mm 1.4 and 135mm 3.5). The 35mm is so sharp, that you can get very bad moiree on fine structures with EOS M 18MP fullres cr2 images !with aperture full open!. (Have never seen something like this with all my Canon lenses.) ;D

Latest vid was filmed in 2.35:1.

AVIR is a kind of hidden feature for viewer, single PNG export and AVFoundation export in v1.9. You just see it in the about box.  ;)

... Only cost me ... three sd cards  :P
Really? OMG. I still use my first SD card.

Thanks guys.

Interested to see how much sharper it would look from a tripod, as I guess stabilisation you used  reduced quality a bit (always did in my experience).

Did another test with a Carl Zeiss Jena vintage lens. Got an adapter for PB to EOS which allows focus to infinity. I thought a monopod + neck strap is okay for a little more stabilization. I was wrong. Downscaled to FHD post stabilizers seem to work better than with 4K footage. But then you throw away so much detail... :(
Big thanks to Danne: I used 4K anamorphic rewire mode and got not a single corrupted frame all over the day! That's awesome!
Graded all clips with the upcomming MLVApp v1.9.

Lately, I've been using Lanczos even when exporting in H.264! ;)

Especially if you only plan on doing all the grade solely within MLV App prior to exporting.  8)
Lanczos was good. AVIR is even better. You really should try it! ;) Future plan is to remove all the ffmpeg scaling functions and to insert just AVIR.

Raw Video / Re: EOS M RAW in 2019 against 4k options like a Panasonic G7
« on: September 17, 2019, 03:12:21 PM »
I've seen the video quality in the eos m and it's impressive but I'm kind of afraid that the crop factor is too severe and that the kit lens loses all of its purpose making a 18mm into a 60mm.
Why that? Use 4K anamorphic mode to use (nearly) the full sensor width. Then you won't have (much) additional crop!

General Development Discussion / Re: Dealing with Focus Pixels in raw video
« on: September 16, 2019, 08:57:45 PM »
Thank you dfort! This works excellent! No more focus pixels in this mode.
As far as I understood, for MLVApp the fpm name has to fit exactly the raw buffer resolution found in the MLV header. So this should be identical to MLVFS.

Yepp... have seen this color shift since a very long time. One of the reasons why I mostly don't like to use chroma smooth. If someone knows how this algorithm works... maybe there is some small bug or it is the way it has to look - I have no idea. All I found: when using chroma smooth, set RAW black level +1 or -1 to default value and the shift disappears.
For topic focus pixels: better using a correct map instead of blurring the whole picture with chroma smooth. Chroma smooth is kind of "last resort" if nothing else helps.

General Development Discussion / Re: Dealing with Focus Pixels in raw video
« on: September 15, 2019, 09:50:47 AM »
Looks like the current maps are working well. I'd like to come up with a way to generate maps for every possible setting but it is like trying to herd cats.
Can't completely agree... I mean the maps are working well, yes... but for this MLV file there is no map. At least I installed all maps from your repos and MVLApp won't select one of them. So the focus pixels won't be removed (completely) - it just looks as if the old coded pixel removal removes some of the focus pixels. In latest revision (to be compiled) there is a small dialog showing which maps are installed and which map is used (if a map is used).

For the MLV I uploaded, no "green line" is shown (-> no map used).

You can try out now. Commited.

Thank you, theBilalFakhouri. So you just used default settings. If (with same settings) bilinear brings 100% CPU usage and AMaZE does not, you're right: it can only be something related to debayer algorithms.
And I think I found it. The only thing changed between 1.7 and 1.8 in terms of debayer was wb-conversion for AMaZE, IGV, AHD and LMMSE. These algorithms became slow while others stayed fast. When watching these two wb-conversion functions, there is an openMP call per function. I exchanged it and got 100% CPU usage instead of 51% on Windows on an i7. I'll do some more tests later and will commit then. Having just 2 or 4 threads the difference is close to 0, while having 8 threads (and surely more) it gets visible.

@MagicPhotoEvents: looks like a linux theme problem. Have you modded your Ubuntu somehow? Never seen this, but
Code: [Select]
(mlvapp:7147): Gtk-WARNING **: 08:53:36.023: Theme file for DMZ-Black has no directories
Gtk-Message: 08:53:36.149: GtkDialog mapped without a transient parent. This is discouraged.
makes me think so. Does the official release (AppImage) create the same error?

Can you share your settings (receipt)? If you e.g. used Clarity / Highlights / Shadows I know what is going on (but this came in 1.7) ;) AMaZE is so a little part in the overall system, it won't depend on just this. AMaZE itself always uses 100%. So if you see low values here, another processing part is pulling it down. This only can be a single-threaded algorithm.

@masc I will shot a video MLVApp showing 16 FPS AMaZE without caching)
If you rechecked, no need for it ;) I trust you...

Thanks Danne. Reproduced. Will have a look.

Edit: fixed.

Camera-specific discussion / Re: Canon EOS M
« on: September 12, 2019, 08:35:24 PM »
No it isn't. I use it at 2.35:1, because then it gets continuous (at 1464x1870 (4K anamorphic rewire)).

Pages: [1] 2 3 ... 52