7D Raw Thread

[deC9r]

me2

[ted ramasola]

me3

[m1ke]

me3

Thanks guys.  I will submit this over the weekend (at the day job now).  One newbie question: having a 7D I have been copying One Percent's Tragic Lantern version down for my builds.  Should I create a branch on that and submit a pull request or should I create a branch off the main Magic Lantern tree? 

[ted ramasola]

Thanks guys.  I will submit this over the weekend (at the day job now).  One newbie question: having a 7D I have been copying One Percent's Tragic Lantern version down for my builds.  Should I create a branch on that and submit a pull request or should I create a branch off the main Magic Lantern tree?

submitting a pull request is the proper etiquette. Besides, A1ex already like it.

[deC9r]

yesterday came my KB 64gb 1000x card. I ran some benchmarks however the benchmarks performs only to 8/9 98/100, tried it a few times, always the same result....
Write speed looks alright to me, what do you guys think?



Also i was testing @1% 29/9 build @ raw_rec 1x mode @ 1728xX @ 16/9 = no issues no pink frames at all

[a1ex]

Thanks guys.  I will submit this over the weekend (at the day job now).  One newbie question: having a 7D I have been copying One Percent's Tragic Lantern version down for my builds.  Should I create a branch on that and submit a pull request or should I create a branch off the main Magic Lantern tree?

I'd like to have it in the main ML tree.

Maybe you (or anyone else) can also create another pull request with the relevant changes from 1% (or convince 1% to do it, because I didn't succeed, and TL is still diverging from ML with no signs of merging back).

[alsey7]

Off topic but please lets not have TL and ML get into a big old mess. I don't want to see a focal vs CyanogenMod drama to happen here 

[Pelican]

As I see 1% merge the changes from the main repo regularly to his fork so the two versions are not so different.
However I hope he will send his important changes back to the main repo soon.

[a1ex]

As I see 1% merge the changes from the main repo regularly to his fork so the two versions are not so different.

Not quite. Last time I've tried to merge the changes, the main differences were pretty significant and some of them dangerous. Imagine somebody giving you a car with the hand brake removed and telling you don't need it (that is, disabling some of the error checks from Canon code).

I don't mind this in a development branch clearly labeled as such, but I don't want this stuff in the main builds. I worked very hard to make ML code as robust as possible (more than 100000 shutter clicks from my cameras were just to diagnose random crashes), and seeing this being thrown out of the window is not quite pleasant.

This post explains the issue pretty well:

1) They keep my brand/project name in their forked project.  I spent a
ton of time building credit against a quality software product, and
for somebody to come and mooch off my hard brand building really makes
me mad.  Because while the software is open sourced, my time and
effort is not.

[...]

3) Make sure you make it clear in all your documents that the fork is
not supported by the original team, and that any changes made in this
fork is supported by you and nobody else.  Because all too often, I
have received support requests for somebody elses fork.  And then when
I have to tell the person that, it is not my work, they get mad at me
for a problem the forker caused.  So make sure you are going to
support your fork, don't fork it and leave it to die.  This also sort
of goes back to #1 about why different brands need to be created for
the fork, so that the end user doesn't get confused about who is
supporting the software.

However I hope he will send his important changes back to the main repo soon.

Tragic Lantern has been around for more than one year (since 2012-06-28 according to Bitbucket), and I have yet to see a single pull request from 1%. So far, me and Nanomad have been trying to pull his changes blindly, with various degrees of success.

So I hope for the same thing, but I wouldn't bet on it.

Sorry about that.

[ltboots]

Actually the recording is really 5X, but I am going to 10x so LV freezes and allows for faster recording at 5X

10x raw record not frozen on tragiclantern-v2.3.NEXT.2013Oct11.7D203 for me. I don't know why, but it only works if you cycle through display modes first. Something specific in the MAGIC.CFG as well. Here is the cfg I use.

# Magic Lantern v2.3.NEXT.2013Oct11.7D203 (dd08a07137b8 (unified) tip)
# Built on 2013-10-12 03:28:27 UTC by grey@greybook-209.local
# Configuration saved on 2013/10/19 12:45:23
beta.warn = 19
menu.first = -3
bitrate.indicator = 1
time.indicator = 0
uniwb.correction = 0
arrows.iso_kelvin = 0
arrows.audio = 0
arrows.set = 0
bv.av = 16
bv.tv = 103
bv.iso = 77
screen_layout.ext = 4
screen_layout.lcd = 2
shutter.lock.value = 96
enable-liveview = 0
focus.rack.delay = 0
focus.wait = 0
fps.override.idx = 32
battery.drain.rate.rev = 89
hist.draw = 0
audio.mgain = 0
audio.monitoring = 0
audio.filters = 0
spotmeter.draw = 0
waveform.draw = 0
focus.peaking.disp = 1
focus.peaking.thr = 10
focus.peaking.filter.edges = 1
zebra.draw = 0
global.draw = 0
disp.mode.x = 0
disp.mode.c = 145
disp.mode.b = 257
disp.mode.a = 257
lv.disp.profiles = 1
beep.enabled = 0

[deC9r]

Im getting in crop mode 2500xX around 250-270 frames, write speed is around 81-82 Mb/s without warmup (gave me most frames). How many frames do you get?

[hdclip]

Hello !!!!!!!what about the new Features of the 20 Oct TL????Thank´s!!!!!

[1%]

somebody giving you a car with the hand brake removed and telling you don't need it

Heheh, I had 2 cars where the hand/parking brake disintegrated. I didn't need it. Disc brakes are pneumatic, they still work and their chances of failure are lower than the cheap drum brake... this is on an auto tho, with a manual I can see it being necessary as you're in neutral a bunch more.


10X can be unfrozen with some display filters but its more fun frozen for me.

I'm all done changing PCs so I'll be able to pull new changes today or tomorrow. For pull requests I'll have to merge stuff back, maybe the best way will be a clean repo and then add 1 change at a time.

[RenatoPhoto]

LOL!   

I like the humor and hope that you keep having fun and keep doing great development work.   Although being restricted in your creativity from safety concerns makes development less fun, I hope that you can find a way to keep smiling and contributing to the main branch.

[1%]

The indicator is awesome. There should be a choice between the buffer display and the compact one however. On cams with piddly buffers you may want to see whats going on. Also would help people who have slower cards when they're testing resolutions.

Maybe only needs the buffers on/off

[cbob]

Heheh, I had 2 cars where the hand/parking brake disintegrated. I didn't need it. Disc brakes are pneumatic, they still work and their chances of failure are lower than the cheap drum brake...

Hydraulic! ...and though the chances of failure may be lower or higher, it's the diversity (of actuation and operation) that'll save your hide some day. 

[m1ke]

The indicator is awesome. There should be a choice between the buffer display and the compact one however. On cams with piddly buffers you may want to see whats going on. Also would help people who have slower cards when they're testing resolutions.

Maybe only needs the buffers on/off

I didn't want to add to a proliferation of menu entries if it was not useful.  There is a #define in the code which enables a menu entry to turn all the old messages/displays back on.  I can turn that on and tweak the code a little so it only displays the buffers and not the info that is redundant with the new indicator.

[1%]

Hydraulic!

Good catch. I tried stopping with the parking brake once (on a car it functioned), it did not work so hot. Had a brake line rupture on a 4000lb van and the hydraulic brakes still stopped it. Also had a caliper piston eject on another car with disintegrated pads and it stopped too.

There is a #define in the code which enables a menu entry to turn all the old messages/displays back on.  I can turn that on and tweak the code a little so it only displays the buffers and not the info that is redundant with the new indicator.

Yea, the redundant stuff needs to go. But the buffer view would be a nice option in addition to it for trying a new card without having to define everything + recompile.

[stevefal]

The indicator is nice, but I wish it was even more out of the way and off the image. Having stuff in the image can be a problem, especially when it hides a boom mic in the shot.

How about using the bars for the main recording indicator, including the color treatment for buffer stress?  http://www.magiclantern.fm/forum/index.php?topic=8539.msg80890#msg80890

I personally don't need to see detailed buffer information unless something is wrong. And something is never wrong for me.

[chish]

Hi all

Thanks to everyone involved for their hard work to date - fantastic product which is making my life easier.

I've decided to try out RAW Video recording on a Lexar 1000x 32gb card and so far have installed the latest build.

Can anyone explain to me or link me to a set of instructions on how to enable raw recording in camera?

Am i only able to do it in silent burst mode and then combine photos in post?

Any help would be much appreciated.

Thanks,

chish

[1%]

Raw video in the video tab, make sure you only load 1 MLV_rec or raw_rec

[Fringuello]

Another test, I noticed that by moving the focus has given me pink frames

[stevefal]

I am guessing they use less CPU..

I'm not sure, but it seems that if CPU load is an issue due to certain overlay features (histo etc), the user could turn those off individually instead of turning Overlay off entirely. I think this should be equivalent, CPU-wise, to allowing bars to draw with GD off. But maybe it's not.

This may also be related to raw_rec cropmarks which currently seem to have a dependency on Overlay: https://bitbucket.org/hudson/magic-lantern/commits/6e63779e0dcf9e8bfc57fe54eca1ab65a884787f#comment-498757

[mityazabuben]

A little test:

[hdclip]

I've looked but can not see adjustment