Messages

It simply seems to be an error of omission within the installation instructions, that can be remedied by adding one or two senteces.

Yes, probably.  I know "just submit a patch" is cliched for open source projects, but you may not be aware that everyone with a forum account gets a wiki account; you can submit the change you want.

Coming from an almost purely open source experience for the last 20 years, it is apparent that a majority of the devs (and almost all of the users) run proprietary OS's and proprietary software.  Any consideration for Linux and the BSD's seem like an afterthought here.

This isn't the impression I get at all, so I'm genuinely curious as to why you do.  I agree about users, but that's to be expected.  I also don't think it's very important what devs run, I'm just curious why you get that impression.  I run Linux and I'm *probably* the most active dev currently?  Alex was linux I think and I'm fairly sure he's the biggest single contributor historically.  The founder was using some linux flavour I believe.

My opinions are somewhere in the middle.  Noobs are always going to ask stupid questions, then after a while they'll learn how to do things sensibly.  But there's always more noobs joining, going through this process.  You will never succeed in making 100% of new joiners read everything before asking questions.  You'll never make docs that everyone finds clear, either.  That said:

I try to give polite answers to questions, in a way that lets people know how to ask it sensibly the next time.  I take this attitude so that the *next* generation of noobs is more likely to do things the sensible way.  I know it won't work 100%, but I hope it will approach the limit over time.  Bear in mind you're not just replying to the questioner, you're also replying to the much larger audience of lurkers.  Giving a positive, helpful impression seems better to me than a negative one.  Yes, it's frustrating answering the same questions every time - but that specific person is asking it for the *first* time, so they don't understand why they're now getting shouted at.  We can do better than that.

I think that replying in a hostile, or grumpy way is *understandable* for people that have been here a long time (or worked with similar attitudes from noobs in different circumstances), but not *helpful*.  It gives a hostile impression about ML forums, discord etc, and is off putting.  I definitely get annoyed sometimes.  Sometimes I even reply when I'm annoyed, although I try to simply wait it out.  It's okay to let someone else answer if you're not in the right mood.

Re the specific question of documentation; we should try to improve it so it makes the most sense to the most people.  It's unfortunate that very early ML docs called ML firmware, and it's unlucky that we use Canon's firmware update *menu* to do something that's not a firmware update; it's pretty obvious why this can cause confusion.  So I'd say the docs want to be extra clear in this part (there have been many changes in this area to improve it).

Re dev attitudes: ML seems fairly normal to me.  Most devs don't really want to answer user questions but know they have to.  There's an unusually wide difference between the technical skills required to make ML and required to use it, and sometimes that causes friction.  I think we could encourage a more polite, welcoming culture and this would make new users happier.  This can be as simple as replacing "You clearly haven't read the FAQ" with "Please read the FAQ and if you have questions after that, just ask", etc.  It's not hard to be polite, and importantly your answer is being read by 99 people that *didn't ask a stupid question*.  Even if you think the noob should have done better (but we were all noobs...), what about the lurkers?  They didn't do anything wrong.

It's interesting that you think most devs use proprietary OS - I'm fairly sure most code was written using Linux.  At some point a lot of work was put in to allow building on Win and Mac but this was a later addition.  Perhaps it enabled another generation of cross-platform devs?  The core devs have normally been Linux users I believe.  It looks like there was a phase with quite a few contributions from a Mac user.  I've only been working with this code for about 3 years so certainly don't know the history very well.

It took me a long time to get round to it, but thanks a lot for the code srsa!  After a lot of ARM manual reading, and working from your examples, I can now remap memory on 200D (and very probably all D78X).



Code will live here when I tidy it up and push: https://github.com/reticulatedpines/magiclantern_simplified/tree/mmu_investigation

EDIT: this commit has a working PoC for 200D, easy to adapt for other cams: https://github.com/reticulatedpines/magiclantern_simplified/commit/2ee5ccd0751d37bd03335f52f23e8673938893b4

That's a great summary, thank you!  We could probably remake an autoexec.bin from that info.

Should we document this better?  I don't really know what went wrong and how it was fixed, but it seems common enough that we should have a proper recovery process.

This is a very low volume forum, so things are slow.  Try not to worry about it.  You only need to get approved once.

People will see your post now (my comment will bump it to the top).

Common ways to demonstrate the problem you're having:
- ML Debug -> Take Screenshot function
- Capture via HDMI out (needs a capture card, of course, which you may not have)
- Video the screen with another cam / phone

I don't think anyone has any plans to even attempt this.

It is not too hard to learn, if you have some programming background.  We can answer a lot of questions on Discord (it's easier there because it's faster).  C is the primary language.

I've done some work to make building ML and building Qemu considerably easier.

Good work!

To clarify, there is a memory region that on some cams, Canon code zeros out if autoexec.bin is selected to run.  On R5, some parts of that region hold data that must be involved with early device setup for peripherals / co-processors.  During a normal boot, the zeroing doesn't happen and everything is okay.  Presumably, when Canon does whatever tests they run using *their* autoexec.bin, they don't try to transfer control back to the cam to finish the normal boot, so everything is okay.  It's only when autoexec.bin gets used, *and* you transfer control back to Canon, that the conflict triggers problems; presumably something is reading the zeros and needs real data instead.

Slightly earlier cams zeroed a region but it was small enough it didn't conflict.  Or, at least, not as badly.  We need to fully confirm this by checking code in other Digic 6, 7, 8 cams.  Perhaps we're lucky and kitor has found the cause of some problems on those cams, too.

Every cam requires additional work.  Yes, 2000D is similar, but it is a different cam and there will be some changes.  Because they're close, it would likely be a fairly easy port.  Somebody still needs to do the work.

Right, so you're comparing two different cameras, two different optical paths.  Using only the resolution numbers isn't going to get you a good answer.  As Walter says, take some calibrated test shots.

Yes, the vertical resolution is real 2160.  Horizontally, it's binned pixels; the light from every 3 pixels is combined in hardware.  Light is captured from a 3840*2160 region, the data produced is 1280*2160, but the pixels are rectangular.  The "stretching" is to undo the assumption by image formats that pixels are square.  Stretched and interpolated are not the same thing.  I believe this is not interpolation, but I haven't checked the code.  There is very little maths involved here.

It is definitely higher resolution than 1920*1080 *in terms of pixels*.  This doesn't tell you if it looks better or worse.  If you want to know that, you must measure it.  There's enough of an MP difference that I'd expect the ML footage to look noticeably better, but that's my guess.

1920*1080 is also a fairly weird raw format.  What cam is it?

What do you mean by "real"?  1280*2160 should have all the light from 3840*2160 because it's binned, and at least as good resolution for detail as 1280*2160 (probably, slightly better angular resolution?  Binning loses you some but you don't need as good a lens etc to have the resolution available over the 3 pixels as you would over 1?).  If you downsample to below 2160 height, you are throwing away resolution.  The *vertical* resolution really is 2x 1080.

So, it should definitely be better than 1920x1080 resolution overall.  That's 2.1MP.  1280*2160 is 2.7MP.  But they're a little odd to compare.  The horizontal and vertical angular resolution aren't the same in 1x3 binned, but the native 1920x1080 is binned anyway and compressed so what are you comparing against?  1920x1080 raw from some different camera?

No, no dedicated place for that.  You will find some people linking to their raw video files if you look around.  They're quite large so they're annoying to host.

Hi   You're replying to a 4 year old thread, you're unlikely to get a response from the poster.

It's free to check how long video processing takes, and only you can define what "too much" is, so I suggest you try it and see.  There are lots of people who can give advice on good workflows if you describe what you're doing (e.g., what resolution video, colour depth, etc etc).

i reset all settings and now works so what was problem?

You've answered your own question.  One of the settings was the problem.  Which setting?  I can't tell you, I don't know what they were.

It's possible for settings to become corrupted.  This can happen with or without ML, due to the way Canon saves them.  If you can find a repeatable way to hit the problem, and if it's due to ML, then we can try to work out the cause and fix it.  If you can't repeat it, there's nothing we can do.

It's more likely that you could capture a "portrait" aspect ratio, and rotate the camera 90 degrees, for the same effect.

Sounds very much like dual ISO isn't supported on that cam, in movie mode.  I'm not sure how the message could be written to be any clearer.

You're unlikely to find someone with the same combination of camera and capture card.

Does it matter if anyone else has seen it?  The problem seems to be the capture card.  I'd recommend trying another one.

This confused me enough that I had to look it up.

The 1300D *does* have a Trash button.  It doesn't have a dedicated Trash button, it shares the same button as AV.

M50 and M50 mk2 are different cams from EOS M.  There is not yet ML for M50 or M50 mk2.

Got some features working (also on 200d).

Shutter count zero appears accurate for 850d:


Benchmarks and screenshots work (not all benchmarks tested):

They work fine for me.  Can you give an example link that doesn't work?  Thanks.

No, there is no real ML for 5D4.  We have a partial version that boots and does some early stuff, but there's still lots of debugging work needed.  No devs have access to 5D4 so don't expect any progress.

You can use imgur.  Upload there, get the raw url for the image, use that inside img tags (remove \, can't get it to display nicely): \[img\]http://[/img]

Bilal, over to you