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 ... 83
@masc there are reports about focus pixels fixing being not that good for dual ISO. I tried moving the focus pixels fix after the dual iso processing and it seems to work very well (better than with the current flow) with the interpolation method 3 + chroma smooth 3x3.

The only problem is that, as soon as I switch Focus pixels fix OFF, I cannot turn it ON again. I have to turn OFF Dual iso, set focus pixels on, and then turn dual iso ON again.
I tried to follow the update process but it's quite hard, I couldn't find the reason why an innocent change in the order will do that  ::)

I've created a branch in case you would have time to check:
I loaded this branch, compiled and loaded one of your sunset clips. Just chroma smoothing can kill (most of the) focus pixels. The behaviour you described... can't see it. Focus pixel buttons don't have any effect. Chroma smooth is working On/Off. Is it the correct branch?

Edit... as soon as I write it, I found it. Is @bouncyball still in the house? Did you implement some intermediate buffer for faster processing here? Unfortunately I am not very deep in llrawproc functions. I just build the GUI around it...

Edit2: what about things like that:
Code: [Select]
/* do chroma smoothing */
    if (video->llrawproc->chroma_smooth && video->llrawproc->dual_iso != 1) // do not smooth 20bit dualiso raw

When will you release an updated version on the website? :)
Release comes when it is ready. Until that: feel free to compile as much commits you like. It is very easy.

Is this increase only on Mac? Any chance for the Windows version?
The dualiso refactoring is for all OS. The compiler optimization is macOS only.

Maybe letting the user adjust the value using a slider could be a temporary solution at least
Let me know if you wish me to create another slider. I then need min/max value and number of steps.

@iaburn: VERY IMPRESSIVE! WOW! Tested your dualiso clips on Intel i7 Quadcore Mac. In playback it feels like double speed now. In export to ProRes422 AVFoundation: 1:26 vs. 1:00 for your 100frames 2.5K clip. The cores now are used!

However I found a problematic clip, which now looks worse than before - even if it is processed also in double speed. See all the artifacts around the tree. Left: yours, right: official. Most of this can be removed with MLVApp CA Desaturate slider. But in e.g. Resolve, this doesn't exist.

Cool stuff will test later. By the way. Uploaded a new eos m version build. With 2.8 it would not start recoridn dualiso until like the third frame but fixed now.

Another question. I believe dualiso was autodetected before? Seems the diso blcok is there but Mlv app isn´t following it anymore? @masc?
Code: [Select]
Block: DISO
  Offset: 0x000007f0
  Number: 17
    Size: 24
    Time: 7738.273000 ms
     Mode:        1
     ISO Value:   0
Mode: 1

Here it still works... in both versions, official and iaburns. (if "force" button is hidden, all is fine. In my screenshot, the clip is too old for this.)

The only problem on my computer at least, is that the bigger the window, the slower the playback... A 1080p clip plays at over 25fps if I make the window small, but just about 12fps when I make it bigger.  It doesn't happen on my windows PC.
That is because of QPainter / QGraphicsScene engine. I found no way to have it always fast. It seems it draws the pixels individually...  ::)

The uploaded codes, compiled and tested ends in strange processing. Each try looks different, for one and the same frame...

Edit: Same for MacOS arm64
I've noticed the biggest gains with this clip, from 6:25 on the current version, to 1:42 on this test version  :o
Unfortunately it doesn't work here. Can't open the app and also can't sign it. Something seems to be wrong.

Edit: downloaded and compiled your version:
the stripes are gone with it. Speed is better: 1:24min the main branch, 1:16min with your branch. Both exported to ProRes422 on my MacBookAir M1.

Nice work!

I think CUDA is no option at all. In comparison there are just a few computers able to run this, while e.g. OpenCL works on nearly all computers out of the box. So if we would implement GPU features, I'd try again with OpenCL. And there is already a CUDA based MLV tool: fastcinemadng. I was never able to try it - no CUDA GPU in my near.

@iaburn: openmp is not difficult to understand. There are these #pragma lines, which will make 'for' loops multi threaded. There should be no dependency between the loop iterations - this can't work. (e.g. writing on same variable)

This would work:
Code: [Select]
#pragma ...
for(int i = 0; i < n; i++)
    c[i] = a[i] + b[i];

@iaburn: if you know how to use the GPU... I have absolutely no idea here. I just heard it is impossible with C/C++, because it has its own kernel language. So this means mostly rewriting everything.
Yes, in the past we tried to use the GPU for debayering. In the end we had success with it technically, but it was slower as with CPU, because the copy actions between graphic RAM and main RAM needed nearly the same time as if the CPU debayers. So GPU might be cool if you process all on it - single tasks are probably for nothing.

Sometimes it is good, if we just hide features instead of deleting them, if not working... nice find!  8)

are we getting close to a new mlv app official version?
i'd like to try it again comparing to resolve, and any extra speed for the windows version would be most welcomed!
Could anyone share an updated build of Mlv app for Windows?
Each commit and dev work brings us closer... but there is still a way to go. iaburn just started porting dualiso and already did a great job. Thank you!

Don't expect the Windows version to get faster until now - this was a macOS compiler optimization. And Windows offers no hardware support for ProRes encoders.
As compiling MLVApp is really very easy, you could compile each commit you like, test and report.

EDIT: btw I tried MLV App official 1.14 release on my x86 Mac Windows partition and in terms of playback it sits just below latest local build with Qt6+llvm15 on MacOS (but still much higher than official 1.14 build on MacOS).
Official x86 macOS build was compiled with the old llvm@6, for supporting all macOS since 10.9.5. It is possible, that this is slower.

Just sharing MLV App installer (DMG) 'nightly build' (ref. commit 3330563) for OSX x86, built with Qt6 and llvm15:

Auto FocusPixelMap install is broken also with this version. Seems not to work on Qt6.4 yet. Many path related Qt6.4 functions fail (e.g. QFileInfo(<fileName>).exists() ). No idea why. No such problem on Qt5.15.

Qt6.5 is in beta state. You can load it from online installer. They plan to release end of march.

Unfortunately no change. Maybe it is Qt6: AVFoundation sound export had an issue, where Qt6 file, path and call commands did not work at all. With standard C functions: no prob. Map download inherits many many of these Qt lib calls. E.g. a simple QFileInfo("filename").exists() always fails here with Qt6.4, same for QProcess::execute("application").

Hm, here it doesn't work with your version. Loading a clip which needs a map doesn't open the known messagebox. Pixels are visible. On my Intel Mac I've seen, Qt did not find libssl, but it downloaded the maps anyway. In Windows version it was needed for downloading. So in my latest commits I added openssl to the linked LIBs. I don't see libssl and libcrypto in your build yet. Could we try again?

A separate post for a feature request: Would it be hard to add an option to export the MLV files attribute table (as reported in the Session Area when in Table Mode) in a very simple and handy format, say csv maybe?
Done. Please test.

@Danne: nice! FocusPixelMap auto downlod also works now?

So apparently I can confirm very slightly better performance during uncompressed cDNG export with Qt6 / llvm15 local build on Mac x86:
cDNG export is not a major strength of MLVApp - more a side product for a longer feature list. Lossless de-/compression is single threaded. So don't expect much changes here. MLVFS is in advantage here (even if - i think - they use the same algorithm), if the NLE preloads more than one frame - then you get multithreading.

The table was/is already planned and should be doable. I just need the time to do this.

Thanks for that info. I never signed any app I compiled :-D

I get 25fps with both, local latest revision and official build. On BigSur MBA2020 M1.
With fps-override to 60fps, I get 30fps with local latest revision, and 27fps with official build. The 10% more now...

Do you have a special test clip I could test? And which receipt - default?

Interesting I get slow playback with the official MLV.App.v1.14.macOS-ARM64.dmg release. With my own compiled build I get 25fps 100% realtime. Not sure the official build is optimized with llvm@15.
I suspect Ventura OS and the old QT5.15 round trip isn´t working optimal now.

The build I sent you iaburn, is it also choppy/slow?
Are you testing your own compiled build?
The official MLV.App.v1.14.macOS-ARM64.dmg release was compiled with llvm@11. But 25fps is no problem. Latest revision compiled with llvm@15 is maybe up to 10% faster in playback.

Something has to be wrong with my machine. I get now much slower playback speed than before, but no idea what could it be  ???
Do you compile with llvm compiler now? And also: did you uncomment  these lines in .pro file?
Code: [Select]
#Qt5 on Apple Silicon with openMP: install llvm via brew, build Qt5 from source
        QMAKE_CC = /opt/homebrew/opt/llvm/bin/clang
        QMAKE_CXX = /opt/homebrew/opt/llvm/bin/clang++
        QMAKE_LINK = /opt/homebrew/opt/llvm/bin/clang++
        QMAKE_CFLAGS += -fopenmp -ftree-vectorize
        QMAKE_CXXFLAGS += -fopenmp -std=c++15 -ftree-vectorize
        INCLUDEPATH += -I/opt/homebrew/opt/llvm/include
        LIBS += -L/opt/homebrew/opt/llvm/lib -lomp -L/opt/homebrew/opt/openssl/lib -lssl

Hi, just wanted to mention that the dimensions of the video on the screen while playing a video have a massive impact on playback speed.
I didn't noticed because I always have the window maximized and I'm used to have the same performance while playing videos regardless of the window size.
Is it so optimized that it actually process less pixels when the screen is smaller, or is the opposite and final scaling is not optimized?  ::)
This is because of the Qt framework: the used pixels of the video on the screen matter how fast Qt shows the images. We always render the full picture. I wouldn't call it "optimized". So maximized (and maybe with hidden Edit, Session and Audio area (press E, S, A)) it is way slower than in a "small video box".

Do you use the standard Apple compiler? This one offers no openMP (Open Multiprocessing). So many algorithms run single threaded. That is okay for debugging but slower than official version. Install llvm via brew, add the new compiler in "Compilers" in your screenshot frame, and then select in Kits the llvm compiler.
Code: [Select]
brew install llvm

Pages: [1] 2 3 ... 83