Messages

When I try over terminal i get this - ./MLV.App.v1.11.Linux.x86_64.AppImage: error while loading shared libraries: libnsl.so.1: cannot open shared object file: No such file or directory

The MLVapp appimage for Linux is sort of messy.  It contains two binaries that are different, and one of them commonly gives errors similar to the one you mentioned, although I suspect that the problem might also involve Fedora's removal of the library in question, to which @masc linked.

Try extracting the appimage (which creates the "squashfs-root/" directory containing all files), and then run the MLVapp binary that usually doesn't give the dependency errors:

Code Select Expand

$ ./MLV.App.v1.11.Linux.x86_64.AppImage --appimage-extract
$ ./squashfs-root/usr/bin/mlvapp

If you still get the same error on the missing library, try copying the library from where it resides on your Fedora install into the newly extracted lib directory:

Code Select Expand

$ cp -ivp /path/to/your/fedora/library squashfs-root/usr/lib/

Now, try running the MLVapp binary again:

Code Select Expand

$ ./squashfs-root/usr/bin/mlvapp

I have installed libnsl, but nothing has changed

If the above steps don't work, make sure that you have the specified version of the needed library(s).  If you are using another version of the library, install the needed version and repeat the above steps.


If none of these steps work, you could also try the same commands above with the usually problematic MLVapp binary and see what happens. To start that binary, do this:

Code Select Expand

$ ./squashfs-root/mlvapp


[***more***]

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.

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.

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.

Okay. I bet this should only be inside the structure, but not in the root folder. I hope the mlvapp executable inside bin is newer.

The working mlvapp binary is located in the /squashfs-root/usr/bin/ directory.  The AppImage has a working symlink (AppRun -> usr/bin/mlvapp) that is integral to the AppImage structure.

Do you guys send the app (and its directories) around in "zip" files before creating the AppImage?  If so, zipping without an "allow symlinks" flag would probably explain the broken binary in the root directory.

Where have you read this? I just see "copy "ffmpeg" and "raw2mlv" executable in this newly created directory". Nobody wrote (as I know) of a systems version of ffmpeg. Those hints came from another user who wanted to help us - maybe these days the archive was wrong the same way. I understood to copy ffmpeg from bin to archive root. But I would never ever use "any" ffmpeg.

I was mistaken.  The Wiki doesn't specify where to get ffmpeg, so I just assumed that it meant one must provide it.  However, others might interpret those instructions similarly.

It shouldn't be too much trouble to make things clearer in the instructions.

Okay, but this is just one function you used from ffmpeg. There are many others like stabilizer and ...

I know.  I just tried my system's ffmpeg to see what would happen.

You could also create an issue on github. Maybe others like to contribute as well with that. And with Linux I believe everything anybody tells me 

Ha, ha!

It would be great if I could send the instructions through this site.  I have no experience with github, but it's owned by Microsoft.  I would like to avoid signing-up with and giving details to Microsoft.

The main problem is, we need RAW data. For non-RAW pictures/videos you must somehow "undo calculate" unknown camera matrix, burned-in white balance and other things. I think this would never look good.

Could just interpret it as sRGB, and figure out a basic curve to un-do it. But dynamic range would be bad.  This could be done very well with log I think. Log could be input in to a raw converter quite easily. Unfortunately this won't be happening with MLV App, it's tightly wrapped to MLV.

Okay.  Just asking.  It's a shame that it can't be, though.

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).

I don't see any way of attaching files to posts nor to direct messages here, so if anyone would like to have these files, we have to figure out how to make that happen.

Thanks!

Okaaay. Two binaries? I never tried to unpack the image. I just have compiled it and I was happy when the appimage process ended without error but with an appimage.

Here is the directory/file tree of the unpacked AppImage:

Code Select Expand

squashfs-root
├── AppRun -> usr/bin/mlvapp
├── Makefile
├── mlvapp
├── mlvapp.desktop
├── MLVAPP.png
├── raw2mlv
└── usr
    ├── bin
    │   ├── ffmpeg
    │   ├── mlvapp
    │   ├── qt.conf
    │   └── raw2mlv
    ├── lib
    │   ├── libasyncns.so.0
    │   ├── libdbus-1.so.3
    │   ├── libEGL.so.1
    │   ├── libffi.so.6
    │   ├── libFLAC.so.8
    │   ├── libgbm.so.1
    │   ├── libgmodule-2.0.so.0
    │   ├── libgomp.so.1
    │   ├── libgstapp-1.0.so.0
    │   ├── libgstaudio-1.0.so.0
    │   ├── libgstbase-1.0.so.0
    │   ├── libgstpbutils-1.0.so.0
    │   ├── libgstreamer-1.0.so.0
    │   ├── libgsttag-1.0.so.0
    │   ├── libgstvideo-1.0.so.0
    │   ├── libgthread-2.0.so.0
    │   ├── libicudata.so.56
    │   ├── libicui18n.so.56
    │   ├── libicuuc.so.56
    │   ├── libjasper.so.1
    │   ├── libjpeg.so.8
    │   ├── libjson-c.so.2
    │   ├── libogg.so.0
    │   ├── liborc-0.4.so.0
    │   ├── libpcre.so.3
    │   ├── libpng12.so.0
    │   ├── libpulsecommon-4.0.so
    │   ├── libpulse-mainloop-glib.so.0
    │   ├── libpulse.so.0
    │   ├── libqgsttools_p.so.1
    │   ├── libQt5Core.so.5
    │   ├── libQt5DBus.so.5
    │   ├── libQt5Gui.so.5
    │   ├── libQt5Multimedia.so.5
    │   ├── libQt5MultimediaWidgets.so.5
    │   ├── libQt5Network.so.5
    │   ├── libQt5OpenGL.so.5
    │   ├── libQt5Widgets.so.5
    │   ├── libQt5XcbQpa.so.5
    │   ├── libsndfile.so.1
    │   ├── libvorbisenc.so.2
    │   ├── libvorbis.so.0
    │   ├── libwayland-client.so.0
    │   ├── libwayland-server.so.0
    │   ├── libwrap.so.0
    │   ├── libX11-xcb.so.1
    │   ├── libXau.so.6
    │   ├── libxcb-dri2.so.0
    │   ├── libxcb-dri3.so.0
    │   ├── libxcb-glx.so.0
    │   ├── libxcb-present.so.0
    │   ├── libxcb-sync.so.1
    │   ├── libxcb-xfixes.so.0
    │   ├── libXdamage.so.1
    │   ├── libXdmcp.so.6
    │   ├── libXext.so.6
    │   ├── libXfixes.so.3
    │   ├── libXi.so.6
    │   ├── libxshmfence.so.1
    │   └── libXxf86vm.so.1
    ├── plugins
    │   ├── audio
    │   │   ├── libqtaudio_alsa.so
    │   │   └── libqtmedia_pulse.so
    │   ├── bearer
    │   │   ├── libqconnmanbearer.so
    │   │   ├── libqgenericbearer.so
    │   │   └── libqnmbearer.so
    │   ├── imageformats
    │   │   ├── libqgif.so
    │   │   ├── libqicns.so
    │   │   ├── libqico.so
    │   │   ├── libqjp2.so
    │   │   ├── libqjpeg.so
    │   │   ├── libqtga.so
    │   │   ├── libqtiff.so
    │   │   ├── libqwbmp.so
    │   │   └── libqwebp.so
    │   ├── mediaservice
    │   │   ├── libgstaudiodecoder.so
    │   │   ├── libgstcamerabin.so
    │   │   ├── libgstmediacapture.so
    │   │   └── libgstmediaplayer.so
    │   ├── platforminputcontexts
    │   │   ├── libcomposeplatforminputcontextplugin.so
    │   │   └── libibusplatforminputcontextplugin.so
    │   ├── platforms
    │   │   └── libqxcb.so
    │   └── xcbglintegrations
    │       ├── libqxcb-egl-integration.so
    │       └── libqxcb-glx-integration.so
    ├── share
    │   ├── applications
    │   │   └── mlvapp.desktop
    │   ├── doc
    │   │   ├── libasyncns0
    │   │   │   └── copyright
    │   │   ├── libdbus-1-3
    │   │   │   └── copyright
    │   │   ├── libegl1-mesa-lts-xenial
    │   │   │   └── copyright
    │   │   ├── libffi6
    │   │   │   └── copyright
    │   │   ├── libflac8
    │   │   │   └── copyright
    │   │   ├── libglib2.0-0
    │   │   │   └── copyright
    │   │   ├── libgstreamer1.0-0
    │   │   │   └── copyright
    │   │   ├── libgstreamer-plugins-base1.0-0
    │   │   │   └── copyright
    │   │   ├── libjasper1
    │   │   │   └── copyright
    │   │   ├── libjpeg-turbo8
    │   │   │   └── copyright
    │   │   ├── libjson-c2
    │   │   │   └── copyright
    │   │   ├── libogg0
    │   │   │   └── copyright
    │   │   ├── liborc-0.4-0
    │   │   │   └── copyright
    │   │   ├── libpcre3
    │   │   │   └── copyright
    │   │   ├── libpng12-0
    │   │   │   └── copyright
    │   │   ├── libpulse0
    │   │   │   └── copyright
    │   │   ├── libpulse-mainloop-glib0
    │   │   │   └── copyright
    │   │   ├── libsndfile1
    │   │   │   └── copyright
    │   │   ├── libvorbis0a
    │   │   │   └── copyright
    │   │   ├── libvorbisenc2
    │   │   │   └── copyright
    │   │   ├── libwayland-client0
    │   │   │   └── copyright
    │   │   ├── libwayland-server0
    │   │   │   └── copyright
    │   │   ├── libwrap0
    │   │   │   └── copyright
    │   │   ├── libx11-xcb1
    │   │   │   └── copyright
    │   │   ├── libxau6
    │   │   │   └── copyright
    │   │   ├── libxcb-dri2-0-dev
    │   │   │   └── copyright
    │   │   ├── libxcb-dri3-0
    │   │   │   └── copyright
    │   │   ├── libxcb-glx0-dev
    │   │   │   └── copyright
    │   │   ├── libxcb-present0
    │   │   │   └── copyright
    │   │   ├── libxcb-sync1
    │   │   │   └── copyright
    │   │   ├── libxcb-xfixes0
    │   │   │   └── copyright
    │   │   ├── libxdamage1
    │   │   │   └── copyright
    │   │   ├── libxdmcp6
    │   │   │   └── copyright
    │   │   ├── libxext6
    │   │   │   └── copyright
    │   │   ├── libxfixes3
    │   │   │   └── copyright
    │   │   ├── libxi6
    │   │   │   └── copyright
    │   │   ├── libxshmfence1
    │   │   │   └── copyright
    │   │   └── libxxf86vm1
    │   │       └── copyright
    │   └── icons
    │       └── hicolor
    │           └── 512x512
    │               └── apps
    │                   └── MLVAPP.png
    └── translations
        ├── qt_bg.qm
        ├── qt_ca.qm
        ├── qt_cs.qm
        ├── qt_da.qm
        ├── qt_de.qm
        ├── qt_en.qm
        ├── qt_es.qm
        ├── qt_fi.qm
        ├── qt_fr.qm
        ├── qt_gd.qm
        ├── qt_he.qm
        ├── qt_hu.qm
        ├── qt_it.qm
        ├── qt_ja.qm
        ├── qt_ko.qm
        ├── qt_lv.qm
        ├── qt_pl.qm
        ├── qt_ru.qm
        ├── qt_sk.qm
        └── qt_uk.qm

57 directories, 153 files

As you can see, there are two "mlvapp" binaries, along with the "AppRun" link to the working mlvapp binary).

Also note the two "raw2mlv" binaries plus the single instance of "ffmpeg."

In addition, there are two "MLVAPP.png" images.

The included ffmpeg version should be used always!!! If you use another ffmpeg, nobody knows if it works for all features. It is just important, that ffmpeg is in the same folder as the mlvapp executable. Otherwise it should not work. Same for raw2mlv. It must be located in the same folder!

The MLV-App Wiki instructs Linux users to copy their system's version of ffmpeg into MLV-Apps extracted root directory.  This action is sort of futile, as the mlvapp binary in that root directory fails while seeking dependencies on the user's system (specifically, in "/usr/lib/").

However, if one runs the mlvapp binary found in the extracted "/squashfs-root/usr/bin/" directory, MLV-App and the included ffmpeg binary works.  By the way, I tried replacing that included version of ffmpeg with the one on my system and I didn't have any trouble exporting an MP4 file from MLV-App.

The reason why we write to use the drag and drop feature is, it always works. In the past it felt like 90% of the users failed with manual copy actions. And for some people even the drag and drop is hard to understand. But if copying the files works for, you can always do that!

After more than 40 years of the personal computing era, the preponderance of computer illiteracy is staggering.  It is amazing how many folks have trouble with something as fundamental as copying files from one directory to another.

Regardless, the instructions should mention the fact that the focus pixel maps are merely copied into a directory, and the instructions should also give the location and name of that directory ("/squashfs-root/usr/bin/" for the extracted Linux AppImage).

Feel free to contribute! That is very much welcome! Also if you find a way to create the appimage in a better way, you can help if you like. We implemented MLVApp mostly on OSX. On Windows I know how to get it to work. But on Linux I am just happy if it compiles and creates the appimage somehow, and it starts if I doubleclick the image.

Okay!   Should I just DM the instructions to you?

In regards to creating an AppImage, my experience is limited mostly to running them and to the extraction that I had to perform to add the focus pixel maps.  I cannot speak for every Linux user, but I would prefer the additional option of having the files and directories of the app packed into a standard tar archive (or a compressed tar archive).  Although one can run an AppImage with only one command (or mouse click), the user must still unpack the MLV-App Appimage to use focus pixel maps.   It takes the same effort to unpack a tar archive and then run (click on) the binary.  Plus, there is no "compiling" a tar archive -- just create the archive (just like a zip file) and compress it, if you like.

I am happy to help in the creation of an MLV-App tar archive (and in cleaning-up the files/folders), but making a tar archive from folders and files is really "dumb-simple."

No idea what this plugin folder is and what it does. Should be something from the appimage. MLVApp has no plugin feature at the moment.

Judging from what's listed in the directory/file tree above, it appears that the "/squashfs-root/usr/plugins/" directory contains needed shared object libraries related to decoding/encoding audio and video formats.

If a version of the "Blue Banana" interface was an option in MLV-App, it could ease simple color grading (although it is very powerful in Cinelerra).

There is a way to import non-mlv, yes, but there is no way to import non-raw files. DNG, CR2, ... can be transcoded to MLV via raw2mlv, which is included in the package. Use "Transcode and Import" from the menu. You'll find the menu action only, if raw2mlv is on the right place (same folder as MLVApp executable). MLVApp imports the created MLV when transcoding is ready.

I thought I saw a way to import jpegs in the MLV-App menus. Even if one converted a video to a series of jpegs and there was an import function, image degradation would be a concern.  If importing jpegs is not possible, it might be a little unwieldy to convert video files to a compatible raw format, and then transcode with raw2mlv.

Some of us shoot ML H264 with boosted bit rate and/or all-I settings.  So, it would be great to be able to use MLV-App on those ML-generated files.

Thanks!

Thank you for the wonderful MLV App!

I run Devuan Linux, and I just installed the the 1.11 appimage!

I also installed the focus pixel maps (fantastic feature!), but the MLV App Wiki is problematic in regards to its instructions on installing the focus pixel maps on a Linux system.

One issue is that there are two mlvapp binaries in the appimage, but only one of them works (unfortunately, not the one referred to in the "Fix Focus Dots" instructions).  The two binaries are the same size, but I ran a checksum on both binaries, and got different results.

Another complication is that the appimage already includes a version of ffmpeg that works, so there might not be any need to copy the user's version of ffmpeg into the extracted appimage folders, as the wiki instructs.

Also, the focus pixel maps can merely be "copied" to a sub-directory of the extracted appimage.  It would likely be better to instruct Linux users to just copy the files (or at least mention that possibility), rather than only telling Linux users to "install" the focus pixle maps in the nice drag-&-drop manner suggested by the Wiki.  Some Linux users use simple window managers, rather than full-blown desktops, so the simple file manger that they use might not be capable of dragging/dropping files into other apps.

There is probably a way to make these instructions clearer, and I would be happy to contribute in that regard.

While I was exploring the extracted files, I noticed that there is a "plugin" folder.  It would be amazing if a version of the Cinelerra "Blue Banana" plug-in could be imported into MLV App.

One more thing, is there a way to import non-mlv and non-raw files?  I could probably convert a video to cinema DNGs or to jpegs, but it would be incredible if MLV App could manipulate mp4's, Quicktime files, mkv's, etc.  If it could do so, I would use it for everything!

Thanks!

sysvinit-inittab
    [snip]
sysvinit
    [snip]
Does this mean that the new camera runs Linux internally, and does it mean anything for us users?

Don't know what is running Linux, but at least it isn't using systemd!

She takes photos with manual lens not correctly. The image after the shot is much brighter than the one that is visible on the display at the time of shooting. This happens on all manual lenses

The EOS-M1 does not have proper exposure simulation when using manual lenses.  Not sure if it is the same with the EOS-M2

However, it seems that Magiclantern can provide proper exposure simulation with the EOS-M1 and manual lenses.  The trick is to go to the ML "Exposure" menu and disable "ExpSim" and enable "ExpoOveride."

Yes.  The huge variety of lenses and adapters is a significant advantage of the EOSM.

With the right adapter, you can use C-mount (and PL mount), 16mm lenses that work wonderfully with the new EOSM raw crop modes, but you cannot do the same with any of the DSLRs -- not without an expensive, perilous mod.

You can also use speedboosters/focal-reducers on the EOSM to essentially give a full frame look when used with a full frame lens, and gain an extra stop of exposure, to boot!  The APS-C DSLRs can't take speedboosters/focal-reducers.

Also, you can use other special adapters on the EOSM, such as tilt/swing or tilt/shift adapters, which are perfect for full frame lenses on an APS-C sensor.  Again, this is not possible on the DSLRs.

The biggest drawback of the EOSM is the slow SD card controller, but the recent ML advances in SD card overclocking have largely overcome that issue.

@AF-OFF
Thank you for the instructions on getting "full sensor" 1736x1120 raw working on the EOSM!  Very helpful!

Unsure on this bit:

Go to ML menu -> Scripts and select one of the mv1080p_12bit scripts.

There is a selection?  Which one is best?

Now I just have to figure out the easiest post "workflow" in Linux.

Thanks!

Looks like a console with boot messages.

I am fairly certain that there is an ML menu setting to enable/disable this console.  I think there is such a setting in modules/debug.

Perhaps someone more knowledgeable can chime in.

Ok, but if the resolution is the same in a case, color depth and bit depth has the same value.

Well, resolution and bit depth are the two, equally-weighted factors of digital color depth.  So, if the value of one of those factors remains constant (resolution, in your case), the color depth will change with the value of the other factor (bit depth, in your case).

Likewise, a 10-bit HD image will have less color depth than a 10-bit 4K image.

Also, an 8-bit 8K image will have more color depth than a 10-bit HD image. 

Don't really get the point of binning pixels? The image will still use the same amount of storage? Say if you go from 1080p 8-bit - to binning pixels and 10-bit?

Yes.  The "storage" required is essentially the color depth of a digital image.

In film you always talk about bit depth and the image resolution is known, in my world its not wrong as it affect color depth and always get same value if the resolution is the same.

Yes.  As acknowledged above, if the resolution remains constant in a digital system, the color depth increases/decreases with a change in bit depth.

However, with actual "film," there is no "bit depth" -- analog film is not digital.  So color depth of actual film comes from resolution (grain size) and from dye/emulsion properties (which, in combination, can be considered the analog "equivalent" of bit depth).

But yes this pixelbinning thing is possible, I understand how it affect bitdepth and color depth if you alter resolution, but why use it? Just because its possible?

In any situation in which one is down-scaling an image (such as the common 4K-to-HD conversion), it makes sense to bin the pixels to retain the color depth (and to also reduce noise and to avoid moire/aliasing).

Yes and even if the colordepth is increased?

The color depth of a digital image can never be increased, unless something artificial is added.

If you record your 8-bit signal within a 16-bit file, it won't be better then the original 8-bit/8 bits per channel (color depth).

Yes.  The image will not improve merely by putting it into a file/system of a higher bit depth.  On the other hand, in doing so you will technically have an image of a higher bit depth.

This product claims to use supersampling which results in a pseudo-10-bit color sampling for improved color reproduction. Does this mean that encoding with this product will result in better quality than the original 8-bit hdmi?

Bit depth can be genuinely increased by binning together adjacent pixel groups.  However, resolution is sacrificed with such a method.

Also, such an increase in bit depth will not improve the color depth, as the color depth of an image can never be increased unless something artificial is added.  Contrary to popular belief, bit depth is not color depth.

Furthermore, artifacts in the original image (such as banding) will remain even if the bit depth is increased.

Looks good!

Thanks!

dpjpandone worked on that code and he has moved on to other interests but his build with the All-I/GOP controls is still in his Dropbox and his Bitbucket account is still online though I couldn't find anything related to what you're looking for in there.

Thanks for the links!

I have already installed dpjpandone's build and enabled ALL-I and boosted the bitrate to 1.5x.  Will test soon, and, if there are no glitches, I will gradually increase the bitrate until the video breaks.

The topic you referred to seems pretty clear. Just uncomment this line:

platform/EOSM.202/features.h

Code Select Expand

//~ #define FEATURE_VIDEO_HACKS // unclean patching


and add these lines:

platform/EOSM.202/Makefile.setup.default

Code Select Expand

ML_SRC_EXTRA_OBJS = \
video_hacksU.o \

Thank you!  So I can uncomment and add said lines to any recent version of ML source code?

Does clearing the settings remove the picture styles? I'm not sure, I'd have to try it out and see.

I think it does... it's mentioned in the ML install instructions.

Resetting the Canon settings usually isn't necessary. For me I found it sometimes helps after doing a Canon firmware update but otherwise I rarely clear the settings.

Thanks!!!  That was very helpful to know!  Saved me a lot of hassle!

@dfort:

Thank you for the prompt reply!

I found where I previously inquired about the All-I/GOP controls in this thread here:
https://www.magiclantern.fm/forum/index.php?topic=9741.msg156491#msg156491

You directed me to another thread in which some of the steps were outlined on compiling the GOP control:
https://www.magiclantern.fm/forum/index.php?topic=15685.msg152612#msg152612

I am unsure on a few things.  Is the code mentioned in the thread above included in the source, so all I have to do is uncomment the lines before compiling?  If not, where do I paste the lines into the source?

Also, I have read that it is suggested to reset the camera before installing ML.  Is this always necessary?  Doing so is problematic for me as I run Linux and have picture styles installed -- I would have to get access to a Windows/Mac machine to reinstall those picture styles.

Thanks!

Hi!

Great work being done with the EOSM (and other models) in regards to raw with SD card overclock!

However, I am one of those strange outcasts who is still interested in shooting h264 with ALL-I frames.  Has any progress been made in getting GOP controls into the main build?

One big advantage of h264 ALL-I is that it utilizes the entire area of the sensor, so that the character of lenses designed for APS-C/S35 doesn't get obliterated by using a crop mode.

If it is not in the main build, instructions on where to get the code and how to compile it would be greatly appreciated.  I have installed the gcc-arm-none-eabi package on my Debian-derived distro, but I am a little rusty on compiling procedures.

As I understand, there is a 3x3 binned raw mode that allows the use of the full width of the sensor.  Is that correct?  If so, that might work, as long as there is no excessive aliasing/moire nor a pink dot problem.  From my scans of the threads, I gather that @dfort has made EOSM pink dot masks, but I am not sure how to apply them.

Thanks!

Keep up the great work!!!

Thanks!

Thanks, Licaon_Kter.

Is the "catch" the problem that is described in this passage (from the dpjpandone post in the thread linked above):

If i recall correctly, the reason this is not included in main, is because the settings persist until you restart the camera, not only this, but the camera must be restarted with the same card (with the current implementation) in order to clear the settings, this presents a dangerous situation, as someone who isn't aware of this might remove their magic lantern card, and the GOP/flush settings don't go back to default

If so, I might keep using the "unmentionable fork" and its GOP controls, as, even though it is outdated, it doesn't seem to have this problem.

Thanks, dfort.

It appears perhaps that Licaon_Kter knows something that we don't.  The dpjpandone thread that you link indicate that there were extensive GOP and flush rate settings back in August, but dpjpandone recommended having only the choice between IPP and ALL-I.  However, Licaon_Kter seemed to imply that now there is only the choice of either IPP or ALL-I (with a locked, default flush rate), in coincidence with dpjpandone's recommendation.

Were dpjpandone's suggestions incorporated since last August, and, if so, could that be the reason why your compile attempt failed?

Thanks!  ALL-I is great!

Is this feature enabled, or does one have to compile?

Do we have GOP controls yet on the EOSM?

Thanks!

Request for GOP control seconded!

Nothing happens when I hit any other key to bring up the ML Menu.
How is one supposed to do that?

Try tapping the touchscreen with two fingers.