Messages

That let me find what I assume is the actual source: https://bitbucket.org/xaint/magic-lantern-astro-module/src/master/

It compiled easily for me.  What have you tried?

It's old.  The solution is to rebuild it.  Do you know where the code is?

For the isoless fix, it looks like you're still relying on heap addresses, which can change each boot, or depending on dial settings, etc.

I have a clean fix for 650d isoless, here: https://github.com/reticulatedpines/magiclantern_simplified/tree/650d_isoless_err_fix

I've only tested in Qemu, if you can confirm it works for you on a real cam I'll merge it to dev.

There's a 550d isoless fix that I did earlier, already merged: https://github.com/reticulatedpines/magiclantern_simplified/commit/215c6fa2c15a26855cf69dcb95cae93d56eb5160

Modules can work on multiple cameras, and should safely fail to load if they're not compatible (whether this is *true* depends on the developer and the code...).

The "old API" message is not about Digic generation, but about age of the ML build.  You can probably safely try this module and see if it works.

Walter - my mistake, I thought you were saying this card was UHS-II and UHS-I fallback was making it even slower than the normal slowness.

While it's true it shouldn't crash, it looks very likely the crash is related to exhausting something due to not being able to keep up.  An intermittent crash when trying to do something the camera isn't capable of?  Very low priority to investigate.

If it only crashed once and it's not repeatable, probably nobody is going to investigate this.  Thanks for uploading the logs, now if somebody wants to look at it they can.

The core problem here is that you're trying to record in a mode that requires more speed than your card / cam can provide.  You'll need to use a better card, as Walter suggests, or record in a lower resolution mode.

Cool, glad that works for you.

CFA Plane Color I changed with a hex editor, exiftool doesn't look to support it.

IFD0 is part of the tag hierarchy and according to the docs I read, can be needed if there are multiple sub-fields by the same name.  Is this true?  I don't know.

Thinking about it, if Motion Cam is creating the DNG, rather than an Android API, this is probably their bug.  Could go either way, you could consider raising it with them as a question.

Both BGR and RGB are common data formats, maybe somebody got the metadata wrong, or forgot to swap for whatever the sensor outputs.

Using exiftool on your sample file:

Code Select Expand


$ exiftool rgb_swap_orig.dng |grep CFA
CFA Repeat Pattern Dim          : 2 2
CFA Pattern 2                   : 2 1 1 0
CFA Plane Color                 : Red,Green,Blue
CFA Layout                      : Rectangular
CFA Pattern                     : [Blue,Green][Green,Red]


You can swap the ordering by editing CFA Pattern 2, or CFA Plane Color.  Probably CFA Pattern too, I didn't test that one.

Editing via exiftool:

Code Select Expand


exiftool -IFD0:CFAPattern2="0 1 1 2" rgb_swap.dng


Does this crash always happen if you perform the same sequence of actions?

You can upload the logfile without opening it.  It is just a text file so I don't know why you can't open it.

I think this is yours: https://foss.heptapod.net/magic-lantern/magic-lantern/-/issues/2978

I don't think anyone uses that bug tracker anymore.

The image is a good start, but there's not enough information to attempt to reproduce the problem.  I don't have a 600d and mlv problems won't reproduce in qemu, so I can't really help.

What build are you using?

If there were updates, people would have written them here, so, no.  Nobody is working on the 2000d.  There will never be any updates until someone does.

ML provides many features that aren't raw video.  Focus peaking, audio level monitoring, cropmarks, etc.

I just don't have any experience with it.  So I have as much information as apalazzi, I'd have to read the forum thread and the source to understand what it's supposed to do, which I assume they've already done.  And I don't have a camera to test it on.

I don't think anyone has mentioned it so far: the reported 20MB/s results are what happens when a card fails to overclock.  The cam drops back to a slow, safe default (this is not ML but the cam / card itself).

With this card, you may get higher benchmark results if you disable all overclocking.

If all you're trying to do is shoot 3 bracketed shots, you can probably use the normal Canon menus, no need to use ML functionality.

If you need something more than that, can you tell us what it is?

A mod split this out, so I'll bother giving a longer reply.

I haven't watched the video because it's 13 minutes long.  The small parts I watched were about RED patents on *compressed* raw, which doesn't seem to be very relevant to your stated question.  Can you be more specific about what you're asking here?

Regarding which cameras are worked on, there are many reasons why devs work on the cameras they do.  One is individual motivation: one dev might want to work on the cameras with the least features, because these would benefit more from ML.  Another might want to work on the most expensive, or most features, because these are "cooler".

Another reason: which cameras are the most useful for understanding how all other cameras work.  We understand Digic 4 and 5 well.  We don't understand 6, 7, 8 or X as well.  6 is closer to 5.  In some ways this makes it easier to understand.  So if you want to support all cams, it may make sense to get 6 working, then 7, then 8, etc.  This is a more natural progression.

And so on, there are many possible reasons.  You are assuming everyone wants the same as you: support for the biggest and best cameras.  But we know this isn't true.  After all, the most popular model currently is probably the M, and that's a small, cheap camera, with bad controls.  And even if the devs "should" work on "biggest and best", who's going to make them?  Magic Lantern project has no managers, and everyone is a volunteer.  Magic Lantern project *has no stated goals*.  I think the project would do better with a little direction, but a) that's only my opinion, and b) you could never enforce very much direction and I wouldn't want to: it's an open source project in a very niche area, it's never going to be very organised.

Personally, I want to support all cameras.  I don't expect to succeed on my own, but I enjoy working on it.  Currently there is one other dev, kitor, working on support for modern cams.  We chat and coordinate some things, but mostly just work on what we find enjoyable.  When you think about "the devs": for modern cameras it is two people.  We work part time and we're not being paid.  We work on what we want to at the moment.  Personally, I do consider to some degree what the community seems to want, it's more fun making things that are useful to others.  But I also know much better than the community what is practical *for me* to get working.  Somebody has to do the work.  If the community wants X but I don't know how to do it, X is not happening unless kitor does it.  And generally we have similar ideas about what is easy or hard, because we have a mostly shared understanding of how the cams and the code work.  So, practically, if I can't do X, X is not happening.  Maybe I'll learn how to do it later on.

Regarding old vs new cam support, I have bought, with my own money, a body from Digic 5, 6, 7 and 8 generations, because this helps me understand how the cameras have changed over time, which helps me improve support for *any* camera.  If my goal was only to support 5D4, I would still want at least Digic 5, 6 and 7.  And, very importantly, I want the ML code to be clean, general, and support many different camera generations.  This means understanding what things *are* general, which requires understanding multiple different cams.  If I just tried to hack support for 5D4 into the code, it might be quicker, but it would be much uglier.  At times in the existing code we can see this has happened and it makes work more difficult for us.  This is normal with any complex code base, and tidying things up, improving generality etc are normal maintenance activities.  Maintenance is slow, it is not cool, it is often invisible to users, but without it, everything falls apart.

These questions are nothing to do with 5D4 dev, so I am only going to give a short answer.  If you want a long answer, ask somewhere appropriate

Relevance: relevant to who, for what?  What you want is different from what other people want.

My goal is to make ML work on all cameras, for fun.  The order doesn't matter.  I don't know what your goal is - you're free to work on it.

How are you processing to get these results?  In theory, lossless shouldn't change the data at all, so I'm wondering if this is an mlvapp artifact.

If you can extract the image data via another route that would be a useful comparison.

You're replying to a thread from 2015.  The video probably no longer exists.

I don't know, it's not stable enough to run benchmarks.

I now have a 5D4.

I also have this:




No real features, but shutter count works:

Aww, I was genuinely curious why GPT was seen as beneficial for this use, and now I won't get a sensible answer.

Hi Jamesonn - you're using ChatGPT or similar for some of your answers.  Why are you doing that?

Any chance you're using a micro-SD adapter and have left the adapter in the cam, with no card in it?  If so, remove the adapter and try booting the cam.

Also try removing the lens and reboot the cam.

Reboot for these tests should always be: turn cam off, remove battery, replace battery, turn cam on.