Messages

However, when I unmount the mlv and then mount it again, the xmp is gone. Maybe this is a good thing, since it implies AFX is not altering the mlv file.
If I want to retain the AFX/ACR import settings more permanently, I can save an xmp manually in the ACR settings folder (or maybe just drag the xmp from the virtual folder into a real folder).

Yup, while the virtual filesystem allows the creation of real files (e.g., XMP sidecars), I haven't yet implemented any preservation of those files after unmounting.  Dragging/copying the XMP files out of the virtual filesystem should work fine.

What controls the naming of the (virtual) DNGs and WAVs?

The naming scheme, which is the same as on the FUSE versions, can certainly be changed.  I presume you want the filename of the MLV video prepended to the individual DNG files and WAV file?

This is pretty cool, can the RAW files somehow be added to work with this. Or is it only possible with MLV?

I don't think there's any limitation precluding implementing RAW support, although the lack of metadata is a little annoying.  However, I myself am more interested in making sure we fully support MLV files rather than worrying about the "older" format.  I encourage any interested developers to contribute to the code, of course!

thanks a lot for your work but the download link does not work (it says that it found a dead link). Could you please fix this.

Thanks for letting me know!  Looks like Bitbucket got a little confused, so I've re-uploaded it.

MLVFS for Windows using PFM now extracts audio as well (DLL download).  Let me know if you encounter any bugs!

The DNG writing code for white balance needs work, because it doesn't have model-specific or preset-specific white-balance multipliers.  Perhaps you should create an issue on Bitbucket!

Using pismo, I am getting no wav files in the virtual folders.

Yup, I haven't implemented audio yet, but it shouldn't be too difficult since it's up and running on the FUSE side.

Also, the folders are read-only by default, so I have to right-click them and make them writable in order to import the virtual DNGs into After Effects.

Hmm, the folder itself should already be writable, but I guess After Effects really wants the DNGs to be writable.  Be careful when making the DNGs writable; things could break in weird and fantastic ways because I didn't protect all of the possible calls (on the presumption that the DNGs were read-only).

I'm happy to announce that I've gotten an analogous implementation of MLVFS running on Windows using Pismo File Mount Audit Package.  After installing PFMAP, download the MLV formatter DLL from Bitbucket (https://bitbucket.org/dmilligan/mlvfs/downloads/mlvfs.dll) and then register it with PFMAP by entering on a command prompt:

Code Select Expand


pfm register mlvfs.dll

You can then mount any individual MLV video by right-clicking on it and selecting "Quick Mount", which will turn that video into a virtual folder containing the virtual DNGs.  The virtual folder also has support for creating and modifying additional files (e.g., XMP sidecar files), but the files are not preserved when the video is unmounted.

It's far better than the workaround with the Linux VM, but I don't know if it's better than g3gg0's WebDAV approach because I haven't tried it. 

- when ML crashes, sometimes the module symbol completely disappears from the menu. I can't even pick raw video.

After powering up following crashes that require a battery pull, a message should pop up for a bit that says, "Camera was not shut down cleanly.  Skipping module loading."  In other worse, modules are disabled until you have a clean shutdown.  Think of it as a safe mode in case a bad module is causing the camera to lock up.

And the weirdest of all:

- when pressing rec and shooting MLV raw, all the screen infos disappear and the only thing that is left on screen is a little camera indicating the time elapsed

This is normal behavior when "Global Draw" is turned off in the MLV options, as is the case by default.  Note that this "Global Draw" setting is different from the "Global Draw" setting on the Overlay tab because it dictates what happens specifically during recording.

Instead, you'd probably have to use more traditional methods of sharing the MLVFS mount point: share the folder over a network as if they were two separate computers (e.g., using SMB).

Oof, it's not for the faint of heart, but I've figured out how to get this approach working for Windows users.  You have to jump through a couple of extra hoops, and I'm sure performance will suffer because of the layers.

In the Linux VM:

• Make sure that the Linux VM is networked with the Windows host
• Configure Samba to share the local folder that will be used as the MLVFS mount point
• Configure FUSE to allow other users (namely smbd) to use your mount points by editing "/etc/fuse.conf" (requires sudo) and uncommenting the line "user_allow_other" (and also make sure that fuse.conf is world-readable)
• Run the MLVFS mount command with the additional command-line option "-o allow_other", e.g.:

Code Select Expand

mlvfs <mount point> --mlv_dir=<directory with MLV files> -o allow_other

In the Windows host, connect to the shared folder, e.g.,

Code Select Expand

\\<Linux hostname>\<mount point share>

Praying this gets ported to Windows somehow. 

I'm still looking into using Pismo File Mount to provide native support for Windows, because the above is painful.

MLVFS works fine in a virtual machine, but just within that virtual machine's local filesystem.  The way that VirtualBox and Parallels (at least) provide support for shared folders, they are local folders in the host machine, and thus MLVFS can't create its virtual filesystem there.

Instead, you'd probably have to use more traditional methods of sharing the MLVFS mount point: share the folder over a network as if they were two separate computers (e.g., using SMB).

I'm confused: the 50D doesn't record MVI?  Do you mean MOV or MLV?  I'm guessing MOV?

"2.3.NEXT" is not a useful version number; for a long time, all of the nightly builds had that same string.  Do you know what date is attached to the build?  Given the icons and fonts, it looks to be at least a year old.  I recommend upgrading to a recent nightly build.

- Drag the dual iso dng folders to my desktop, then give the folder read, write permissions
- Convert the files using cr2hdr20bit as usual. Original dng files are being overwritten to the converted one.

Ah, okay.  To be clear, when you drag the folders to your desktop, you are converting the virtual DNGs to actual DNGs.

Question. How do you explain acr being able to store write changes directly to dng files in the original fuse folder but not in after effects which needs permissions? Is acr overriding the write, read permission structure?

When you use ACR on files in a read-only directory (e.g., on a CD), it can't create the sidecar XMP files (which is also its fallback for read-only DNG files), so the changes are instead stored in a central Camera Raw database.  That's how ACR can work with the (current) read-only nature of the MLVFS filesystem.

I don't know how files are distinguished in the Camera Raw database, so it's possible you may lose your ACR modifications if you mounted the MLV file in a different location.  Certainly, the ACR modifications would not persist if you mounted the MLV file on a different computer.

Cool! When I right click a dual iso movie file I can give the file read and right priviligies and the files can convert fine with cr2hdr20 bit and also open in after effects.

It's easy enough to understand why After Effects complains; the virtual filesystem is configured to not have write permission, and you work around that.  What I don't understand is your statement about being able to convert with cr2hdr.  The filesystem doesn't have any actual implementation of the write call.  So, what exactly happens when you run cr2hdr?  Where do the converted DNGs go?  I don't have a dual-ISO video to try this out myself.

[magiclantern-Nightly.2014Sep01.6D113.zip]

The most recent nightly build for the 6D is merely a week old (magiclantern-Nightly.2014Sep01.6D113.zip).  You've previously made a similarly perplexing post, which suggests you are mistaken about where to download nightly builds.  As always, you should go here: http://builds.magiclantern.fm/#/

It's about whether RAWMagic can be labeled a "wrapper" and whether the ML tool can be considered part of the core functionality of RAWMagic.  For example, if vertical-stripe correction is used by the majority of the RAWMagic user base, that can be contributing evidence that the ML tool is effectively core functionality, even if it is not necessarily implemented that way.

All parties here are unlikely to ever agree on whether or not RAWMagic is, in its current form, is compliant with GPL, and I suspect that Thomas Worth has a defensible position (not counting the clear GPL violation of earlier versions).  If the stakes were higher, this would be adjudicated in a legal system, and even then the parties would likely not agree on the outcome.

Again, I like the approach of simply declaring that this forum will only allow threads for GPL apps.

I had to mount using full path names, not with ~ in the mlv_argument. It didn't give an error when mounting, but the mount dir could not be opened.

Paths now have typical shell expansion (e.g., ~), and there is error handling for bad paths.  I'll let dmilligan update the binaries for those who can't compile.

I've had to wade through licenses on other projects, and the "viral" nature of GPL always leads to furious debate.  Here are my comments:

Looks like a GUI wrapper over a command-line GPL program must also be GPL:

Both fortunately and unfortunately, that's not automatically the case, and the links you cite also show that.  It depends on many factors, including how the wrapper and the GPL program communicate.  FSF's GPL FAQ on this issue acknowledges that the murkiness has to be resolved on a case-by-case basis based on the mechanism and semantics of communication.  There is a space for non-GPL programs to call GPL binaries and still be compliant with GPL.

Even if wrappers automatically had to be GPL-ed, I have to agree with Thomas Worth that it seems inaccurate to characterize RAWMagic as a wrapper.  I don't know what the distribution of RAWMagic users, but it seems like there could reasonably be a significant fraction of the user base has no need for the vertical-stripes correction.

point is
a) you used GPL code in some of your versions
b) you sold them without releasing GPL'ed source
...
the OLD versions still are not GPLed! and this means: you are still ignoring GPL.

This is a clear violation of GPL, and something that Thomas Worth must address and remedy.  Unlike the above debate, direct integration of GPL code triggers GPL protections.  You can't get around this.

Therefore, I suggest enforcing GPL compliance on all the postprocessing apps based on ML command-line tools.

Authors who do not respect the license will have their threads locked. If no corrective action is done within 1 month, their threads will be deleted.

Again, it's possible for non-GPL postprocessing apps to use ML tools while still being compliant with GPL, depending on the nature of the communication.  However, reasonable people can disagree about where that line gets drawn.  So, instead of dealing with the recurring debates over GPL compliance, simply only allow threads on this forum for GPL apps.  Thus, unless Thomas Worth distributes RAWMagic under GPL, its forum thread will be locked/deleted regardless of the app's compliance with GPL.

Turn on exposure override under the exposure tab

Actually, more useful would be if you save a copy of the old IDX file instead of deleting it.  If re-creating the IDX file fixes your issue, send me both the old and new IDX files.  Thanks!

[mlv_play]

But latest nightly wouldn't play .mlv files that were recorded before I updated to latest nightly. raw files played fine though.
Nothing to do with raw_twk though, it was not loaded when I started playing the files and noticed that the mlv files would not play, just mentioning.

Can you try manually deleting the associated IDX file and letting mlv_play re-create it?  I adjusted the IDX format recently, but the change should only affect "exact" playback.  And even then, playback should still work.  But, perhaps some bug slipped past my testing.

It's not currently possible in ML to discriminate between those two buttons (i.e., they send the same event).  See the following thread (it's about silent pictures, but the cause is the same):

http://www.magiclantern.fm/forum/index.php?topic=10740.0

Pismo is crossplatform (mac,linux, win): http://www.pismotechnic.com/
Can it be used as an alternative to fuse?

(It was used for a virtual filesystem for Avisynth: http://www.turtlewar.org/avfs/)

Interesting!  It looks Pismo's file mounting may actually be only for Windows, but it's not a problem to have platform-specific code.  I'll definitely look into this.

Edit: Okay, there is cross-platform support for Pismo, but it may still be preferable to stick with fuse for OS X and Linux.

Alternatively, it hasn't been explicitly stated, but the MLVFS proof of concept works on Linux as well.  You'll have to grab the MLVFS code and compile your own executable, but you probably already have fuse installed.  I imagine one could configure a Linux VM in such a way as to achieve Windows support.

Perhaps try first copying over the CR2 files to your home directory on OS X (e.g., using a card reader) before trying to work with them.  I know I've encountered issues in a past with Lightroom on OS X properly reading CR2 files that were stored on a separate Windows partition.  I suspected some filesystem miscommunication.

Actually, I think there may some issue with the benchmark code, at least on the 50D.  The last time I ran it, a while ago now, it was unstable, and I didn't investigate it further then.

Don't worry about whatever the benchmark reports as long as you're getting the max rate (~70 MB/s) when actually recording.  The buffer filling up fast in crop mode is just a consequence of exceeding that record rate.

Yes, without exposure override enabled I can't change the aperture at all even in standby. With exposure override enabled I can adjust the aperture while in standby but not while recording in either H264 or RAW. In the stable build (and TL) I'm able to adjust the aperture but it does result in a brief pause in the video while doing so but still nice to have the ability to for any emergency adjustments needed. Camera is in 'M' mode.

I'll look into it, but it might have been changed for a good reason.  You may also want to create an issue on Bitbucket.

On a side note I've also just noticed that in this nightly I'm using the blue LED doesn't turn off when you stop recording in RAW!

Known issue