Messages

@Icaab: what difference do you see? Processing engine is always the same, no matter which bitdepth was used. So the result should look the same. The lower the bitdepth, the more noise in dark tones. You like to decrease quality of the high bitdepth clips?

adding tgis camera model like exiftool for addional functiinallity in davinci reaolve as suggested in the attached post

No attached post available. No idea what you're talking about...

If speed is important, do not use Windows. Using Unix you get much higher export speed on same hardware. Our algorithms are the same for all supported OS.

now importing 100 gb files into mlv app, they can be graded, but can not exported.

How that? No problem here. Is there a message? File size is a don't care for MLVApp.

@IBIRRU: hm... for PNG and TIFF there was a bug, which was fixed 7th july. But since then there was no new official release. When scrolling through the thread, I found this test build. Maybe try this for now:
https://www.magiclantern.fm/forum/index.php?topic=20025.msg242369#msg242369

I just can give you the code - everything else is magic for me

https://github.com/ilia3101/MLV-App/blob/master/src/processing/filter/genann/genann.c

Film is a look-simulation trained using neural networks. LUT uses 1D or 3D LUT files to change the look.

Aha, I see. Shadows and HL are a must, at least for me.

Not really. Try to pull down exposure and then raise "lighten". Looks mostly better, is always faster.

In MLVApp using Clarity, Highlights and Shadows also will destroy any good fps - special algorithms behind

Your points 1.4 and 2.4 might also vary a lot on what you setup in those applications. I bet this will be very hard to compare, if possible at all. Even for my own projects the export speed is different for each clip, because I use other features (but the same MLV setting on camera).

In 1. you still have RAW in the end, in 2. you have a nearly ready project.
--> You missed two very important underlined lines:
1.4 -> "5h" (Davinci does RAW processing and grading)
2.5 -> "5min" (Davinci just copies data)

The clip I used for M1 numbers was a 3K clip. Maybe try some non 1x3 clip, because 1x3 needs to be stretched. This needs additional time. But this time is worth it, because MLVApp uses AVIR which is by far superior to bicubic used by Resolve.

Cool! A Qt6.5+llvm16 version. Nice. Audio works. FocusPixelMap download doesn't (was never working with 6.x for other computers than your own - whyever)

What Mac are you using? Your export is extremely slow! Is this dualiso or something?

Tested your version on my MBP2018 on Intel with a 1856x1044 clip:
- 20fps preview
- 17.3fps export speed into ProRes422 with FastProxy receipt
- 14.1fps for cDNG
(And this MBP2018 is known to be very slow for processing, because of heavy heat throttling.)

The final grade export needs its time in MLVApp, yes. But here Resolve is very slow too on all my machines (if it works at all). And your calculation is wrong, if you compare cDNG against final grade.

What you asking for, already exists. Example: 5.2K EOSM export:
- H.265 12bit 444 "high" --> 36.2Mb/s = 4.5MB/s
- H.265 12bit 444 "medium" --> 5.4Mb/s = 0.67MB/s
Tested with MediaInfo.
Note: bitrate depends also on resolution and framerate.

@koopg: "this" = what?

My workflow for almost all videos I do:
1. Import all MLVs in MLVApp, set CutIn/CutOut to not render parts you'll never need, render as ProRes422 with AVFoundation. Use FastProxy.marxml for fastest export, or FastProxyRCD.marxml for better but fast debayer.
2. Import all .mov into your NLE
3. Cut/Edit in NLE
4. Export FCPXML from NLE
5. Import FCPXML in MLVApp
6. Color correction/grading in MLVApp, export as ProRes4444 with AVFoundation
7. Relink the graded clips in NLE
8. Export final from NLE

I use FCPX for this. But when I implemented the FCPXML feature into MLVApp, it worked also with Davinci. Since then I did not really use it anymore for such projects. To be tested with current versions...
Edit: works exactly this way also in Davinci Resolve, with nice performance.

@vastunghia: grading before edit makes no sense. Simple ProRes422 export is faster then cDNG export. Cut with this and grade the used clips later in MLVApp (use FCPXML import), then exchange the files. This makes sense not only for small videos. Especially for multiclip videos this is extremly powerful method: you can play and edit many clips in parallel in your NLE.
There were many fixes for AVFoundation export since last official version. Latest revision runs super fast and stable (my last >1TB without any issue). But this must be compiled first, there is no official release yet. Are you on Intel or Apple Silicon?

@togg: you could plan to do the color correction and grading in MLVApp - it is made for this.

[choppy preview]

...
Choices for each button:

• Half-Shutter:  OFF, Zoom x10

[li]...
[/li][/list]
...
-Fixed choppy preview while idle in 1080p 3x3 and HFR modes
...

Thanks for your quick update!
Two questions:
->Doing the Zoom on SET button works fine, while on Half-Shutter it just changes from FRTP to Framing. Is there another setting to avoid that, or am I doing something wrong?

->"choppy preview" means the black screen (HFR) and paused liveview (1080p)? 2nd works, 1st not (for me, in 2.35:1 and 2.39:1). Also here: am I doing something wrong?

And another problem: If I toggle between 2.8K and "Full-Res LV", I get crashes. After restart, Full-Res LV doesn't let me record (stops very quickly with invalid MLV).

Code Select Expand

ML ASSERT:
fullsize_buffers[1] == UNCACHEABLE(raw_info.buffer)
at mlv_lite.c:1514 (free_buffers), task shoot_task
lv:1 mode:3

shoot_task stack: 1f3cc8 [1f3e28-1f1e28]
0x000E8F28 @ c9018:1f3dc0
0xUNKNOWN  @ e8f7c:1f3da8
0x00B8591C @ b89888:1f3d08
0x0009EC30 @ b85980:1f3cf8
0x0009E558 @ 9ec8c:1f3cc8

Magic Lantern version : crop_mood.2023Apr16.EOSM202
Mercurial changeset   : NO HG
Built on 2023-04-15 22:02:10 UTC by bilal@DESKTOP-27BNL6E.
Free Memory  : 213K + 3138K

I found a small chance for easy GPU usage in MLVApp:
"openMP target" offloading.

As we already use openMP for CPU multiprocessing, this sounds good. But a first test program tells, my system has no device for offloading. Find the test program here:
https://enccs.github.io/openmp-gpu/target/

Output for MBA M1, same for Intel MBP:
"Number of available devices 0
Running on host"

openMP >=4 is needed. Latest LLVM versions (we use already) should support this.

Maybe someone finds how to use it.

For more modern laptops it seems it has changed.

ffmpeg on GPU would not bring much. And NVIDIA encoding doesn't work on any of my computers - probably the same for many if not most users. I also would not really recommend to render the clips to H264 or H265 if you want to edit. If you like HW encoding, try out the macOS version with AVFoundation - it brings more or less the same speed like preview without encoding (so I think Apple must do it in HW somehow). This can be faster than cDNG output. But encoding is the fastest part of creating the files. If you want to speed up MLVApp processing, you need to bring the entire RAW processing engine into GPU, not the encoding.

More tests on Apple Silicon M1, with the 3K testclip from @iaburn:
Export with my FastProxy receipt, ProRes422 AVFoundation: 8sec
Export to DNG lossless: 14sec


https://github.com/ilia3101/MLV-App/blob/master/receipts/FastProxy.marxml

Even with GPU processing, Resolve is slower for me, if it runs at all: 3h for 2min footage is normal here too. But I don't have a good GPU. Additionally 10x the time for making the footage look good plus all the artifacts it creates. 
ffmpeg doesn't render anything. MLVApp does the rendering. You need to bring all the proessing.c, raw_processing.c, as well as all related files into openCL (for best compatibility). CUDA, Metal and friends is no solution IMO. Starting point is function "getMlvProcessedFrame16(..)"

You are right. So what do you suggest to replicate MLVApp look in Resolve for every image? If the base settings are not enough a 3D LUT should cover it, no?
Maybe I forgot if there has been in the past a complete explanation of what MLVApp does to contrast and colours.

Processing in MLVApp and importing this into Resolve? I don't understand the need of replicating, when you can use the original for free.

I'm reviewing some samples and it looks like the focus pixels removal is not working for some modes like the 2.8K on the EOS M (2880x1226). I have old 2.8K clips (2800x1192) and it works fine on those.
Do some modes need new focus pixels maps for MLVApp?

Please try again. Uploaded a map.

masc: dumb question: it's not possible to force the threads to work on different image frames?

With current concept: no. But you could use MLVFS for this.

Could you please improve multithreading support using some help from ChatGPT?

...

Converting to Lossless CDNG with Dual ISO turned OFF, everyting else is default:

Macbook M1: 30 sec
AMD Epyc 6 core: 40 sec
AMD Epyc 44 core: 40 sec

If someone has a working multithreaded lj92 version for lossless encoding&decoding, please let me know. (As far as I know this is technically impossible, so runs always single threaded, for monochrome image data.)