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

[Luther]

I have already made a compressed Linux tarball of MLV-App.  I cleaned out a lot of the compiling cruft, and I created a README file.  I also made a zip version (with the symlinks flag).  These archives are 60MB (smaller than the AppImage).

Wouldn't it be better to just make an apt port (or use whatever package manager your distro has)? Same goes for Windows/OSX, actually. Everything could be installed through Chocolatey or Homebrew.

[tupp]

Wouldn't it be better to just make an apt port (or use whatever package manager your distro has)? Same goes for Windows/OSX, actually. Everything could be installed through Chocolatey or Homebrew.

Making distro-specific packages probably wouldn't be better from an "ease of maintenance and install" perspective.  Package managers such as apt, rpm, pacman, etc (and, perhaps, Chocolatey and Homebrew) fulfill dependencies from an OS's package repository (or "store").  So, it gets complex from the package developer's/maintainer's perspective, as every required dependency from every distro's repository has to work properly.

The developer could avoid those difficulties by maintaining versions of all dependencies for each distro in an independent, dedicated  repository, but, of course, that is a significant undertaking.  Such a scenario would additionally require that the user modify his/her repository list to include that independent repository (which can be somewhat daunting).

It's much easier for the developer of a special app to simply include all of the dependencies in an archive with the main binary.  It is just as easy for the user to to simply unpack the archive and run the binary, as it is for the user to update a repository list, install the app and run it normally.

[Luther]

It is just as easy for the user to to simply unpack the archive and run the binary, as it is for the user to update a repository list, install the app and run it normally.

Yeah, but normally easy is not the correct thing to do. If you distribute your software in a whole binary, your system will have different binaries for the same software. This will cause software to be out of date. Also, if you don't use a package manager, you'll need some kind of update checking code, which can be eliminated while using a package manager (MLVApp should even have network capable code in the first place). And from a security stand point a package manager is much better (protocol is encrypted, files signed and hash checked - some even have privilege separation).

So, it gets complex from the package developer's/maintainer's perspective

For a project with many dependencies, I agree. But MLVApp has only two dependencies and one of them is already well maintained on most systems (Qt).

Some useful links:
https://github.com/chocolatey/choco/wiki/CreatePackagesQuickStart
https://github.com/Homebrew/homebrew-cask/blob/master/doc/development/adding_a_cask.md
https://www.debian.org/doc/manuals/debmake-doc/ch05.en.html

[tupp]

Yeah, but normally easy is not the correct thing to do.

Who's to say?  What is considered "easy" and what is considered "correct" are two independent and subjective notions.

If you distribute your software in a whole binary, your system will have different binaries for the same software.

Most of the time, but not always.

In this case, we have two versions of ffmpeg -- the user's system version and, apparently, the version specially compiled for MLV-App, as suggested by @masc:

The included ffmpeg version should be used always!!! If you use another ffmpeg, nobody knows if it works for all features.

I would rather have two ffmpegs than bork some MLV-App features.

This will cause software to be out of date. Also, if you don't use a package manager, you'll need some kind of update checking code, which can be eliminated while using a package manager (MLVApp should even have network capable code in the first place).

Huh?

Every time a new MLV-App version appears, one merely downloads the archive and upacks it in the same location as the previous version.

No problem.

By the way, MLV-App is likewise installed without a package manager with the AppImage and with the Mac (and probably Windows) package.

And from a security stand point a package manager is much better (protocol is encrypted, files signed and hash checked - some even have privilege separation).

A package manager doesn't provide more security -- it basically just automates the install and reduces redundancy.

There is nothing preventing someone from encrypting, signing and check-summing a Linxux tarball, a Mac DMG nor an independent Windows program.

By the way, in Linux, MLV-App is usually installed somewhere in the user's home directory, so it only runs with that user's priveleges.

For a project with many dependencies, I agree. But MLVApp has only two dependencies and one of them is already well maintained on most systems (Qt).

There seem to be lots of dependencies -- just look at the file/directory tree in this post.

I tried to run the unintended mlvapp binary found in the root, " /squashfs-root/" directory of the extracted MLV-App, and it looked in my system's /usr/lib/ for all of the MLV-App libraries that were unpacked in /squashfs-root/usr/lib/.  Those libraries are not in my system's /usr/lib/ directory, so MLV-App stalled.

Hence, all of the libraries and shared objects packaged with MLV-App are dependencies.

Some useful links:
https://github.com/chocolatey/choco/wiki/CreatePackagesQuickStart
https://github.com/Homebrew/homebrew-cask/blob/master/doc/development/adding_a_cask.md
https://www.debian.org/doc/manuals/debmake-doc/ch05.en.html

Thanks.

[Luther]

Who's to say?  What is considered "easy" and what is considered "correct" are two independent and subjective notions.

They are not subjective notions, we are not talking about philosophy we are talking about computing.

Most of the time, but not always.

Doesn't matter, many software will be redundant and out of date.

I would rather have two ffmpegs than bork some MLV-App features.

In the ffmpeg case, there would be no choice other than distribute the binary or give the package manager the order to compile the package itself.

one merely downloads the archive and upacks it in the same location as the previous version.

That's the point. This process can be easily automated.

A package manager doesn't provide more security -- it basically just automates the install and reduces redundancy.

That's just false. Most package managers require signing with PGP. The files are transported over encrypted connection (TLS1.2 or recently 1.3) and files have integrity check with SHA256/512. If you don't see the security benefits here, I don't know what to tell you.

There is nothing preventing someone from encrypting, signing and check-summing a Linxux tarball, a Mac DMG nor an independent Windows program.

Indeed, there's not. But these systems already have a unified solution, so why not use them?

There seem to be lots of dependencies -- just look at the file/directory tree in this post.

Those doesn't seem to be dependencies, they are in the software itself.

Those libraries are not in my system's /usr/lib/ directory, so MLV-App stalled.

Of course not, that's the function of the package manager to put them there.

Hence, all of the libraries and shared objects packaged with MLV-App are dependencies.

Libs != dependencies

[Kharak]

I noticed Slimraw lossless compressed dng’s can not be transcoded to MLV.

Does Mlv App “expect” lossless compressed dng’s from MLV_dump to be able to uncompress/transcode them back to MLV?

Slimraw does a better compression than mlv_dump, I’d say about 10-15% more compression or put it this way, you can compress the lossless output from Mlv_dump with slimraw by another 10-15% or so, lossless.

Would you consider looking in to supporting lossless dng from Slimraw?

[masc]

If it is just the appimage size: we also can zip it in future.
For me the good thing on a "All Inclusive Package" is: you get what we tested. In past we tried to keep the number of depencies low: now we use openMP and Qt, a ffmpeg version which we tested with MLVApp and a raw2mlv executable. The downside on Qt: there are many many versions out there. And some features change over time. So if a feature works with one Qt version, it might look different with another. That's why I don't like package managers. In our archives we can include the best working libraries we can find.
If you search a Debian package of MLVApp, you find it here:
http://phd-sid.ethz.ch/debian/mlv-app/
(1.10 is latest atm)

[ilia3101]

I noticed Slimraw lossless compressed dng’s can not be transcoded to MLV.

That means raw2mlv (meaning, LibRaw) does not support that specific format of DNG. LibRaw is supposed to support all raw formats, but there's a few it does not seem to work with. You could sumbit a issue on github: github.com/LibRaw/LibRaw - send them a sample file

[tupp]

They are not subjective notions, we are not talking about philosophy we are talking about computing.

Please pardon me.  I forgot that there are no subjective opinions concerning computing.

Doesn't matter, many software will be redundant and out of date.

It matters.

As I said, in this case, we have two versions of ffmpeg -- the user's system version and, apparently, the version specially compiled for MLV-App, as suggested by @masc.  This is a special case and not "many software."

Furthermore, even with a package manager, the user usually still has to manually command an update -- auto-update mechanisms are commonly not the default.

In addition, "many" folks employ an "app"  directory in their home directory for just such special cases.  I have such a directory and it contains 13 apps, all up-to-date, except for the ones I specifically have not updated -- very easy. convenient and foolproof to do without a package manager and I never have to worry about a package manager inadvertently updating a package that I have intentionally downgraded.  One more thing, such a directory makes it very easy to run a downgraded version of an app , while also the "current" version of the app maintained by the package manager.  Additionally, one of the apps

In the ffmpeg case, there would be no choice other than distribute the binary or give the package manager the order to compile the package itself.

Yes.  So, the first "choice" applies here -- the MLV-App binaries are distributed in their own self-contained packages :  Mac DMG,  'nix AppImage, Windows "whatever" (with it's own "installer?")  and, potentially, a Linux tarball.

That's the point. This process can be easily automated.

No.  Not through a package manager.

Trying to keep differing versions of the same app and differing versions of the same libraries with a package manager is difficult to set-up as a maintainer (and one first has to recruit such a maintainer), and can often be complex to set-up as a user.

It is easy enough just to unpack a tarball and run the app from there.

That's just false. Most package managers require signing with PGP. The files are transported over encrypted connection (TLS1.2 or recently 1.3) and files have integrity check with SHA256/512. If you don't see the security benefits here, I don't know what to tell you.

It's not false.

I said, "A package manager doesn't provide ***more*** security -- it basically just automates the install and reduces redundancy.  There is nothing preventing someone from encrypting, signing and check-summing a Linxux tarball, a Mac DMG nor an independent Windows program."

So, one can also use PGP signing and check-summing  with an independent tarball, AppImage or dmg (as I actually stated), just like a package manager might do.

Hence, a package manager doesn't provide ***more*** security than an AppImage, DMG, tarball, etc.

Indeed, there's not.

So, we agree that package managers don't provide more security, immediately after stating that assertion is false?

But these systems already have a unified solution, so why not use them?

For the reasons that I have repeatedly stated.  Basically, it is often easier to distribute and run special apps (such as MLV-App) without using a package manager.

Those doesn't seem to be dependencies, they are in the software itself.

No.  They aren't "in" the software.  They are separate, independent files, as shown in the directory/file tree.

Of course not, that's the function of the package manager to put them there.

So, ignoring the mud-slog of having to set-up such dependency functionality with each package manager, those libraries and shared objects are required by the main binary.

Thus, the binary depends on those files.

Libs != dependencies

On the contrary, libraries are probably the most common software dependency.


This line of discussion has taken this thread off the rails, and I cannot keep repeating myself.  I merely tried to offer improved instructions for the MLV-App focus dot pixels and to provide a Linux tarball of the AppImage, but it seems to have devolved into qualitative opinions and semantics arguments regarding package managers vs. self-contained packages.

I have to move on.

[Luther]

It's not false.

I said, "A package manager doesn't provide ***more*** security -- it basically just automates the install and reduces redundancy.  There is nothing preventing someone from encrypting, signing and check-summing a Linxux tarball, a Mac DMG nor an independent Windows program."

So, one can also use PGP signing and check-summing  with an independent tarball, AppImage or dmg (as I actually stated), just like a package manager might do.

Hence, a package manager doesn't provide ***more*** security than an AppImage, DMG, tarball, etc.

Seriously dude? Call me when you wake up. This is the same as saying OMEMO doesn't offer more security, because you can just check fingerprints manually and encrypt your text with AES-256. That's just a dumb way of thinking. If the process is not automated, normal people just won't do it.
There's a reason why package managers exist for so long: they work.

[Ottoga]

@Luthor @Tupp

Let's remember that all the development work and distribution packaging is being done by people who aren't getting paid for it and doing it in their spare time. So how about we stop the pissing contest.

@Luthor If you feel that strongly that MLVAPP should be distributed via a packaging tool then: perhaps put your hand up and volunteer to take ownership of packaging and distributing the app for the developers unpaid in your spare time.

If not, then I think your suggestions have been heard load and clear. However at the end of the day it is up to the developers to decide on their distribution process.

[Danne]

@Luthor If you feel that strongly that MLVAPP should be distributed via a packaging tool then: perhaps put your hand up and volunteer to take ownership of packaging and distributing the app for the developers unpaid in your spare time.

If not, then I think your suggestions have been heard load and clear. However at the end of the day it is up to the developers to decide on their distribution process.

+1

[bouncyball]

+1

[yokashin]

 

[olofen]

   Hi,
I am searching (in vain...?) for a way to postprocess my CinemaDNG files from MLV to ProRes 444 to be able to work in FCP X.
Someone mentioned somewhere that I could do it through Apple Compressor but I only meet greyed out files...
Why I want this is because I can adjust the CinemaDNG files in Photoshop in a good way as an intermediate process
Is it possible? Did I do something wrong?
    Please help me out!
         yours
      olof thiel

[Danne]

What do you mean?
Dng to prores can be achieved wkth mlv app resolve and acr för instance. What's the problem?

[masc]

You can do that with Quicktime or in Resolve. Or you don't use CinemaDNG and convert straight to ProRes.

[olofen]

I want to be able to work with the CinemaDNG files in Photoshop before converting them to ProRes 444....

[Danne]

Closest thing is going through after effects, using adobe camera raw.

[yourboylloyd]

I want to be able to work with the CinemaDNG files in Photoshop before converting them to ProRes 444....

Photoshopping hundereds of cDNG files is going to be rough. Like Danne said, use after effects (it's the same as photoshop because of Adobe Camera Raw). This is the fastest workflow if you want to stick with Adobe https://www.magiclantern.fm/forum/index.php?topic=13354.msg128954#msg128954 . It uses "Smart Import 2" and lets you adjust multiple DNG's at once that are in the folder.

But MLVapp can do all of that too and is much faster. Davinci Resolve is the fastest for editing cDNG files by an exponential amount though and it's free.

[olofen]

You mean you can get ProRes out of After Effects...?
(Sorry about my ignorance but I never worked with After Effects but if it works I will get it)

[Danne]

You mean you can get ProRes out of After Effects...?
(Sorry about my ignorance but I never worked with After Effects but if it works I will get it)

Stop your "ignorance" by using search from now on. Even google will do the trick. Think you got enough hints already.

[olofen]

I learn 👍

[cmh]

I want to be able to work with the CinemaDNG files in Photoshop before converting them to ProRes 444....

This is how I would proceed: I would get IWLTBAP LUT Generator, generate an hald LUT put the hald ontop of a frame in Photoshop, "grade" everything, cut the hald part out of the image, save that as a PNG and generate a x64 cube LUT that I would import in MLVApp (or Resolve but you should test this by yourself). That woud serve as a base for a grade or a reference.
Look at their website for more in-depth explainations, that is a very useful tool (that I used to convert gmic's hald to cube).

If you are on Windows, MLVApp uses ffmpeg so your ProRes 444 would be 10 bits but on Mac it should be 12 bits  if i'm not mistaken.
With Resolve on Windows, you can export to DNxHR 444 12 bits and Prores should be available on Mac, I'm not sure.

From an esthetic point of view if the goal is to apply a film emulation preset to your shots keep in mind that they are meant for photography and might end up very strong in the context of videography (for the same reason I don't find trying to copy a look from a movie by grading a still particularly relevant, it might look good on one frame but usually really bad on a scene for many reasons that would need a deep dive into cinematography). I don't find grading from Photoshop very appealing overall because it is utterly slow and would lack consistency between scenes but hey, to each his own, there's nothing wrong about experimenting. Feel free to share your findings (preferably in a dedicated post in the Raw Video Postprocessing section instead of this one if it doesn't involve MLVApp).

[2blackbar]

google's pixel 2 XL  RAW DNG files transcode and import is broken again in 1.1, it was fixed in the sourcecode for previous versions but looks like was not merged into new one.
But when i swap old raw2mlv then it says that cant find the MLV file, so more than that was changed.
I know its pretty vague but this hsould fix it, ill try to do it myself and compile raw2mlv again with this change
IT should be :

Code: [Select]

        "Pixel 2 XL-Google-google",
        {
         0.0127,  0.0727,  0.5789,
            -0.2806,  1.0683,  0.2451,
            1.2341, -0.6660,  0.0994
        },
        {
            -0.0558,  0.1620,  0.5206,
          -0.3982,  1.2675,  0.1412,
            1.0612, -0.4169, -0.1001
        }