MLV App 1.14 - All in one MLV Video Post Processing App [Windows, Mac and Linux]

[ilia3101]

wow, this looks great! I wonder how it will behave on skintones with saturated color lighting, because this problem exist even with standard cr2 files opened in photoshop sometimes..

I suspect it will be better than Adobe, except for highligh reconstruction. I'd love to see your results.

You can import your CR2 in to MLV App using File -> Transcode and import. It will convert any raw photos to an MLV.

[Skinny]

@ilia3101 Thanks, unfortunately I can't test it because builds after 1.12 (32-bit) don't work on my PC... it's from 2007. I can ask for cr2 if you want to check it out yourself and compare to Adobe or other software..

[ilia3101]

Ah that's annoying. Does it crash, or give any useful errors? Are you able to try compiling MLV App?

Also, maybe 1.14 will run. Perhaps 1.13 is just an unlucky coincidence.


And yes, I would love to see any difficult photos please.

[masc]

@ilia3101 Thanks, unfortunately I can't test it because builds after 1.12 (32-bit) don't work on my PC... it's from 2007. I can ask for cr2 if you want to check it out yourself and compare to Adobe or other software..

What OS do you use on this PC? And this OS is still 32bit? 2007 most PCs were already 64bit...
Maybe our used Qt library version was too new for your OS. Even Win7 isn't supported in latest Qt updates anymore.

[masc]

Finally, MLVApp v1.14 is out now. Thanks to all the contributors and testers.

New in v1.14:

• Added LUT navigator (by @orfeas-a)
• AgX: Hugely improved reproduction of saturated colours, with less clipping and smoother tonality. Especially helpful for shooting under RGB LEDs. Fixes cyan highlights and similar issues. Based on @sobotka's AgX display rendering transform.
• Added Davinci wide gamut profile
• Added changeable viewer background color
• Added clip renaming feature
• Added support for Apple Silicon
• Added pivot slider for contrast
• Added disk full check on export
• Added VP9 codec export
• Corrected color space tag in ffmpeg export
• Fixed focus pixel fix in DNG export
• Fixed 1D LUT processing
• Fixed bug when deleting a clip
• Updated to AVIR 3.0
• Some minor fixes
  

[Skinny]

Finally, MLVApp v1.14 is out now. Thanks to all the contributors and testers.

Great!

so, I'm using Windows 10 21H2 x64, and the processor is Intel(R) Core(TM)2 CPU 4400 @ 2.00GHz

Why 32 bit MLV App - because 1.12 32 bit is working here, but 64 is not. 1.13 doesn't work at all (as well as 1.14)

Are you able to try compiling MLV App?

I think I need to try it.. And maybe if I can use older QT version it will work?

And yes, I would love to see any difficult photos please.

ok, here are some files:
https://gofile.io/d/eh7zCN

In the archive you will find cr2 as well as processed jpeg files (just for reference). The problem is this purple light, which is a light source, so it should be brighter and not just dark purple color..
Photoshop camera raw profiles render it differently. Default Adobe profile is obviously worse, while "faithful" seems to be the most correct.. And not "neutral" as I was expecting.

But even then it still have some problems. For example if you look at 3384, in the center you will see a very saturated region on the hand/fingers which looks obviously kind of wrong..
As well as other problems, some photos looks better than the others. And sometimes it becomes very visible when photos are processed, for example if you add some contrast and change levels, gradients from these saturated regions become not as smooth as they should be, it can be really noticeable on the face for example. We can instantly tell if something wrong with person's face/skintones.

It's Rezeda's photos, and (fun fact) you subscribed to her youtube about a week ago...  I know she tried different things and at the end processed them with two different camera raw profiles, one for the overall look, and maybe "faithful" or "neutral" for the purple part of photos only. So obviously these saturated colors can be a little bit hard to work with..

[masc]

so, I'm using Windows 10 21H2 x64, and the processor is Intel(R) Core(TM)2 CPU 4400 @ 2.00GHz

Why 32 bit MLV App - because 1.12 32 bit is working here, but 64 is not. 1.13 doesn't work at all (as well as 1.14)
I think I need to try it.. And maybe if I can use older QT version it will work?

On Win10 all Qt 5.x should work. For MLVApp 1.14 we used 3 different versions of Qt, the oldest was 5.9.9. Can't believe non is working for you. There is still no message or something? I think it doesn't matter what version you try. Maybe try latest 5.x - should be 5.15.2.

[Skinny]

no message or anything, but I found under windows event viewer two types of errors - with code 1000 and 1005.
both of them doesn't explain much.. but there is an exception code.

1000 - "Faulting application: MLVApp.exe, version: 1.14.0.0"
Exception code: 0xc000001d

1005 - "Windows cannot access the file for one of the following reasons: there is a problem with the network connection, the disk that the file is stored on, or the storage drivers installed on this computer; or the disk is missing."
There is no information about what file it is or anything.
Application name: "Processing and converting tool for MLV files"

[ilia3101]

Thanks for the photos! Very pink, wow. Even new MLV App is having trouble. Switching to Arri Wide gamut helps as usual. But that's some insane pink. Will take a deeper look later.

I can't find information about the exact CPU model name you specified. Only core 2 duo comes up. Is it a core 2 duo? (If so, it would be 64 bit). Also wikipedia for core 2 says all core 2 are 64 bit - https://en.wikipedia.org/wiki/Intel_Core_2

You could try dual booting 64 bit linux, and running the Linux build, might be easier than compiling it yourself for Windows 🤷

Those error codes might be helpful. Thanks for sharing.

[names_are_hard]

Some Core2Duo don't have SSE4.1 support, looks like MLV App builds with that.  0xc000001d is illegal instruction, so it's plausible as a cause.

[ilia3101]

Thanks for pointing that out. Is that a compiler flag we're setting?

I think we should limit to SSE2, at least for the 32 bit builds.

[names_are_hard]

I don't know about 32 vs 64, but this is what I'm refering to, in platform/qt/MLVApp.pro:

Code: [Select]

QMAKE_CFLAGS += -O2 -fopenmp -msse4.1 -mssse3 -msse3 -msse2 -msse -D_FILE_OFFSET_BITS=64 -std=c99 -ftree-vectorize

I don't know Qt well at all, could be wrong.

[Skinny]

yes it's core 2 duo.

You could try dual booting 64 bit linux

do you know any protable linux version that I can just copy on the thumb drive and boot from it, instead of installing? for testing.

It could be SSE issue. What's interesting is that I haven't found any other program that won't run on this machine. Although I don't use a lot of applications.

Very pink, wow. Even new MLV App is having trouble.

By the way, it is not LED, it is just a standard white flash light with color filter on it. And it is not even that much as it can be sometimes.. for fashion photos it is normal to have very saturated colors sometimes. For example:
https://lindsayadlerphotography.com/fashion-i
https://lindsayadlerphotography.com/editorial-beauty

[masc]

librtprocess uses SSE4.1, which is used since 1.13.

Code: [Select]

#ifdef __SSE4_1__
Maybe undef it in .pro and compile.

Code: [Select]

DEFINES -= __SSE4_1__
My oldest laptop also is a Core2Duo (P8600), but it runs well there. Maybe a bit newer. The 4400 indeed has no SSE4.1.

[ilia3101]

do you know any protable linux version that I can just copy on the thumb drive and boot from it, instead of installing? for testing.

You can do this with normal ubuntu thumb dribe. But again, it may not run because of the SSE4.1 issue.

@masc What do you think about disabling SSE4.1 for 32 bit builds from now on? Or even on all builds, if the performance penalty isn't too great. It's a pretty weird instruction set that no one uses anyway.

By the way, it is not LED, it is just a standard white flash light with color filter on it.

That filter is likely producing a stronger pink than what's possible with typical RGB LEDs. I really appreciate having that photo to play with, so thanks again!

for fashion photos it is normal to have very saturated colors sometimes. For example:

Love bright colours. BTW, even in those examples, they aren't handled perfectly. I see digital skews/clipping in some of those photos.

My goal is to create digital image processing that handles bright colours smoothly. It's possible. Film does it. It's what I've been working towards for the past two years.

[masc]

I don't know about 32 vs 64, but this is what I'm refering to, in platform/qt/MLVApp.pro:

Code: [Select]

QMAKE_CFLAGS += -O2 -fopenmp -msse4.1 -mssse3 -msse3 -msse2 -msse -D_FILE_OFFSET_BITS=64 -std=c99 -ftree-vectorize

I don't know Qt well at all, could be wrong.

For Qt pro files "win32" and "win64" is the same.

@masc What do you think about disabling SSE4.1 for 32 bit builds from now on? Or even on all builds, if the performance penalty isn't too great. It's a pretty weird instruction set that no one uses anyway.

We have to disable it manually by changing the .pro file, before compiling this version. If someone knows about a "working" Win32/64 switch for .pro files, please let me know!


Could you please try this? Should be SSE4.1 free. Even before no feature used it in win32 version, just the compiler flag was enabled.
https://www.dropbox.com/s/ofqvc9vmmffarpl/MLVAppWin32Test.zip?dl=0

[BatchGordon]

My goal is to create digital image processing that handles bright colours smoothly. It's possible. Film does it. It's what I've been working towards for the past two years.

That's a great goal.
Color science (including color smoothness and highlight rolloff) can make more difference in the beauty of an image than the dynamic range and much-much-more difference than the resolution (personally I don't care too much of resolution unless it's less than 720p).

About this, are colors in MlvApp treated like in the color science of Arri Alexa (or Amira), with color saturation limited to a certain value like in watercolors?

[Skinny]

Could you please try this?

Thanks, it works! You guys are awesome!
I had to copy libgomp-1.dll from 1.14 Win32 version, because it is not included in the archive. And it opens up. I also copied ffmpeg and some other stuff, exported some MLV footage and everything seems to work perfectly

By the way I can instantly see benefits of AgX function - just opened some random mlv file, it was a test clip shot from my window (crappy and noisy) but it has red "Hotel" sign (LED) and it looks much better with AgX enabled.

Love bright colours. BTW, even in those examples, they aren't handled perfectly.

I know I can see it too now

My goal is to create digital image processing that handles bright colours smoothly. It's possible. Film does it. It's what I've been working towards for the past two years.

I agree, this is really great. Keep us updated I think everyone wants to have "film-like" colors.

[names_are_hard]

Cool, probably SSE4.1 then.  I think 64 bit builds should work fine for you so long as they don't include that.  And 32 bit OS *can* use SSE4.1 (and all other SSE), just not your core2duo because it is super old

Even before no feature used it in win32 version, just the compiler flag was enabled

The compiler will optimise using sse4.1 ops when it feels like it, can happen in any code.

The sophisticated fix would be something like: use CPUID to detect features at runtime, build multiple object files, some with sse4.1, some without, and swap function pointers / load different DLL or .so based on CPUID results.  Probably quite annoying work to do.

CPUs from about 2008 should have SSE4.1 and 4 is a big upgrade from prior versions, I expect you'll see noticeable perf drop with it disabled (have to test to be sure, of course).  How much do you want to support 15 year old hardware?

[bouncyball]

Huston I've got a problem.

Hey guys I cant export fimage sequence (tiff, png, jp2) from mlvapp any more (Linux, v1.14). Craches/closes on fist frame every time with all MLVs.

The issue is not observed with v1.13. Tried 2 ffmpeg binaries with the same result.

Can you guys try this? No special steps needed for reproducing, just load mlv and export to TIFF sequence.

Valgrind does not give any sane information. Guess it is something with pipe but only for image sequences _not_for_video_ files.

Code: [Select]


Process terminating with default action of signal 13 (SIGPIPE)
==7341==    at 0x7113C5F: __libc_write (write.c:26)
==7341==    by 0x7113C5F: write (write.c:24)
==7341==    by 0x70960AC: _IO_file_write@@GLIBC_2.2.5 (fileops.c:1180)
==7341==    by 0x709544F: new_do_write (fileops.c:448)
==7341==    by 0x7097128: _IO_do_write@@GLIBC_2.2.5 (fileops.c:425)
==7341==    by 0x709676D: _IO_new_file_xsputn (fileops.c:1243)
==7341==    by 0x709676D: _IO_file_xsputn@@GLIBC_2.2.5 (fileops.c:1196)
==7341==    by 0x708B886: fwrite (iofwrite.c:39)
==7341==    by 0x15814D: MainWindow::startExportPipe(QString) (MainWindow.cpp:2619)
==7341==    by 0x186400: MainWindow::exportHandler() (MainWindow.cpp:8174)
==7341==    by 0x17C80F: MainWindow::on_actionExport_triggered() (MainWindow.cpp:6628)
==7341==    by 0x30D4DA: MainWindow::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (moc_MainWindow.cpp:1492)
==7341==    by 0x30EBC2: MainWindow::qt_metacall(QMetaObject::Call, int, void**) (moc_MainWindow.cpp:1769)
==7341==    by 0x68CA656: void doActivate<false>(QObject*, int, void**) (in /home/nic/Qt5.14.2/5.14.2/gcc_64/lib/libQt5Core.so.5.14.2)
==7341==
==7341== HEAP SUMMARY:
==7341==     in use at exit: 135,989,283 bytes in 98,200 blocks
==7341==   total heap usage: 1,221,836 allocs, 1,123,636 frees, 8,090,879,848 bytes allocated
==7341==
==7341== Searching for pointers to 98,200 not-freed blocks
==7341== Checked 474,945,176 bytes
==7341==
==7341== LEAK SUMMARY:
==7341==    definitely lost: 896 bytes in 7 blocks
==7341==    indirectly lost: 1,465 bytes in 45 blocks
==7341==      possibly lost: 6,673,015 bytes in 345 blocks
==7341==    still reachable: 129,313,907 bytes in 97,803 blocks
==7341==                       of which reachable via heuristic:
==7341==                         newarray           : 4,288 bytes in 2 blocks
==7341==                         multipleinheritance: 16,240 bytes in 22 blocks
==7341==         suppressed: 0 bytes in 0 blocks
==7341== Rerun with --leak-check=full to see details of leaked memory
==7341==
==7341== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)


[bouncyball]

Debug bails out here:

MainWindow.cpp

Code: [Select]

-> 2619                fwrite(imgBuffer, sizeof( uint16_t ), frameSize, pPipe);


[theBilalFakhouri]

on Windows, exporting to tiff or png using 1.14 MLVApp, CMD shows for a less than second then closes very fast and MLVApp doesn't crash, progress bar is working but of course there is no exported frames.

Using 1.13 version, it works fine.

[70MM13]

if you launch mlvapp using a command prompt, you might see what is going wrong... maybe

[masc]

ffmpeg output tells for TIFF "%7" is the problem in the used command. This is the colortag change we did - it seems nobody tested that. But I don't understand why argument no7 isn't inserted into the command string.

Edit: please try latest commit. I just sorted the arguments and now it is working here.

[bouncyball]

That's it!

ffmpeg chokes on colortag option if sequence is chosen right?