Messages

Yes it's easy to get rid of the error message, but the message is not the problem, it was intentionally put there to highlight the underlying bug and encourage someone to fix it.

http://www.magiclantern.fm/forum/index.php?topic=19761.msg186060#msg186060

Is the value of frame_headers->rawi_hdr.yRes different?

Yes. The xRes and yRes are the recorded resolution (user selectable). The raw_info stuff is constant per video mode, and has nothing to do with the actual recorded resolution.

MLVFS does not check the recorded resolution, it checks the resolution of the video mode (in raw_info struct) only way for this to be wrong is if one can adjust the line skipping parameters for the video mode such as in the crop_rec and 4K branch. That is why there was new metadata added in these branches for precise specification of crop and resolution parameters: http://www.magiclantern.fm/forum/index.php?topic=17021.msg181639;topicseen#msg181639

I did reply in the other thread

It's very unlikely the browser, the MLVFS webgui only uses super basic and very standard HTML and JS stuff. Probably the problem is either you didn't start MLVFS from the correct directory (the one with the webgui support files) or you need to use the -f switch to force foreground mode (on *nix OSs this is necessary, not sure how dokany/Windows works).

This should be all you need to do to compile on ubuntu (not tested)

Code Select Expand


sudo apt-get install libfuse-dev
sudo apt-get install git
cd ~/
git clone https://bitbucket.org/dmilligan/mlvfs
cd mlvfs/mlvfs
make


It should compile from Visual Studio. You'll probably need the dev libraries for dokany installed.

You probably had trouble finding it b/c you are on a Mac right? Most Mac keyboards lack a dedicated forward delete key. Try: Fn + Delete

[was]

There was a bug discovered that occurs with extremely low probability when writing to or reading from files. The message you see is warning about places in the code where this bug needs a proper fix (there is currently a stop-gap measure in place, a proper fix will be a lot of work).

So there actually was a problem with the old version, it was just unknown. Now at least there's a warning.

See:
http://www.magiclantern.fm/forum/index.php?topic=19761.msg186060#msg186060

https://en.wikipedia.org/wiki/Mebibyte

Good catch - the build system was not smart enough to remove it when running "make clean"...

make clean for modules pretty much never works because of this (in modules/Makefile):

Code Select Expand


MODULES_CLEAN_ALL_TARGETS = $(call targets_rules, $(shell ls -d */), clean)


The rule tries to run clean on every directory it finds in the modules folder, regardless of whether or not that folder actually has a makefile in it. As soon as you get to a folder without a makefile, the whole things errors out and nothing after that folder gets cleaned. This is a huge problem when switching branches with different modules in them, since the version control will delete the makefile when switching branches, but none of the build files or the directory.

A long time ago, I made a patch that prevented this rule from failing, by only trying clean on directories that had makefiles inside them, but this still doesn't fix the issue of switching branches leaving behind build files, but no makefile that tells how to delete them.

So for a complete solution, I would recommend changing the module build system to work something like this: have all modules create all their build files in a subdirectory (e.g. bin/). Then have the modules/Makefile, clean by simply deleting all modules/*/bin/ directories it finds, rather than relying on calling the module's makefile (which might not be present). Of course this would be a rather sweeping change to module build system and require touch a lot of files.

Putting build files in a subdirectory would have the added benefit of avoiding all the clutter in the modules' source directories which can make it hard to find the actual source files when browsing to them.

Doubt I'll have time to do it myself, but it would be a good easy coding task.

That means MLVFS probably crashed for some reason. Check for logs in ~/Library/Logs/DiagnosticReports and ~/.mlvfs.log

Nice work @dfort!

Higher ISO is noiser

Sounds like you didn't read the link a1ex posted in the previous response.

It's totally virtual and the size doesn't matter.

http://www.catb.org/esr/faqs/smart-questions.html#beprecise

Turn off long exposure noise reduction in the Canon menu.

[exactly]

I think you have a misunderstanding about what lossless JPEG means.

"Lossless" compression algorithms compress data in such a way that the original data can be reconstructed exactly, bit for bit. "Lossy" compression algorithms compress data in such a way that the original data cannot be recontructed exactly, but you can come close and the differences are optimized to be things that aren't very noticeable based on human perception. They are two very different beasts.

JPEG is not a file format nor is it a particular compression algorithm or codec. It is a group of people who design compression algorithms and standards. It's a bit confusing that this group of people gave their name "JPEG" to a particular lossy compression algorithm they standardized. This particular algorithm based on the discrete cosine transform is what most people know as "JPEG". This group has also standardized other compression algorithms, including a "lossless" compression algorithm.

The lossless compression algorithm created by the JPEG people is very different and has nothing to do with the well known lossy JPEG algorithm, other than the being created by the same folks.

The lossless compression algorithm the cameras use to compress CR2 raw data is the lossless JPEG algorithm. That is the compression algorithm referred to in your quote that we recently discovered how to use. It has been implemented to losslessly compress raw video.

I think what you are actually asking about is not lossless JPEG, but the traditional lossy JPEG. There is also a lossy JPEG hardware in the camera (JPCORE), but we don't know how to use it well enough at the moment to implement what you are asking. Search the forum for MJPEG.

Already done -> https://builds.magiclantern.fm/experiments.html

Problem is you need to use an MLV converter that supports the new lossless compression.

Probably you are using some old version before lossless compression support was added.

There are some tutorial videos linked in the first post.

IIRC, if you can't use -P, you loose the vast majority of powerful parts of regex syntax (depending on what you're trying to do, it might not be possible to use grep at all, and so you would need to take on an extra dependency anyway). And I bet that statement about "highly experimental" was put in decades ago and never taken out. These more advanced parts of regular expression syntax are now quite standard.

There's also this: http://jlebar.com/2012/11/28/GNU_grep_is_10x_faster_than_Mac_grep.html

Cool!

There's probably a file selection dialog that came up behind other windows (hide other open windows and you should see it). It's really annoying that Automator does that, but not anything I can do about it.