MLVFS - a FUSE based, "on the fly" MLV to CDNG converter

[DeafEyeJedi]

Okay no problem! I'll see what I can do over the weekend and will do the best I can.

FYI - I managed to get MLVFS to finally work again on my 2006 MBP by updating the Fuse to the latest and all is fine and dandy -- so please disregard this particular issue!

Thanks for your time, David!

[kgv5]

I anyone of windows users who recently installed PFMap from the link on the first page have problems with MLVFS and importing files to premiere - pay attention on PFMap build - now is 177, i had some serious problems with it (couldnt import to premiere) and figured out that older build 171 is the one to go. Seems that 177 has some changes and because of that it wasn't working for me.

[ayshih]

Good to know!  I still haven't been able to put back real time into MLVFS again, but it looks like there have been quite a few recent changes to Pismo File Mount.  Here is the link to build 171:

http://www.pismotechnic.com/download/archive/pfmap-171-win.exe

[dmilligan]

updated the download link in the OP with that one

[mothaibaphoto]

Hi, Dmilligan, I'm a mlv_dump long time user. Some feedback on my attempt to try MLVFS under windows with pismo(1.7.1) driver with ACR and AE.
1. It works, fast and flawlessly.
2. WB temp "as shot" always 2550, mlv_dump produces dng sequence with correct WB from camera.
3. I find no way to use command line options.
4. DLL file seems not updated from october 2014. Both mlv_dump and cr2hdr has updates/bug fixes since then.
5. Something wrong with MLVFS CDNG files format itself - Capture One, for example, didn't recognize it. DNG from mlv_dump and CDNG from raw2cdng are OK, but CDNG from MLVFS - not.

[Danne]

Curious.
Are you sure mlv_dump is translating to correct wb to as shot neutral values? The mac binary doesn, t seem to at least from what I can see.

[mothaibaphoto]

Yes, mlv_dump generates DNGs which looks absolutely the same as CR2 if I shot the same scene with same camera settings. Actually, wrong WB is not a big problem.

[Danne]

Oh, gotta check for mac. Actually I personally prefer to nail wb before actually shooting. Saves a lot time.

[ayshih]

@mothaibaphoto I wrote the PFM version of MLVFS, and as you've already noted, it is out of date because I took a long personal break from development.  I hope to fix it up with @dmilligan's improvements, but it will take some time.

2. WB temp "as shot" always 2550, mlv_dump produces dng sequence with correct WB from camera.

Good to know.  What camera?  And are you shooting normal images or dual-ISO images?

3. I find no way to use command line options.

Given how the PFM version works – mounting a specific MLV file in Explorer, typically via the right-click menu – it's non-obvious what the best approach is to feed in options.  I'm open to suggestions!

[mothaibaphoto]

Hi, ayshih!!! It's so great that you have plans to update MLVFS on windows! It seems MLVFS becomes very popular among Mac and Linux users, and its simplicity tempting us, windows users.

Good to know.  What camera?  And are you shooting normal images or dual-ISO images?

5D MarkIII, normal video

it's non-obvious what the best approach is to feed in options.  I'm open to suggestions!

It could be some predefined ini-file in folder with *.MLV files. When any MLV file mounts, DLL looks for parameters in this file in same folder. Ideally, this file could contain path to *.Mxx files. This makes possible not to copy files from cards to one folder first when shoot in spanned mode.

[dmilligan]

mlv_dump does not write correct WB in DNG files. It uses a hard coded AsShotNeutral for Daylight (5500). There is a PR of mine to replace the old CHDK DNG writing code in mlv_dump with the DNG code I wrote for MLVFS that does handle WB correctly (with some kelvin to RGB multipliers code from UFRAW). Are you using that version or something? Otherwise I don't see how you're getting correct WB from mlv_dump unless you always shoot in daylight and never noticed it was wrong for other lighting situations.

[mothaibaphoto]

Sorry, dmilligan and everyone confused with my wrong sentences about mlv_dump. It really use 5500 K Temp. I didn't notice it, i prefer to shoot in good light indeed Just checked again with file shot at 4500 K in camera:
MLRawViewer 1.4.3 - 5500 K
mlv_dump (last one, by the way, how to check its version?) - 5500 K
raw2cdng.1.6.5 - 4500 K (wow, the winner !!!)
mlvfs.dll 0.4.0.0. - 2500 K
Maybe the obsolete dll is the only problem?
And, please, pay attention: MLVFS output file - the only not recognised by Capture One.

[morrisonmike]

Sorry, I'm new to Linux. Can you give me the command line entries for this?

"Install FUSE via the normal way for your distribution (it may already be included)
Download the code with git and compile using make"

I get the following error:

mike@GP532UC-ABA:~/mlvfs/mlvfs$ make
gcc -Wall -std=gnu99 -D_FILE_OFFSET_BITS=64 main.c dng.o index.o wav.o stripes.o cs.o amaze_demosaic_RT.o hdr.o histogram.o mongoose/mongoose.o webgui.o resource_manager.o lj92.o gif.o LZMA/7zAlloc.o LZMA/7zBuf.o LZMA/7zBuf2.o LZMA/7zCrc.o LZMA/7zCrcOpt.o LZMA/7zDec.o LZMA/7zFile.o LZMA/7zIn.o LZMA/7zStream.o LZMA/Alloc.o LZMA/Bcj2.o LZMA/Bra.o LZMA/Bra86.o LZMA/BraIA64.o LZMA/CpuArch.o LZMA/Delta.o LZMA/LzFind.o LZMA/Lzma2Dec.o LZMA/Lzma2Enc.o LZMA/Lzma86Dec.o LZMA/Lzma86Enc.o LZMA/LzmaDec.o LZMA/LzmaEnc.o LZMA/LzmaLib.o LZMA/Ppmd7.o LZMA/Ppmd7Dec.o LZMA/Ppmd7Enc.o LZMA/Sha256.o LZMA/Xz.o LZMA/XzCrc64.o -pthread -lfuse -lm -o mlvfs
main.c:33:18: fatal error: fuse.h: No such file or directory
 #include <fuse.h>

[Licaon_Kter]

Use your distro packaging tools to find what package provides fuse.h, some thing like libfuse-dev  on Debian.

[morrisonmike]

Thanks, but "Use your distro packaging tools to find what package provides fuse.h, some thing like libfuse-dev  on Debian" doesn’t mean anything to me... Isn't there just some commands I can cut-n-paste into the command prompt?
-MM

[Walter Schulz]

No, because without telling which distribution you are using we can't tell.
Google
install fuse <insert name of your Linux distribution>

[dmilligan]

assuming you are using a debian flavored distribution (like ubuntu) something like

Code: [Select]

sudo apt-get install libfuse-dev


[morrisonmike]

Thanks everyone. I'm up and running now.

[DeafEyeJedi]

Just tried running MLVFS this morning on a test run and it randomly disappeared from my services list on MBP running Yosemite.

I should note that this happened after I tried to create a shortcut button for MLVFS -- could this be the culprit? (though I turned it off and it still doesn't show up on the services list after right click) and I also notice now it just opens Automator every time I want to reinstall MLVFS -- I must have pushed some buttons somewhere not realizing it within Automator?

How do I fix this and make it install and overwrite it as well as running MLVFS like normal again?

However, it still shows under settings preferences. See attachments below.



Anyone else out see a similar situation? I've also tried uninstalling/reinstalling both MLVFS and FUSE to no avail.

[dmilligan]

You have to right click on a folder. You can only mount folders, not individual files.

[DeafEyeJedi]

Actually I apologize for the false alarm this morning. Must have been either really tired or a bit hangover from being in the post world for quite a bit!

FYI regarding previous post that I've noticed MLVFS hasn't disappeared or any problems when rendering overnight as of lately is most likely due to the fact that I had updated to the latest FUSE.

Also is it a good idea to use their beta version of FUSE or best to stick with non-beta's?

Thanks again, @dmilligan!

[benyonker]

I just found this a few days ago, and I've been using it re-process some MLVs that were full of bad pixels. The "bad pixel fix" feature alone is going to save me hours of post on this music video, so thank you!! I have two questions that I haven't been able to find in the forums:

• First, when I use MLVFS, the resulting DNGs are noticeably darker than the DNGs I get out of RAWMagic. I didn't even know that was possible, because I thought a DNG was a DNG (I'm new to shooting RAW, so forgive my ignorance if I'm way off base here). Is there something that either MLVFS or RAWMagic is doing to process these that could affect their levels?
• Second, the DNGs seem to have the wrong date. The year, day, and time are all correct, but the month is one less than it should be. For example, footage that I shot yesterday (7/29/15) is showing up as 2015-06-29. I double-checked the date setting in my camera, and it is correct.

Neither of these is a big deal; I'm obviously color-correcting anyway, and the dates aren't critical. I'm just curious.

Thanks again!

[dmilligan]

1. A DNG is a DNG, the raw data is going to be the same between the two. "Darker" is just a result of how the raw development application (ACR, Pemiere, DaVinci, etc.) chooses to treat the file (you can't actually 'see' true raw data or levels, it must be processed, demosaiced, white balanced, and converted to some real colorspace to display on your monitor for you to even view it, there are going to be arbitrarily chosen default values for parameters used in these processes).

Simply increase the exposure in your post processing app and they will look exactly the same. The difference is likely due to some different metatdata in the DNG that causes the raw development program to interpret the raw data differently by default. There is a DNG metadata field for 'exposure offset' or 'exposure' or something like that. There have been a lot of people who complain about the DNGs not matching the camera's LCD screen and 'appearing darker'  (this complaint is sort of silly for the reason given above), my guess is that RAWMagic developer utilized this field to make the DNGs appear brighter to match the LCD screen (to appease his paying customers). If you'd like to find out for sure, try comparing the metadata between the two with exiftool.

2. The struct tm has a field tm_mon, on some systems this is [0,11] on others it is [1,12]. That is probably the issue.

[benyonker]

Thank you for the quick reply. Your answer to #1 makes perfect sense. I agree that the complaint is sort of silly given your explanation. As for #2, I don't even know what to make of that or how I can alter the tm_mon field. I'm on a Mac. Is this something I would have to do in Xcode? Terminal?

One final question: I shot this footage at 29.97, but I want it to play back at 23.98. In the MLVFS window, I see an option to override the framerate. When I change it to 23.98 (or 23.976), PPro interprets the footage to be 23.000fps. If I use 24 in MLVFS, PPro interprets it at 24. That could work, but I'd still rather have it be 23.98. Am I better off leaving it at 0 and doing Interpret Footage in PPro? Will that cause issues in Resolve?

Thanks so much, and again I apologize if these are basic questions.

**Correction to above: Resolve sees the footage as 23.98. When I render proxies, PPro also sees them as 23.98. Looks like we're OK here; just a glitch with the way PPro sees the original DNGs.**

[dmilligan]

For the month stuff, I will have to look at the code and fix it