Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - names_are_hard

Pages: 1 2 [3] 4 5 ... 20
51
MLVApp uses QT Creator I think?  It should be relatively easy for users to profile their usage and see where the pain is coming from.  I've never done this with QT Creator but I'm a big fan of profiling if you're trying to optimise.

52
Quote
Also, I just realize that AMD CPU and GPU is not well supported by low level compilers

This is not true.  The article you linked to was about a specific *Intel* library that *Intel* deliberately made to be poorly optimised for AMD CPUs.  It has no relevance to "low level compilers".  Only one specific Intel library.  MLV App isn't even using that library!  Compilers optimise just fine on AMD.

Benchmarking is always quite tricky.  Since we can run MLVApp anywhere, when you're interested in MLVApp performance, it's the obvious best choice to use.  Ideally, script running MLVApp, always with the same input file, processing options etc.  That way you can get reproducible results, and you can share the script with other people so they can test on their systems.  It would be cool to see a set of results across a lot of different systems.

53
Quote
I remember that MacOS later versions use Linux kernel
MacOS has never had a Linux kernel.

Quote
Better avoid AMD cpus and video cards. Something I was not aware before.
Please don't give completely unfounded advice.  This is just untrue.  It's probably the *opposite* of true for MLVApp, which is heavily threaded; current Zen based AMD CPUs normally beat Intel (and Apple M1) based systems in multi-threaded workloads.

Don't guess.  Don't assume benchmarks *on a different piece of software* will be representative.  Benchmarking is notoriously complicated.  Benchmark using MLVApp on different systems; it's free and available on all OSes!  If somebody gives me an MLV file and instructions, I'll bench on my modern 8c/16t AMD Linux system.

54
Quote
There just aren't enough people with deep ML knowledge and free time to edit the wiki
This was a simple edit and took me less than ten seconds.  I'd say the time consuming part of improving instructions is checking them thoroughly while keeping aware of possible sources of confusion.  Finding the problem here was slower than fixing it.

Quote
I just don't quite understand how a very experienced developer can't google such a simple thing
The terms were quite generic.  People are tired sometimes, or don't have much time.  There are many reasons.

55
Quote
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.

Quote
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.

56
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.

57
General Development / Re: MMU, memory mapping (DIGIC 7 and later)
« on: May 01, 2022, 12:20:36 AM »
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

58
Camera Emergency Department / Re: EOS M - Bricked, showing Err 70
« on: April 29, 2022, 01:40:12 PM »
That's a great summary, thank you!  We could probably remake an autoexec.bin from that info.

59
Camera Emergency Department / Re: EOS M - Bricked, showing Err 70
« on: April 29, 2022, 04:10:46 AM »
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.

60
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

61
General Help Q&A / Re: C100 question
« on: April 22, 2022, 08:26:09 PM »
I don't think anyone has any plans to even attempt this.

62
Camera-specific Development / Re: Canon EOS R5 / R6
« on: April 15, 2022, 12:36:55 AM »
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.

63
Camera-specific Development / Re: Canon EOS R5 / R6
« on: April 13, 2022, 01:50:42 AM »
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.

64
Camera-specific Development / Re: Eos 2000D
« on: April 13, 2022, 01:37:58 AM »
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.

65
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?

66
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?

67
Share Your Videos / Re: Family Vacation 2018 - 5D3
« on: April 06, 2022, 10:18:51 PM »
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.

68
Share Your Videos / Re: Family Vacation 2018 - 5D3
« on: April 06, 2022, 07:33:17 PM »
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).

69
Camera-specific Development / Re: Canon EOS 1300D / Rebel T6
« on: April 05, 2022, 08:17:15 PM »
Quote
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.

70
Camera-specific Development / Re: Canon EOS M
« on: March 20, 2022, 03:03:29 PM »
It's more likely that you could capture a "portrait" aspect ratio, and rotate the camera 90 degrees, for the same effect.

71
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.

72
General Help Q&A / Re: Canon 700d HDMI out Issue
« on: February 02, 2022, 12:15:23 AM »
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.

73
Camera-specific Development / Re: Canon EOS 1300D / Rebel T6
« on: January 13, 2022, 04:36:51 PM »
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.

74
General Help Q&A / Re: Canon M50 Mark II
« on: January 02, 2022, 06:37:24 AM »
M50 and M50 mk2 are different cams from EOS M.  There is not yet ML for M50 or M50 mk2.

75
Camera-specific Development / Re: Canon 850D / T8i
« on: January 02, 2022, 01:59:55 AM »
Got some features working (also on 200d).

Shutter count zero appears accurate for 850d:


Benchmarks and screenshots work (not all benchmarks tested):

Pages: 1 2 [3] 4 5 ... 20