Messages

C100 and the 70D are crop sensors, so it doesn't look good for us full frame users.  Not to say the 5D IV would be excluded but the III and 6D were probably separate designs.

The pattern is obvious if you look at them in binary, but might not be so apparant from the hex:

Good find by the team.  It is surprising how different each camera models are.  Is it not even consistent from DIGIC processor versions?  From a Canon development standpoint you would think they would standardize.

Thanks for sharing.  It brings up two things; one I am amazed at what is unveiled here, two I see the mention of only two cameras that are capable of this because of the dual channel, but I thought the team cracked more cameras so how did they do that?

Thanks, too bad.

Since this is about how the camera takes the picture, is it possible to control ISO for each pixel?  For example the dual_iso feature alternates lines with a whole row being ISO setting 1 and the next ISO setting 2.  So is it possible to change the sensitivity of the pixel for each pixel dependent on the scene?  Like sections where the white is clipping automatically decrease the sensitivity and where the pixels are reading no signal to increase the sensitivity.

Challenge would be not to make it too flat, and of course to program it.  I was trying to follow the code that 1% developed and was not able to determine if pixel level is possible.  Also this would have to be a two step process; read an image determine the problem spots, adjust each pixel and take the picture.

One more thing... sorry if my suggestion insulted anyone's intelligence.  I was only making a recommendation based on the perceived problems I had read.  It wasn't that I thought the development team was unaware of the possibility of wrapper functions, it was just that they were not initially used and possibly were overlooked since the project had grown so quickly and successfully from the initial implementation.  If anyone wants to discuss this with me I would be glad to assist in anyway that I can.

- Backend stuff: we are pretty close to the limit of how much RAM we can use (how many things we can cram inside). Module system (under development) will improve this. This can be for 2.5 if you ask me, but g3gg0 would like it earlier.

- I'd like a boot process that supports all cameras with a single download (like the unified 2.3 zip). The current approach does not scale to the new models (it requires a huge fat binary containing the code for all cameras). I'd like a small platform-independent bootloader, the camera-specific modules (ML core), and user modules (functions that are only loaded on demand; usually platform-independent code).

My solution was inline with the above.

the problems we currently have, are not related to any language based solutions.
even with C# or any other high level language we would have any advantage.

Totally agree that a higher level language would not be the solution even if it were possible.

engardeknave, my whole reason for posting the suggestion was for the developers to save them time and energy in the long run.  From reading the thread and a few others about Tragic Lantern vs Magic Lantern, it looks like there is currently a challenge with new camera models, new features, and getting them all into a single release.  The typical question that is asked is when will the next stable release be available?  This is frustrating for the developers and for the users.  If it were feasible to release single features as they become stable that would be a huge benefit to the developers and the end users.  Again, the developers are doing a great job and are devoting their personal time on a free project.  I was proposing a possible solution to help for future releases.

Unfortunately I do not currently program in C or C++ so I am not comfortable altering code that I am not sure is stable for my $2000 camera.  Also, I only have one camera so I would not be a good candidate for cross model programming.  It also is very difficult for someone to jump in on the project without discussion with the main developers.  Which is why I posted here.

g3gg0, I appreciate that a developer has looked at this.  Thank you!  I see that the try/catch option with setjmp was not a good one.  This is good to know.  Since I have your attention, my original post was suggesting to have the main features in a standard class that called wrapper functions to camera specific functions.  The attempt of the try/catch would be to call functions and if they are not developed then display that this feature is not yet available.  The logic was to implement features as they become stable.  Would this be beneficial to you as a developer?  Would you also see benefits for the end users?

Audionut, thanks.

Dmilligan, your second post was much more helpful than your first worthless comment.  The GUI.c is interesting. I was surprised to see the supported list.

Here is a link to a try/catch option... http://en.wikipedia.org/wiki/Setjmp.h

Maybe you'll see why using classes and try/catch blocks is not some simple solution to the problem...

I looked at the links you provided.  I thought I read that ML was written in C++, hence the classes recommendation.  Structs are available and used in the project.  As you know structs were a pre-form of classes.  They were the basis of object oriented programming.  From the provided example the project references menu.h.  Again if menu.h were converted to wrapper functions it could work.

I do not remember saying that it would be a simple solution, just that it would help to advance the project.  Also, I said the code example was C# and I was only demonstrating an example.  I haven't programmed in C++ for 9 years or more and C for 12 years or more so I am rusty with it.  I do know that it is possible to replicate my example in C, because I have done it.  I am sure the devs could accomplish it if they wanted to and agreed with the direction.

Possibly you do not understand what I am saying.  From the forum messages and my own experience as a software developer, my recommendation was to possibly help move the project forward to more end users in less time.  I am quite impressed by the developers and what they have accomplished.  Not so much by you and your comment.

Then you should not render judgements about the code, b/c you clearly have no idea what you are talking about.

I am new to ML and have not looked at the code, however I would think a good direction would be to move all of the camera firmware code to class.  Then have a standard class for the menu.  The menu functions would call wrapper functions that would call the camera specific functions.

When one of the developers starts to work on a new camera, (s)he would first start with determining the firmware verification test function.  Once established the system would boot with pass or fail and if failure then prompt to continue or not.

At that point the developer would start on each function.  For example dual ISO.  So the menu class function for dual ISO might look like this:

function menu_iso_dual()
{
try
{
camera_iso_dual();
}
catch(err)
{
Msg("this function is not available");
};
};

It has been too many years since C++ so example is in C# but the basics are there.

With the above structure you could quickly release versions for new cameras with functions as they come available.  I would also add a function stability option too. Something like:
Alpha = red menu
Beta = blue menu
RC = green menu
Final = white menu letters.

That way people are aware of the progress on each menu item.