Messages

@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!

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

Can you provide screenshots of what you are seeing in Live View, what your settings are on your Overlay tab, and maybe even what your settings are on your Modified tab?

You asked earlier about setting "Kill Canon GUI" to OFF.  When that is set to OFF, the Canon GUI is not suppressed, and competes with the ML GUI, which is why there is flickering.

For those using the Pismo File Mount version of MLVFS on Windows, I know that it hasn't been updated in eight(!) months, and it's far behind @dmilligan's Mac/Linux version.  I took a very long break from ML or MLVFS development, and I'm starting to get back into it.  I still have to figure out the best way to "catch up", not least of which is figuring out how to implement the equivalent to the webgui.  Let me know if there are specific features that should be the highest priority (e.g., FRSP support).

finder does not show the image correctly

Can you elaborate?

This is super cool =). I've been trying it out on windows with pismo file mount program. Is it possible to control hotpixel fix and stripe removal in windows?

Not yet, no, but the other demands on my attention have largely subsided, so I should be able to spend time on ML/MLVFS again.  Stay tuned!

[dot_tune.mo]

Ah, the 5D3 1.2.3 nightly build isn't quite up to date.  This module was fixed on August 19.  Can you try swapping in the dot_tune.mo file from the 1.1.3 nightly build?

There is supposed to be the capacity to change just one end at the time (merged in August).  Questions:

• Which nightly build are you using?
• Which camera?
• Do you see distinct "AFMA mode" options of "This lens, wide end" and "This lens, tele end"?

But webserver doesn't work under Linux.  (http://localhost:8000)

Sorry, I'm still out of commission with respect to working on ML or MLVFS for at least another week, so I haven't been able to maintain the Linux version.  I encourage you (or others) to try to figure out why it's not working!

Oops.  For Linux, in "mlvfs.h", you need to add an include prior to the include for "raw.h":

Code Select Expand

#include <stdint.h>

Wow, cannot wait to test it    Is the first page download link up to date (for windows)?

I haven't been able to work on the Windows/PFM version lately, so it's fallen a bit behind.  Unfortunately, that's likely to continue to be the case for the next couple of weeks.

It's a good idea to delete all of the ML v2.3 files from your CF card before putting the nightly-build files on there.  Note that no files are ever actually installed on the camera itself, so you don't have to worry about removing or uninstalling anything there.

v2.3 is the stable build, but you'll have to install the nightly build if you to be able to record raw video (and enable modules).

[cr2hdr]

Yes, the converted dual-ISO shots will look qualitatively the same as normal shots taken at the same exposure settings (at the lower ISO).  However, the difference is there when you manipulate the photo in post (e.g., Darktable).  For example, if you increase the exposure, you should see noticeably less noise in the shadows.  This gives you more post-processing latitude, including if you want to apply crazy "HDR" effects.

For Linux, you can build a native version of cr2hdr from the source code, but if running it through Wine works for you, there should be no difference in the output.  Note that you should probably use the 20-bit version (cr2hdr-20bit.exe), which has a bunch of improvements.

I'm not able to look at the images right now, but this is almost certainly a problem with incorrect black levels in the EXIF information of the DNGs.  Unlike most applications, Preview ignores the EXIF black level and instead uses a default value for the particular camera model.  So, while Preview's behavior is generally undesirable, it can happen to skirt a problem when the black level in the file is wrong.

See http://www.magiclantern.fm/forum/index.php?topic=13473.msg130232#msg130232 for how to change the black level in the DNGs (you may need to use a value different from 2048 depending on your camera).

[cr2hdr]

See related discussion.  The white-balance calculation in cr2hdr is apparently being affected by the fact that which lines are at which ISO changes from frame to frame in dual-ISO video (in crop mode?), which is probably changing stuff like black levels.

I've implemented a very experimental dual ISO conversion (I really prefer to think of it more as a preview).

ayshih will need to update the Windows version.

The Windows/PFM version of MLVFS now has the same (experimental) dual ISO support.

@escho: The Makefile had not been updated for compilation on Linux.  Try again now.

The black level is incorrect and needs to be set to 2048, e.g.:

Code Select Expand


exiftool -IFD0:BlackLevel=2048 *.dng

Some applications, like Preview, ignore the black level stored in the EXIF metadata and instead use a presumed value (which happens to be the correct value in this case).

I'm not sure exactly what you are asking, but the 50D doesn't support exFAT.

[cr2hdr]

The AsShotNeutral values in the unprocessed DNGs are the same because they're just default values that don't take into account the actual photo; the white balance is determined in the processing stage by cr2hdr.

I don't have a camera that can do dual-ISO video, so I was surprised to see that the unprocessed DNGs have different brightness patterns: "ddBB RGGB" for 0.dng and "BddB RGGB" for 1.dng.  That is, it looks like the set of lines that are the primary ISO actually switches from frame to frame.  Is this true for all dual-ISO video?  Or is this some consequence of the 5D3 pixel binning?  Whatever the reason, this behavior may be what is causing the white-balance calculations to oscillate.

Heh, at this point, you may want to clean up the initial post since the majority of it is struck through!

It seems that every alternating DNG has a different white balance color despite all of my DNG's being synced to have the exact same white balance.

Then when I opened up the DNGs in Lightroom, despite syncing them all to have the same white balance, each alternating DNG frame has a slightly different white balance.

I presume you actually mean to say that you are syncing them all to have the same levels (i.e. the "--same-levels" option).  That is not the same as syncing the white balance.

That is strange. One is greener than the other. When I look at the exif information I see a difference in asShotNeutral but I have no idea if changing this will help. Tried to but it didn,t seem to make any difference.

I can't look at the DNGs right now, but a white-balance difference is definitely due to the differences in the AsShotNeutral tag, and setting the AsShotNeutral tag to the same values should make the white balance the same in the two DNGs.  So, something may be throwing off the default "graymax" white-balance calculation, although I don't know why it'd occur on alternating frames.  As a guess, are you shooting both dual ISO (alternating ISO between pairs of lines) *and* HDR (alternating ISO every other frame) at the same time?

My guess is a bad black level, and you can also search for ways on this forum to fix that.

If you want better help than just guesses, you need to upload a DNG.

Any discoveries recently that could lead to dual ISO working in 50D and 5D2 video?

Nope.

They open fine in ACR/LR but have no preview, so if I use the --compress option, which enables the .dng to be displayed in preview, it comes out like this-

If you mean OS X Preview, there's a known issue where Preview apparently ignores the EXIF black level if it recognizes the camera model (and presumably uses some default black level), which can lead to color casts like you show.