Messages

Answered here: https://www.magiclantern.fm/forum/index.php?topic=21155.msg194047#msg194047

A fix would be non-trivial, and I prefer not to think too much about it right now.

Confirmed - that's a valid bug report.

Last time I've checked, it used to work:

https://foss.heptapod.net/magic-lantern/magic-lantern/-/blob/branch/lua_fix/scripts/api_test.lua#L785

Code Select Expand


            local apex = math.random(5*100,10*100)/100
            camera.iso.apex = apex


https://codingkilledthecat.wordpress.com/2012/06/26/how-to-ask-for-programming-help/
https://en.wikipedia.org/wiki/Minimal_working_example
http://sscce.org/

Current status: networking functions were documented several years ago, but no such functionality implemented in ML yet.
https://www.magiclantern.fm/forum/index.php?topic=11053.0

Otherwise, the functionality should be doable, but has to be built from scratch - possibly with reusing some existing libraries. No 6D here, so... can't help much.

Answered in reply #1086.

What you describe is probably the arithmetic mean, or maybe some approximation of it (as I don't know how Photoshop works); in any case, it's a linear combination of input images. Median cannot be computed that way, and has very different properties from arithmetic mean. Both of them are measures of central tendency, but that's pretty much where the similarity ends.

https://en.wikipedia.org/wiki/Median
https://en.wikipedia.org/wiki/Arithmetic_mean

https://petapixel.com/2013/05/29/a-look-at-reducing-noise-in-photographs-using-median-blending/
https://blog.keepcoding.ch/?p=2324
https://www.investopedia.com/terms/m/median.asp

[Median]

The median merge function is 'simply' (a+b)/2, that is sum the pixel values and half the result.

That's the arithmetic mean, and it's quite different from median. For example, median is a robust statistic (not affected by outliers, so you can use it for e.g. removing people from the image sequence). Arithmetic mean, on the other hand, "simply" simulates a long exposure, where every single frame contributes to the final image (so, any moving subjects would appear as ghosts).

https://www.mathsisfun.com/data/outliers.html
https://www.cese.nsw.gov.au/effective-practices/using-data-with-confidence-main/outliers

Now, the question is whether the Eeko routines are actually useful to implement this stuff. Short answer: maybe.

Median: to compute it, you need to store all images. This is going to be tricky with full-res images, but an approximation like frugal median might be doable.

Advantages of frugal median (compared to median):
- only one "accumulator" image is required for Frugal-1U (check the paper)
- it might be good enough for practical purposes (not too far from the real median)

Difficult points:
- how to compute the sign of the image difference with Eeko routines?
- may require applying a logarithmic curve before and after processing (can it be HW-accelerated? no idea)
- a large amount of frames is required for convergence (possibly hundreds)

See also:
http://content.research.neustar.biz/blog/frugal.html
https://agkn.wordpress.com/2013/09/16/sketch-of-the-day-frugal-streaming/

Average: should be straightforward with a small number of images, but expecting precision loss with a large image sequence.

What's the matter with this precision loss? The hardware-accelerated routines work with integer values. Additionally, you don't want clipping in the highlights.

If the number of frames is known in advance, one could naively average N images like this:

Code Select Expand


acc = 0
for i in range(N):
    acc += image[i] // N    # integer division


What's the problem?

Code Select Expand


octave:1> a = round(rand(1,8) * 10)
a =
   0   7   9   9   3   1   1   7
octave:2> sum(floor(a / length(a)))
ans =  2
octave:3> mean(a)
ans =  4.6250

octave:4> a = round(rand(1,32) * 10)
a =
   8   1   9   4   4   5   9   9   1   2   5   7   8   1   4   4   6   9   9   9   7   7   1   6   4   4   1   2   2   3   2   2
octave:5> sum(floor(a / length(a)))
ans = 0
octave:6> mean(a)
ans =  4.8438


In other words, any shadow detail you may expect to get out of this naive averaging process, will be crushed to black. This gets worse as N increases.

There are several approaches possible to work around this precision loss, but these are left as an exercise to the reader. Constraints: up to 16-bit image buffers available for hardware acceleration, and only a tiny number of full-res images can fit into the camera RAM. The only hardware-accelerated image operations - known to us at the time of writing - are those described in the Eeko thread.

Another issue is how to handle clipped highlights while averaging. Can be simulated offline, with already-captured image sequences - again, exercise for the reader

[https://mikemcquaid.com/2018/03/19/open-source-maintainers-owe-you-nothing/]

Aria,

The issue here wasn't with the feedback you provided. That was actually welcome - reporting bugs properly is something that actually helps - especially considering that those who write the code might not be using it for filmmaking, so they might not have ran into your issue. (I, for one, record H.264 for my own needs - and that happens like 2 or 3 times per year).

The issue was with your expectations: you seem to think we somehow have a duty to fix what's not working for you. That is, the part about demanding that we should do something about it - whether it's removing a menu item, or fixing the feature, or whatever. That's unreasonable in an open source community, and no amount of praise would change that.

Here's a long answer:

https://mikemcquaid.com/2018/03/19/open-source-maintainers-owe-you-nothing/

- The way the software is today is all that the maintainers ever agree to provide you (bugs and all)
- The maintainers provide no assurances that the software will ever work for any user or use case (even documented ones)
- The maintainers are never liable for any problems caused by any use of the software (including damages that require you to pay for repairs)
- You must agree with the above to have any right to use the software

Open source initiatives here going on for years with nothing expected in return but maybe respect and some gratitude.

Exactly this - here's an even longer answer:

https://snarky.ca/setting-expectations-for-open-source-participation/

Everything in open source should be a series of kindnesses

To reiterate, just because open source software is free for you doesn't mean someone else hasn't paid some price on your behalf to get you that code.

Since open source is paid for by others in effort and time, that would suggest that there really shouldn't be any expectations on your part from what you get out of an open source project that you choose to use. You could view everything in OSS as a kindness that someone has done for you and others. Putting things into that perspective takes away the feeling of expectation and entitlement. This frames open source participation as someone doing something nice for the community and project, as someone having done a kindness for you.

As soon as you start demanding or expecting something from open source you have stopped viewing it as it was intended, and that distortion can be poisonous. When I choose to donate my precious time to open source I do it voluntarily as a nice thing that I enjoy doing. I didn't do it because someone demanded it of me, and the instant I feel that my time is not appropriately appreciated as the gift that it is, I stop enjoying doing open source. And when someone stops enjoying their contributions to open source, they burn out and quit.

Taking the altruistic view of open source keeps things grounded and healthy. Viewing open source as a kindness someone else has done for you gives the appropriate perspective that this is something nice and no one has any expectations from it. It's like when I hold the door open for someone. Ultimately I don't expect anything in return (although a "thanks" is always appreciated). And the person passing through the door doesn't expect anything else from me either. But when someone in open source makes demands it's like the person passing through the door criticizing how I held the door open. It's pointless and simply leads to people no longer being willing to hold open doors for others.

To reiterate, you should view open source as a series of kind acts people have done altruistically. That means you cannot make any demands or hold any expectations of an open source project. Or as Evan Czaplicki, the creator of Elm, put it, "Remember that people do free work because it is fun, not to get stressed by strangers".

BTW, you've actually received useful feedback on what you - as a non-programmer - can do to help the project:

Edit: Also consider taking the time to "clean" up all inappropriate info you can find by testing each and every feature systematically. Write down your findings and create a list of changes you would suggest for the community. This would be nice and effective user feedback probably useful for a lot of users. This place is in need of users digging in more actively.

And you actually did, to a small extent - and I appreciate that. Lack of good feedback over what works and what not, has been a problem here for years. But it should have been done without demanding that we should do something about it. From the same article:

And this extends to bug reports and feature requests. It's a kindness when you report a bug so that I have a chance to try and fix it. But just because you reported a bug doesn't mean I specifically owe you anything. I should try to thank you, but there is no contract here that says I have to address your bug or feature request. My kindness was to provide my time and effort for the open source project up until now, but there's no expectation beyond that of my time and effort. Open source really should be viewed as self-service unless I choose to help further. If something doesn't work for you then you are free to take the code and modify it to meet your needs; that's a key tenet of open source. So the idea that any open source project owes anyone anything is a misunderstanding of what open source fundamentally is.

Hopefully the above makes it clear where the backlash comes from. Also, you may want to review our older ML's Goal thread - which feels surprisingly up to date, even if it's from 2013 - and this particular piece as well.

However, I do agree the community could have handled it a lot better, rather than starting with a dismissive answer, without any context. Hr, hr

A small bit of history: yes, there are some features that were written before raw video was even imagined in our community. Some of them still work with raw video, others don't. Somewhere in 2014, I've actually started to disable the menu features that are not compatible with raw video (menu-raw-yuv-features) - but for some reason, the changes weren't well received by the reviewers at that time (one of them even commented that I'm trying to "dumb down" the user interface - yes, I remember these words very clearly even today). So, it quickly went to the back burner, and since I wasn't hitting this particular issue during my regular use of the camera, it hasn't been a priority - for me. YMMV.

I am also well aware of card free space not updating on its own, at least on some camera models. I know Canon firmware has some way to update it (iirc, if you open the Format dialog), but currently I have no idea how to call or trigger this procedure. One might be able to reproduce the issue in QEMU and figure out how to trigger the free space update from there, but... it does require programming skills and time for research - code doesn't grow on trees.

The last two days I try to understand the "mlv_rec" and the "pic_view" module in the lua branch. Mostly the module named "pic_view", because it is the smallest available module in the module folder.

Probably not the best starting point - pic_view was one of the first modules I wrote, so the coding style back then was quite rusty. To get started with modules, I'd recommend following the Hello World module tutorial (which is not in the repository, specifically so people can actually follow it and create that module from scratch).

Then, some of the simpler modules are mpu_dump and sf_dump - though, pretty low-level. The "deflick" module is another easy one, although it has limited purpose - everything done by that module can be done much better in post-processing. The benchmarks module (bench.mo) could be also reasonably easy to understand. Arkanoid is a fun one - but also one of the older modules.

ETTR and Dual ISO are a little more polished, but also more complex. For raw recording, I find mlv_lite being simpler than mlv_rec - but that's largely because it was derived directly from my old raw_rec code (unlike mlv_rec, which was more like a major rewrite). If you look at mlv_lite, also check the crop_rec_4k and derived branches (LJ92 compression etc).

Just out of curiosity I peeked into pic_view.c to find

Code Select Expand


        bmp_printf(FONT_MED, 0, 0, "Not a CHDK DNG");


This doesn't feel right but IANAP. ;-)

Kind of - that code works specifically with DNGs created by the library we have borrowed from CHDK (src/chdk-dng.c). Other DNG formats, created by other means, probably won't work.

That reminds me of the attempt to switch to another DNG library - PR 603 by dmilligan - currently on the back burner, sorry.

[Academic Corner]

While preparing the application to Software Freedom Conservancy (see Applying for fiscal hosting for context), I was a bit surprised to find quite a few academic works mentioning Magic Lantern. I already knew about 2 papers mentioning Dual ISO, but apparently our software can be useful beyond the typical camera usage.

https://scholar.google.com/scholar?q=magiclantern.fm
https://twitter.com/autoexec_bin/status/1346864496338415616

As such, today I've moved previous discussions and experiments related to scientific papers into this newly created Academic Corner - hoping something good might come out of this eventually.

I know, I know, too little, too late...

Status update: polishing the application to Software Freedom Conservancy - it already grew way larger than I'd like to admit

Currently, reviewing the application takes place on Discord - anyone is welcome to take a look... except for the search engines

If you are not already on Discord and you'd like to take a look, feel free to ping me on IRC (no registration needed) or via PM.

Edit Jan 11: application submitted!

Thanks to schrijver and Audionut for the major edits, but also to everyone else who made comments and suggestions

Auto power off  / disable
To ensure you record over 30 minutes you could even make the file size smaller (-2/Q-scale/0,5) skipping to the next video after 30 minutes would be maybe a little faster.

Bad news: these won't allow anyone to continuously record over 30 minutes.

Also worth mentioning: https://www.magiclantern.fm/forum/index.php?topic=19737.msg218437#msg218437

Currently, the project is unable accept contributions in any meaningful way, so we need to solve that first.
Long answer: links from Audionut.

[Applying for fiscal hosting]

Short follow-up before splitting the topic.

Given the reverse engineering nature of the ML project, opening an individual Patreon account individually is not the best idea. Besides, I like to think that ML is no longer a one-man show, so any fundraising efforts should consider the entire team. However, to be able to accept money as a group, we need some kind of legal backing, and the path of least resistance in this direction is to apply for fiscal hosting / fiscal sponsorship.

Long answer: to accept money as a group, we would need some kind of organization (such as a non-profit). Setting up one is non-trivial, i.e. too much of an overhead for a hobby project, given that we are all from different countries (mostly EU, but also US and AU). The bitcoins are just a workaround, and so is g3gg0's signature.

Back in April, I've considered a Patreon page, but since then I've changed my mind. There are many reasons against opening one, some discussed in the linked thread, others not (can't really articulate why; it just feels wrong).

I am, however, exploring the idea of fiscal hosting (for the entire team, not just for individual developers).

This is just "testing the water" and as such I think message and response came through and there is enough data for a1ex to come closer to a decision.

Decision made, thanks everyone for the initial feedback!

Next step: Applying for fiscal hosting.

Stay tuned!

Thanks. I'd like to add that it's not my intention to keep everything for myself, and I'd find it very useful to have a small team that I could rely on, rather than doing most of the maintenance work myself. For example, having at least an extra pair of knowledgeable eyes when reviewing pull requests would help a lot. Same for being able to delegate tasks like issue triaging, documentation, release management and so on, at least to some extent. But it would be unreasonable to expect any kind of commitment from volunteers / spare-time contributors (or, at least I'd feel bad about it).

https://snarky.ca/setting-expectations-for-open-source-participation/

And a related joke: https://twitter.com/ryanchenkie/status/1067801413974032385
(maybe not relevant atm, but it used to be very true for us some years ago)

So, it's not for anyone's personal benefit, but for moving the project forward. And some oversight for Conservancy could actually help with this - for example, if we join them, we'll have to think seriously about the project governance, and maybe write down some rules.

Here's an example from another project that operates under Conservancy's umbrella:
https://twitter.com/reduzio/status/1338108643762429952 (the entire thread)

And another example of how to organize tasks that are eligible for funding, from another project under Conservancy:
https://inkscape.org/support-us/funded-development/

One particular detail in the Inkscape guidelines: there is a rule that any development tasks eligible for funding should stay on a waiting list for at least 6 months, so volunteers could get a chance to implement these on their own. If we were to consider a similar rule, support for new cameras would qualify, for example.

No improvements expected in newer builds regarding this issue. Can you find a way to reproduce it?

Seems to be a race condition between LiveView and still photo mode.

Of course, any thoughts are welcome. However, tax issues aside, the choice that we are going to make (Open Collective Europe vs Conservancy) may impact the future of the project in some very significant ways - so I'd prefer opinions that would help us make the right decision.

BTW, another possible reason for choosing Conservancy:

In the CHDK forum I once heard the statement that as soon as CHDK became more commercial, Canon could protect its cameras better for debugging. Is that to be expected here too?

Conservancy is a 501c3 charity (based in New York); therefore, by choosing them, we would emphasize the non-commercial nature of the project even further (compared to choosing Open Collective). Or, at least that's my understanding. Whereas, if we were to incorporate a regular LLC or something similar, that would have screamed "commercial intentions", so this was excluded from the start:

we really need support in some things.
but it is our rule set to be
a) non-commercial
b) self-financing
c) non-profit
d) spare time project

within these rules, feel welcome to help

BTW, the following could also serve as a longer answer:

- The Value of Fiscal Sponsorship in FLOSS Communities (also covered on LWN)

While Open Collective fiscal hosts are also non-profits (Open Source Collective is 501c6 in California, Open Collective Europe is ASBL in Brussels), they actually go a little further away from the charitable path, in the direction of offering services to companies and backers. This probably makes sense for a large number of open source projects - Open Source Collective already host over 2000 projects, despite being quite recent (2017-2018?), while Conservancy - about 50 projects, despite them being around since 2006. However, it looks like Open Collective don't have the legal protections available for charities, so they had to be much more conservative regarding our application. I'm no expert, but apparently in US there is a clear difference between nonprofits and charities.

https://blog.opencollective.com/moving-beyond-the-charity-framework/
https://blog.opencollective.com/from-firms-to-collectives/

Well, I didn't mean to ask for tax advice on the forum; just sharing my current understanding.

With Xolo Go, VAT for invoicing works like this:

If your customer has a valid VAT number for intra-EU transactions, and is located in an EU country other than Estonia, then the VAT is marked as 0% due to the reverse-charge mechanism.
[...]
If your customer does not have a valid VAT number, then it will be necessary to add the Estonian VAT rate of 20% to the invoice.

If your customer does not have a valid VAT number for intra-EU transactions, for instance, they only have a local VAT number or they are a legal entity that is not able to apply for a VAT number, then it is still possible for you to invoice them via Xolo Go.

However, in this case, the Estonian VAT rate of 20% will be added to the invoice.

The following explanation is clearer, but applies to Xolo Leap (i.e. if one registers a company in Estonia through them). Likely similar to Go, from what I could tell:

If you sell services which need human intervention, such as consultancy, the following examples apply:

- If your customer is a business from the EU (e.g. Germany), and has a valid VAT number, you apply 0% VAT adding a special clause on your invoice: 'The purchase is liable to Intra-Community supply 0%, Reverse charge.' (You can check the validity of your customer's VAT number here)

- If the customer is a private individual or a business from Estonia, you need to charge 20% VAT (Estonian VAT)

- If the customer is a private client or business from the EU, and does NOT have a valid VAT number, you need to charge 20% VAT (Estonian VAT)

- If the customer is outside the EU (e.g. U.S.), don't apply any VAT (0%)

To my understanding, Open Collective Europe would fit into #3, while Conservancy (or Open Collective 501c6, which is off-limits for us) would fit into #4.

I've mentioned Xolo Go because it could be interesting for any EU-based contributors looking to get paid for their work on ML, as it might be easier to get started (depending on their home country, there might be less paperwork, compared to registering as self-employed in their home country). In this case, they would have to pay local taxes on a foreign salary, to my understanding (no dividends available from Xolo Go). Further reading: https://www.xolo.io/faq/xolo-go/category/withdrawals/subcategory/reporting-income

There might be a way to get around the second VAT - the one applied when invoicing Open Collective Europe:

In Belgium you can work around this if you have a small chiffre d'affaire—you don't need to charge VAT then

That is, if the freelancer registers a local business in their home country, and their yearly turnover is below a certain limit (3000 - 60000 EUR/year, depending on their country), it might be possible to invoice OCE without VAT.

For potential US-based contributors, I have no idea how things would work there. Assuming things will be straightforward for Conservancy (as they are US-based), but expecting surprises with Open Collective Europe - they would have to invoice the unincorporated EU-based partnership, whatever that means for them.

Again, this is not tax advice or request for tax advice - just my own understanding

Some hopefully good news:

First one is that I've already found a way to allocate significant amounts of time for ML without worrying about making ends meet, and without breaking the bank. Look at the current Bitcoin price

In short, g3gg0 agreed to transfer me 0.737 BTC that I can exchange/trade as I see fit, and that should cover part of my living expenses for the current year. Obviously, it doesn't reach the threshold for dropping out of my full-time job - so one shouldn't expect miracles, besides visible progress. The remaining balance of 1.0 BTC is still available for the entire ML project, but any decision to spend it would be much easier if there were a steady stream of income.

Current priority for me is project maintenance: things like completing the transition from Bitbucket to Heptapod, figuring out and documenting a contribution workflow, continuous integration/testing in QEMU, integrating previous contributions into mainline, assisting other developers with technical advice etc. Development for new models is secondary for me, at least for the time being - there are more important issues that need to be addressed first. Of course, others are free to explore whatever areas they are interested in, including new camera models.

Once the project will be back into "maintained" state, i.e. able to accept/manage contributions, we can also think about fundraising towards supporting new camera models, new features, maybe a stable release etc. Bounties could be useful too, but again, somebody has to manage the contributions. Food for thought.



The second part is about the fiscal hosting application. I still see some value in having some legal backing for the project and some consistent funding (as opposed to relying on occasional Bitcoin bubbles) - the project would no longer have the "underground" feeling, and a small team of part-time "staff" members (maintainers, devs, community assistants) might speed up the development quite a bit.

So far, we have met (using video-conferencing) with both Open Collective and Software Freedom Conservancy to discuss the initial details, but without any commitment, so we still have to decide which organization to pick in order to complete the application process.

In a nutshell, the more I think about it, the more I'm leaning towards Software Freedom Conservancy - and here are a few reasons.

First, they provide services like "Basic Legal Advice and Services", "Some Personal Liability Protection" etc:

When a project joins Conservancy, it formally becomes part of the Conservancy. (The project is thus somewhat analogous to a division of a company or a department in a large agency.) As such, project leaders benefit from some amount of protection from personal liability for their work on the project.

This is obviously valuable for US-based contributors, but also for EU-based ones, as I expect a significant part of the donations to come from US-based supporters. Yes, DMCA affects the EU as well.

Conservancy is a 501c3 charity, and - to my understanding - the personal liability protection comes primarily from the Volunteer Protection Act. We haven't discussed this particular detail with them; that was just my googling.

Some details to be reviewed (long reads):
https://sfconservancy.org/projects/apply/ConservancyFSATemplate.pdf
https://sfconservancy.org/projects/policies/conflict-of-interest-policy.html
https://sfconservancy.org/projects/policies/conservancy-travel-policy.html

For Conservancy, we need to have a "Project Leadership Committee" with at least 3 active members. There are also some fairly strict rules about managing expenses, about getting paid for one's time (contract work) and so on; while they are probably overkill in the beginning, gut feeling says they will be beneficial for the project in the long run. These rules are probably part of the reason they can offer personal liability - again, my own interpretation.

Here's an opinion I've got on Discord, from the author of Copy this book (no affiliation, but he has some experience running a nonprofit association):

The project leadership committee is a good thing, I think. It creates a structure wherein as project leadership you can have more confidence in your decisions because you don't take them all by yourself.

They leave some freedom as in how to structure this committee—the "Simple Self-Perpetuating Committee" is clearly the easiest. That being said, it would be good to think about a way to involve the community with this committee. For example, you could have the committee meetings be open to members of the community to attend.

Then, a detail that further tips the balance towards Conservancy, if you ask me:

The Patreon donations are processed by Conservancy, which then uses them to hire developers based on contracts made transparent to all supporters.

It's not advertised on Conservancy's website, but... apparently they are compatible with Patreon!

I haven't discussed this aspect with them - found the above quote earlier today - but we might be able to open a team Patreon account to be managed by Conservancy, i.e. without personal liability

Of course, they also accept direct donations via Paypal (which also handles credit/debit cards), so one will not have to create a Patreon account in order to support our work.

Finally, getting paid for one's time would be done for contract work (as a freelancer), and I believe they can be invoiced via Xolo Go (an Estonian service that allows EU-based freelancers to invoice any EU/US/CA-based business without requiring the freelancer to incorporate/register in their home country - much like a virtual company).

In comparison, Open Collective Europe ASBL (where we've also received green light) has a few important differences:

* the project would be an unincorporated partnership, and Open Collective Europe would hold the money for us
+ much less bureaucracy; the core team would simply have to approve any expenses without a formal process
- there's no personal liability protection - probably not needed as long as we "stay" in Europe (both regarding contributors and supporters, to my understanding)
- requires sharing the home address of a core contributor, for invoicing
- donations (under OCE) must be without any kind of expectations/promise attached, otherwise they are considered "services" and taxed 20% extra
+ they have some very interesting funding options involving services, such as a support contract / support tiers, or even office hours for companies - but there is an important limitation^*) on the European side of Open Collective, see below
- the collective would not have a VAT number, so if anyone would like to get paid for their time, they would have to invoice the collective with VAT - the usual EU rule about reverse VAT charge does not apply here. I smell double VAT taxation for any services that we might decide to offer through Open Collective Europe, but I might be wrong.
- cannot invoice the collective via Xolo Go (reason: lack of VAT number)
- no Paypal, only debit/credit cards available
+ transparent budget visible by everyone (recommended reading: From Firms to Collectives)
+ Twitter integration

^*) Regarding the services (including users who donate towards e.g. supporting a particular camera model), there is another important limitation:

If your collective plans to offer products and services on a regular basis, you should apply for your own VAT number. If that's the case, we would highly recommend you to create your own fiscal host for your collective that could also act as a fiscal host for collectives like yours in your country.

Some of the shortcomings might be fixed in the near future, as they plan to expand Open Collective Europe, but we haven't discussed these details yet.

Some common aspects (would apply to both Open Collective Europe and Conservancy):

+ reimbursing project-related expenses (e.g. for cameras to work on) can be done for contributors from at least US and EU (other countries might work as well, but not all)
+ taxes are only due if anyone gets paid for their work (and only for their part, not for the money received by the entire group)
+ both orgs allow reimbursements via Paypal or bank transfer

Docs to be reviewed:
ToS: https://docs.google.com/document/d/1Cc8GBkH4XUfdF9hxmrK5b2W2YUw09hRNoCMdoR2Kzao/pub
VAT issue: https://opencollective.com/europe/conversations/about-vat-04qj9b68

TLDR: for covering various expenses, such as server costs or cameras to work on, Open Collective Europe is a fair choice, but that's not primary reason we are applying for fiscal hosting:

Need hardware + time.
Hardware is easy.

Rather, the problem I'm trying to solve is this one:

ML code doesn't grow on trees.

Thoughts welcome - although I might sound biased or undecided, I'm just trying to find the best way forward for the entire project.

Happy New Year, btw!

Step 1: Portable ROM dumper. Send me the files privately.
Step 2: startup-log and startup-log-mpu. One of those might be able to save a log, or at least perform a LED blink.

If all else fails, UART would be the easiest way to diagnose it, but there are some other ways.

You could test the card in another camera (signature suggests you've also got a 5D3). The same binary works on all cameras.

If the card is prepared correctly (bootable + portable autoexec.bin, confirmed working in another cam), and ML was running before the crash (boot flag enabled in camera ROM), lack of any kind of visible activity means... the problem is on the hardware side.

You could check the UART port for any kind of activity, if you feel comfortable with this step, but I don't have high hopes. Sorry.

Probably the most reasonable way to interpret that "tip" would be "tip at the time of writing". That is, link translation should be done considering the date of the post containing that link.

Otherwise, replacing it with "unified" could also work.

For the forks, which are not hosted on Heptapod, we can probably link to Software Heritage. Example: https://archive.softwareheritage.org/browse/origin/content/?origin_url=https://bitbucket.org/OtherOnePercent/tragic-lantern-2.0&path=src/video_hacks2.c

Or, I could merge all of the forks into one big repo (let's say magic-lantern-all-forks) and ask Heptapod nicely to create it and let me push everything there. I don't have permission to create new repos there, but I've been thinking to ask them to re-host some of the "side projects" related to ML, such as ml-focus-pixels etc, in the same namespace.

ROM files from OP and MPU messages from the above log will boot the camera in QEMU, although with main display off, but menu works on the virtual camera. So, I'm not sure what's going on.

The above error is actually a bug in my logging code, or - rather - a side effect of the overhead of capturing debug messages. Small timing differences in PropMgr task could cause this message on this particular camera, at least.

Something unusual: log files are saved if and only if an ERR70 appears on the main screen. Otherwise, the camera probably does not initialize file I/O for some reason. To be investigated, but I cannot exclude the power button at this stage.

I've tried to compare the MPU messages with the power button in both positions (on or off), from my 60D, but couldn't find any difference. Rather, it seems to me that MPU decides to power down the camera while main CPU (ICU) code is still executing (early boot), but before the SD card is initialized. There may be some event or flag or whatever, that allows the MPU to power down the camera, but I haven't identified it yet.

[half-shutter from the menu apparently does *not* put the camera into mode 0 / "idle" mode]

Now we are talking

so, like before, half-shutter from the menu apparently does *not* put the camera into mode 0 / "idle" mode?  Or, it does, and ML is reading it wrong?

Apparently yes - in consts.h, CURRENT_GUI_MODE might be 0x3960 (at least for pattern matching).

Will try reproducing it in QEMU.

On the root of the card is TEST.DAT, 131072 bytes (exactly 128K), and is full of mostly junk data - probably uninitialized.  It appears to die without any helpful print before it can create the file full of "Will it blend?" messages.  My wild unfounded guess is... I don't see the first TEST.DAT file getting deleted anywhere in selftest.c, before attempting to FIO_Create a new file with the exact same name.  Is it possible that the camera will not let you overwrite files like this, causing the test to crash?

Junk data is expected - it dumps a section of the ROM, same block written twice (2 x 65536 bytes). If the contents of that file match the description, the first few lines from stub_test_file_io() might have succeeded.

Overwriting should be OK - the wrapper code in fio-ml.c will call FIO_RemoveFile prior to FIO_CreateFile. Otherwise, at least on some models, FIO_CreateFile would happily create multiple files with the same name on the filesystem, and that confuses at least the FAT32 driver in Linux - didn't check other systems on this particular one

Next test is checking the resulting file size - no surprises expected.

The following test is attempting to read back the file from card; that's where I would expect things to go wrong if memory allocation fails. You might be able to see some error messages - not yet written to a log file - directly on the screen.

This issue should be reproducible in QEMU as well.



Edit Dec.28 2020: both issues hopefully fixed (tested in QEMU only); new build available on the Experiments page. Please report back.

Focus distance is only printed, not used in any of the "decision" code.

1.0.5 available here: https://builds.magiclantern.fm/1100D-105.html