Messages

Hi!  I'm glad you enjoyed using ML.

Nobody is working on the 800D.  No dev has this camera.  There is no code for 800D for you to build.

To work with ML code you'll need to learn C.

Do you get an error when you try to use Walter's discord link?

Regarding the camera - do you have the same touchscreen problems when there is no card in the camera?

EDIT: I can see you've joined Discord - you need to follow the instructions in the Rules channel to see other channels (and to be able to post messages).

Do you get an error?  If so, what is it?

Level of access is not the problem (well, more would help, of course).  The problem is nobody is working on this feature, so if you want it improved, you'll likely have to learn how to do it yourself.  I can teach you if you want to learn.

STM lenses may work better.  These report more reliable focus information.

I bought the card，so called benchmarks will work,speed is good,but in real shooting,it will stop in a few minutes of raw video recording.This so called Benchmark way of testing cards is misleading.

Multiple other people have this card working in a real cam, including the M, for long shots.  Not just benchmarks.

If you had said "I couldn't get this card working reliably in my cam" - that would be fine.

Saying this card doesn't work for long videos in *general*, is not true.

wonder if Camera has a cache or something that is taking time to clear.

No, it doesn't.  And yes, you only need to run the FIR once to enable the bootflag on cam.

Yup - this is not a feature that ML devs think is practical to add to the 5D2.  May not even be possible, depends on the camera internals.  Since it doesn't have an articulated screen, a monitor from HDMI is useful anyway, lots of people do that.

Hey, nice, congratulations!  It should be much easier to diagnose problems and extend functionality now you have a working boot process!  Shame I don't have an XF605 to test with

Is the code available?  I'd like to compare the process, especially against our early support for Digic X cams, which seemed to share many features.  We have some significant problems remaining there, I'd be happy to take any improvements you've made.

Notes for ML devs: the XF605 is unique amongst cams I've examined, in that almost the entire ROM is copied to RAM before use.  So you can modify code very extensively, with no special effort!  Possibly this is a Digic DV thing, they might have a lot more ram spare?  Or perhaps they have RAM much faster than ROM, so it's a worthwhile step for perf.

Thank you for doing the debugging dance, Walter.  I'll edit the first post to make it clearer it's HDMI out 30 min timer only.

As described in the post you're replying to, it does work in raw.

The answer was found on Discord - it doesn't work on 5x crop, but this is a Canon thing not an ML thing.

Of course everyone with a Digic 4 cam would like the ability to overclock SD.  And all devs already know this

We need more devs, and the devs we do have need more time, not more motivation.

I see.  In that case, would it make more sense to define an address for the bootloader somewhere in platform/cam dirs?  That way, you wouldn't need a special case for 1300D (which is hard to understand), and instead would have something like this:

Code Select Expand


    for (uint32_t i = BOOTLOADER_BASE_ADDR;
         i < BOOTLOADER_BASE_ADDR + 0x1fff0;
         i += 4 )


I meant the search range change, here:

Code Select Expand


    #if defined(CONFIG_1300D)
    for (uint32_t i = 0xFE000000; i < 0xFF000000; i += 4 )
    #else
    for (uint32_t i = 0xFFFE0000; i < 0xFFFFFFF0; i += 4 )
    #endif


And here:

Code Select Expand


         #if defined(CONFIG_1300D)
                if (func_addr > 0xFE000000)
          #else
            if (func_addr > 0xFFFE0000)
           #endif


I have no way of knowing why these changes are required.

Thanks. I'm having trouble understanding these changes.  You're searching a different range, but there's no comment explaining why.  Did the bootloader move?  How should 2000D / 4000D devs know if or why these changes are required on their cams?

(Also you've mixed tabs and spaces so the formatting is kind of messed up)

[Bonus update week, late Aug / early Sept]

Bonus update week, late Aug / early Sept
I decided to clean up the code before pushing builds for testing.  I've been annoyed forever that the build has a large number of compiler warnings.  I've spent a lot of time previously reducing this number (targeting new cams, we saw many warnings related to the new cams disabling most features, these build configurations hadn't been tested before).

Took about a week, but I've now removed all warnings from builds.  Some of them were definitely bugs.  Some were quite hard to fix.  Some have been in the code for over 10 years.  On the plus side I got to use an anonymous union for the first time.

In the background I updated my dev machine, so now I'm building with arm-none-eabi-gcc 12.2.1.  This is a much more recent gcc than official builds use, and makes builds smaller.  I've also enabled slightly more aggressive warning flags in the build.

I've added a make flag that enables -Werror, so you can do e.g. this:

Code Select Expand

make FATAL_WARNINGS=y zip
There is now no excuse for adding code that introduces new warnings.  I need to get feedback from other devs using different environments / compilers, but at some point I expect to make -Werror the default.  Any devs reading this - if you can test to see if you get any build warnings, that would be useful!

Code with all the fixes is here:
https://github.com/reticulatedpines/magiclantern_simplified/commit/8934ac40ce1e004032a3187e02178f0852081875

Oh yeah, I made modules autoload, too.  If a module depends on an export from another module, when enabling the first module, the second will also be enabled (still requires reboot for the modules to load).  Sadly, this is less useful than expected: the few modules that do depend on others have the required symbols provided by *multiple other modules*, with no sensible way to choose between them.  So I made the code only auto-enable if it's unambiguous...  which is currently never the case.

I don't think we want multiple modules to provide the same symbol.  This is confusing and in the current form has led to code duplication.  Probably we want to split out the symbol into a separate binary and have everything that needs it, load that.

Sounds interesting - what's the code change?  I don't see any updates to the repo (makes it hard to apply to other cams )

Trying to find the specific code for rendering that one graph is likely to take more than a weekend   But it is fun if you're in the mood for it.

Human perception of brightness is a weighted sum of red, green and blue components, pretty much.  So that makes sense.

The initial post wasn't confusing, it just doesn't ask anything.  Hence, I was trying to confirm what you wanted to know.

More important was *why* you wanted to know this, because that informs *what you actually want to know*.  People are on average quite bad at asking questions and often don't ask in the right way to get the answer they want.

If the real reason truly is just because you're curious what Canon use, then there's only one way to answer the question: check the code to find out what they do.  You don't want to do anything with this information once you have it?  It's hard to imagine that you really care that much about this particular histogram.  If they're approximating it in order to be fast, they won't use the approximation for anything important, so it doesn't matter.

Maybe not by Canon itself, but for example for computer graphics, there are pages describing efficient algorithms for various things using only integer arithmetic.

Why do you want this?

In fact, can I get some more detail on what you want to find out, and why?  You don't actually ask a question in your first post.  The closest you get is "I wondered what the luminance/brightness histogram of Canon cameras actually show" - for this, you'll need to check the rom code.

Do you want any somewhat fast alg?  Do you want Canon's exact alg?  Why?

Documentation of how Canon implements it?  None that I know of, but I haven't looked at all.

Okay, so it's not busy before it sleeps, or during.

I tested 70D waking from sleep by holding full shutter until it took a pic, then immediately entering ML menu.  Dual ISO menu options were present.  Didn't time it, but less than 2s.

The time until the module becomes available seems to vary, though, might be related to how "busy" the camera is with taking and storing photos, bu that is a wild guess of mine. Haven't had that much time to do thorough tests.

Sounds strange.  How could it be busy with taking or storing photos, if it was asleep?  Are you doing something unusual before or after it goes to sleep?

Works fine on 70D.  I can't think of many reasons why you'd see this behaviour, one possible is if you have multiple modules enabled and one is slow to initialise.

Do you see the problem if you:
- disable all modules
- enable only dual_iso
- restart cam
- wait for cam to sleep and test as before

Assuming that works okay, enable other modules *one at a time*, and re-test each time.  This should let you find which other module is causing the problem.

If you really want to know, you'll probably have to dig around in the rom code to find out.

It makes sense to me that it could be an artifact of integer maths; these cams don't have hardware for floating point.

Walter regularly helps me with programming, otherwise how would I know how features should work, or what cams have them?

Fast preview looks good!  Haven't looked at the code but it doesn't sound like it should be too hard to integrate into any other repo, or make it work on more than the 5d3.  You might be able to get around the large single alloc problem by segmenting it.  Try say, 6 x 256kB allocs.  You'd need to segment the LUT too, and do perhaps some bitmasking ops to quickly determine which segment to use.  Only benchmarks can tell if this is worthwhile

Re my opinion on "where", see my recent post: https://www.magiclantern.fm/forum/index.php?topic=26814.msg244762;topicseen#msg244762

My repo now has crop_rec_4k_mlv_snd code (and, unlike other crop_rec_4k_mlv_snd forks, has all the *other* code, too).  I'd like to start bringing in code from other popular repos, so we can have a single place to work from again.  I've fixed a significant number of bugs (especially in the module system) and improved build time performance greatly.  It builds easily on modern systems, with modern compilers etc (this makes the ML binary smaller as an additional bonus).

I can't make people use it, but I think most people would like to have a single repo that's useful for everyone, and I'm willing to put in the work to merge code.