Difference between Tragic Lantern and Magic Lantern

Started by mityazabuben, October 19, 2013, 11:13:51 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

mityazabuben

I would appreciate, if someoe explain me about ML and TL and their difference. Thanks.

RenatoPhoto

Magic Lantern (ML) is the main branch of development and Tragic Lantern (TL) is a separate branch that has been doing some development on specific cameras like the 600D/6D/50D/EOSM/7D.

Since the developer of Tragic Lantern (1%) has not taken the effort to merge his code back to the main branch now there are some builds in the main branch that lack the functionality added to those specific cameras worked on TL.

Nightly builds are done from the main branch, and therefore are not up to date with the latest improvements done in Tragic Lantern.

I am not a programmer but I assume that the task of bringing TL into ML will be nearly impossible without the cooperation of 1%.
http://www.pululahuahostal.com  |  EF 300 f/4, EF 100-400 L, EF 180 L, EF-S 10-22, Samyang 14mm, Sigma 28mm EX DG, Sigma 8mm 1:3.5 EX DG, EF 50mm 1:1.8 II, EF 1.4X II, Kenko C-AF 2X


deletedAcc.0021

I've been running TL on multiple 600D's for quite some time for commercial work and haven't experienced any issues. I believe 1% is a competent coder and I'm pretty sure he wouldn't release anything that would jeopardize our cameras. 

But, that said, after reading the two topics that dmilligan posted above, I've decided to heed a1ex's warning once again.

I've been known to do some stupid things while recording, including turning off the camera instead of hitting the stop button to end the recording, so as a precaution and to hopefully save the lives of my cameras I'll revert back to using the nightlies.

I could probably just get by with using 2.3, but there are so many new features and the new look make my little 600d's power houses on the job.

I'd love to see some of TL features merged into the main branch, especially the video hacks and maybe the advanced bitrate control. So, hopefully these guys will work it out.

Andy600

Although I agree that keeping the code unified is important, I'm a little disappointed at the tone of some comments directed towards 1% who, like a1ex, g3gg0 and other devs spend a lot of time working on the code and, importantly, spends his time working on cameras that would otherwise not be as developed as say the 5D MkIII.

As a1ex pointed out in another thread, there is an etiquette to open source that, in an ideal world, should be followed so that the knowledge is being shared in both directions. This is actually  happening with Tragic Lantern as the code is freely available in 1%'s repo(s) on Bitbucket and the main issue being that 1% is not himself pushing everything back upstream for review. This (I think) is for a couple of reasons. The first is that 1% works at his own pace and is often quick to implement/change and rework ML code across several camera bodies and second, some of the TL code is classed (by a1ex) as potentially dangerous and will never be approved.

While 1%'s approach may be a little disruptive I think it's also very important to point out that his input on several cameras has been quite significant and rather than criticizing him for not playing ball when it comes to pushing back code (for whatever reason) it should be acknowledged that he is a valuable asset to the Magic Lantern development team and perhaps he just needs a little help from knowledgeable individuals who can push his work back to the main trunk, enabling him to continue doing what he does. This is something I think might be possible for someone at my level although I do need some guidance in how to do it.

As someone who only compiles a fork of Tragic Lantern, I admit I have little knowledge of the actual code and have probably not helped matters when uploading development builds without highlighting the potential dangers to users, however, I personally have had no issues when running Tragic Lantern builds on my 600D and 50D (although I know the dangers are real). After reading comments made by a1ex in another thread I can now see a couple of areas where I can contribute more by removing some developer specific features and adding clearer warnings to the 50D alpha builds so that users will understand better.

I guess what I'm trying to say here is that everyone is on the same team and although devs may differ in their approach and working methods this shouldn't be cause for animosity and ill-feeling. Words taken at face value on a public forum can often be misinterpreted and misunderstood and we, especially the non-coders, shouldn't be adding fuel to the fire potentially, making these valuable and knowledgeable developers think that they are not appreciated..... because they truly are!



Colorist working with Davinci Resolve, Baselight, Nuke, After Effects & Premier Pro. Occasional Sunday afternoon DOP. Developer of Cinelog-C Colorspace Management and LUTs - www.cinelogdcp.com

a1ex

Agree with Andy600.

Look in the 50D thread: back then, when GregoryOfManhattan was active, he was pushing everything to main tree, and it was pretty nice, we were exchanging ideas, test results and so on. After he left, I don't remember seeing anything pushed back to the mainline. Basically, the main 50D builds seem abandoned (also EOS M, 6D, and 7D, and the 600D is not too far from that), and soon I'll probably have no other choice than disabling these nightly builds, like I already did with the EOS M.

QuoteThe first is that 1% works at his own pace and is often quick to implement/change and rework ML code across several camera bodies

Okay, but more than one year without a single pull request seems a little too much for me. It no longer feels like collaboration, but like competition.

Quotesome of the TL code is classed (by a1ex) as potentially dangerous and will never be approved.
Not in the current form, but most of the stuff can be reworked in an acceptable way. For example, I'm trying hard to ensure that, when feature X is disabled, it really does nothing (not patching Canon code, not altering data structures and so on). Also, when you have to disable a Canon safety check (assert), it should be used as a last resort (so look for some alternative method first). If you really have to use it, you have to make sure it won't cause harm (write a description, something I can understand, not just obfuscated cache_fake calls that are impossible to review). Showing that it seems to work is not enough for me, because I've had enough bad experiences with problems happening with very low probability (which are hardest to diagnose). You know, race conditions, buffer overflows... stuff like that.

Quoteperhaps he just needs a little help from knowledgeable individuals who can push his work back to the main trunk, enabling him to continue doing what he does. This is something I think might be possible for someone at my level although I do need some guidance in how to do it.

I recommend taking one thing at a time (for example, display filters on camera X, or FPS override improvements on camera Y). Ideally you should be able to simply pull a changeset or a group of changesets that does just that (but this is impossible to do without the cooperation from 1% - you should try to do only one thing in a changeset, not 3 unrelated things). So, the alternative approach is to take the diff between ML and TL (easy with the rdiff extension), pull the relevant lines, apply these changes manually (or if you feel confortable to edit a huge patch directly, that's fine too), describe what that change does and submit a pull request.

deletedAcc.0021

When raw capability first came to be, you had to run TL to get this feature on the 600D.  There were links in the main raw forum to TL as the source for the 600D.  I think those threads gave it credibility as to being safe to run.  Other than one small post by a1ex about sraw, I never knew of any other potential hazards in the code, so I continued to use it.

And, if you look at the number of downloads, there are a lot of people either running or at least tried TL, who I'm sure are not aware of these issues or even this discussion.

I recommended TL to a lot of people including friends, which I now feel obligated to point out A1ex's concerns to them and let them make the decision whether to continue using it or not.

Like Andy600, I too am guilty of compiling code for other users from 1%'s fork and sharing it with others, and (knock on wood), no one has bricked or harmed there cameras.

In no way is this meant to be a derogatory statement aimed at 1%,  I have nothing but respect for the man and I wish I had his skills.
I too hope they can all work together to get this concern ironed out.




RenatoPhoto

My hat off and respect to all of the coders!!!!  :-* :-* :-*

But if I have the option, I will take the (free) car with a hand brake.   ;D ;D
http://www.pululahuahostal.com  |  EF 300 f/4, EF 100-400 L, EF 180 L, EF-S 10-22, Samyang 14mm, Sigma 28mm EX DG, Sigma 8mm 1:3.5 EX DG, EF 50mm 1:1.8 II, EF 1.4X II, Kenko C-AF 2X

1%

Its not competition, ML still drives most (like 90%) of the features... I never made a pull request because I have no clue how.. I know how to bring them in but not push them out. The diff seems like the best idea. Plus previous laptop only had a 40GB so with all ida files/arm console files/etc I was just out of room. Most of my time is spent adding ML stuff, fixing conflicts and testing stuff.. But this machine can actually play back the H264 video from 6D/600D and I have 128GB to work with.

deletedAcc.0021

Quote from: 1% on October 22, 2013, 12:33:05 AM
Its not competition, ML still drives most (like 90%) of the features... I never made a pull request because I have no clue how.. I know how to bring them in but not push them out. The diff seems like the best idea. Plus previous laptop only had a 40GB so with all ida files/arm console files/etc I was just out of room. Most of my time is spent adding ML stuff, fixing conflicts and testing stuff.. But this machine can actually play back the H264 video from 6D/600D and I have 128GB to work with.

Cool dude,  get your code tweaked so it passes ML safety inspection and get it in the main repo.  You have too many good features not to include them in ML.

1%

It pretty much is ML with some tweaks and extras. Someone merging back would be great too... its a bit of time to do new stuff + fix merges + test on like 3-4 cameras and then merge it back after that.

I.e, I can work on audio support for EOSM or I can learn pull requests, make a new repo, add everything to merge back and then fix the conflicts when merging it back into my source, etc.

RenatoPhoto

Excellent! 

By the way I sent kisses since I cannot send money since you took the PayPal link down.  Ha ha  ;) 
You could probably use a new laptop!  Although I could only contribute a few bucks!
http://www.pululahuahostal.com  |  EF 300 f/4, EF 100-400 L, EF 180 L, EF-S 10-22, Samyang 14mm, Sigma 28mm EX DG, Sigma 8mm 1:3.5 EX DG, EF 50mm 1:1.8 II, EF 1.4X II, Kenko C-AF 2X

N/A

I've used TL since I discovered the glory that is Magic Lantern. Even bugged 1% a few times when I first joined and he (or she?) has always been super cool. I've trusted the ML and TL builds on my own work and paying shoots, a few of which being pretty damn tense (ever shoot a music video with a room full of drunk, coke-money rappers and marijuana smoke so thick that it looked like a got-damn fog machine was on?). I'm no coder, but I've done my fair share of various videography and photography jobs. When it comes down to it, all of these guys are revolutionizing the cinematography world and deserve the utmost respect.

With all that said, where's my damn slice 87, 1%?!

;D
7D. 600D. Rokinon 35 cine. Sigma 30 1.4
Audio and video recording/production, Random Photography
Want to help with the latest development but don't know how to compile?

1%

Lol yea, that needs to be ported. Its easy for shit to get put on the back burner with so many incoming changes.

Marsu42

Quote from: 1% on October 22, 2013, 12:33:05 AMIts not competition, ML still drives most (like 90%) of the features... I never made a pull request because I have no clue how.. I know how to bring them in but not push them out.

Well, if that's the issue (is it?), then here's the solution:

1. Log in to https://bitbucket.org/OtherOnePercent/tragic-lantern-6d
2. Click on "Create pull request" (that's the button on the top right, even I found it, and that's saying something)
3. Alex will merge this request asap, then take some days's work to revert the stuff he doesn't like and ask 1% if in doubt about something (don't update tl during this phase)
4. When Alex is finished, merge the main ml tree again - done.
5. Repeat procedure every few weeks whenever you feel you've done some significant & stable work on 6d/7d/eosm.

Quote from: a1ex on October 21, 2013, 08:44:40 AM
It no longer feels like collaboration, but like competition.

Strictly from a user's perspective my fear is that if 1% leaves (real life issues do happen) or gets less active the 6d port will be dead in the water if the tl/ml codebases have forked too far alex or the main ml devs might not be willing or able to merge it back. And without intimate ml knowledge it isn't possible to just resolve conflicts when merging the main ml repo into the 6d tl fork.

DTSET123

1% we love you!!! I am thankful for all you have done for 6d users!!!

1%

I think its one hell of a pull request to merge the whole thing at once.  It would be conflict city. I don't want to lose my notes either but they should definitely not go into main.


Marsu42

Quote from: 1% on October 23, 2013, 11:59:20 PM
I think its one hell of a pull request to merge the whole thing at once.

I'm 100% sure alex is very open to attempt to solve it, I don't know how large the code differences really are by now - but as you and alex are very intimate with the code it shouldn't be impossible to merge it either via mercurial or as a diff, ml is large, but not that large. But it's great the discussion moves from the "will we do it" to the public "how will we do it" stage :-)

Quote from: 1% on October 23, 2013, 11:59:20 PM
It would be conflict city.

Indeed, this shows that the merge attempt is beyond overdue. However you do it, +1 for doing it now before it gets even worse :-o ...

... and I really have to mention again that you're really doing great work and my 6d would be near useless without you, so please take this post as a user's wish for continued 6d ml success.

Quote from: 1% on October 23, 2013, 11:59:20 PM
I don't want to lose my notes either but they should definitely not go into main.

That's notes as in code annotations with // and /* */ ? Hmmmm, isn't there some editor or similar approach that can manage annotations separate from the main code file? I doubt it you're the only coder in history facing this problem, so there have to be solutions for this.

1%

Yep, but all solutions for moving notes don't back them up to the repo :)


A1ex wrote so much of ML, I read through all the ML code to figure things out and incorporate them, sometimes by hand. In fact all code I can find to see if I can squeeze out one more feature. Its just a lot of work to merge it all, I guess one upside is that now he only has to do 5DII and 5DIII and the rest can be ported down to other cameras.

Also removing the movie remap on 600D was the reason to fork in the first place. It has worked pretty well there and its probably the only cam that both needs its and has it working without major hiccups. 60D from where I looked at the FW is a mix of 600D + 7D so kinda old and new. I can see how it was problems for cams < 600D hence its never enabled there.

But yea, not going anywhere any time soon. ML is basically needed to get anything constructive out of these cameras.

Marsu42

Quote from: 1% on October 24, 2013, 02:22:06 AM
Its just a lot of work to merge it all

Well, on reflection I all should probably comment on this that I hope TL & ML don't stay separate forks forever, but of course my main interest is to get a working 100% 6d port and getting all ml features merged into this, wherever the repo actually is :-)

Dreamer

I hope very much that some individuals with the willingness and resources tackle the merge of TL mutually with 1%, because fragmentation over time is a bad, bad thing.  Especially with projects like these.

Critical Point

Yeah, it would be really nice if the GOP/Slice controls for H.264 would be ported to ML. If not, I'm happy with TL, for me it's working very well, no issues of any kind.

For GH2 for example, there are a ton of hacks, all different, who needs a certain thing, can install a certain hack, TL and ML are the same way.
600D & GH2 / PC.

a1ex

Just a friendly reminder: it's been almost two months and no sign of improvement.

Let's try something else:

1) During the next two months I will not commit anything to ML code base other than accepting patches and maybe tweaking them.

2) I will move any ML ports that have not been maintained in the last few months into a "unmaintained" directory (that is, no more nightly builds for them). Anybody is free to jump in and maintain these ports. When the situation improves, I'll move them back.

3) I will create a separate forum section for third party modifications (TL, a.d.'s 5D2 builds, g3gg0's experiments, Marsu42's tweaks and so on). Basically, anything that lives on its own and is not (yet) maintained by the ML team. Eventually, all the good stuff from these should get merged into mainline, and until then, they should have a chance of getting tested by the adventurous users without competing for attention with the main ML nightly builds.

Discuss.

gary2013

Quote from: 1% on October 22, 2013, 01:14:30 AM
... I can work on audio support for EOSM or I can learn pull requests, make a new repo, add everything to merge back and then fix the conflicts when merging it back into my source, etc.
That is a no brainer. Audio support for the EOSM.  :)

I appreciate everything you, Alex and all the other devs do for the rest of us and I hope this all gets worked out somehow. No matter what Canon camera anyone owns, we all have a common goal and hopefully success. 

I hope "everyone" understands the smiley face and the sincerity of my words after that.

Gary   

a1ex

Quote from: gary2013 on December 11, 2013, 08:15:46 AM
That is a no brainer. Audio support for the EOSM.

In other words: screw the project health, I just want features!