First 7D alpha released!

[P337]

Immediately started experimenting with it. I love the cropmarks feature! This way I can make better ones with 3ths 5ths and 7th. Yet I see that not every pixel of my file is showing up. Is this because the 720x480px file is rescaled or what? Any solution? What would be the best resolution to make it in than?

Lay-out wise I don't really like the font for the aperture and shutterspeed in live view. It is much harder to read than the standard canon typography. I also don't like it being colored. Could this become a future option?

I can't wait for HDR video and a build in intervalometer.

You should post that typography under the feature request topics: http://www.magiclantern.fm/forum/index.php?board=24.0
I doubt anyone here would know about that.

You may also have better luck with cropmarks help in the general help topics: http://www.magiclantern.fm/forum/index.php?board=4.0

[ted ramasola]

damn...i really thougt a card reader on a printer works like normal card reader...never used it before... But i found an option to allow write Process on memory cards. But thanks..."use a real card reader" was a good tip  :-)

I however have been using the card reader in my epson printer.  It worked fine. Just make sure you access the card as removable storage using the explorer or my computer in windows and NOT the canon eos utility.

[akshayverma1]

I made some cropmarks for the 7D. These are for 640*480 since the screen is 4:3, unlike the 720*480 on the 3:2 screens.
The actual size is 640*427 because the rest of the pixels in height are taken up by the information bar at the bottom, effectively leaving us with a 3:2 usable area.

1) Cinemascope 2.35:1 with translucent 16:9 borders, rule of thirds grid and action safe lines (very thin and non-interfering)
http://dl.dropbox.com/u/48224378/CineSco1.bmp


2) 16:9 with translucent border, 2.35:1 lines in black and action safe. (No rule of thirds grid on this one because the default camera grid works for this)
http://dl.dropbox.com/u/48224378/CineSco%26HD.bmp



In the crop marks guide it was written that 1 px lines cause aliasing on 4:3 screen and should be avoided. I figured it was due to scaling from 720 px to 640 px. In these crop marks, the action safe lines are 1px and don't cause any aliasing 

[a1ex]

Cropmarks will always be stretched to cover the 3:2 image area (even on 4:3 screens). So, the same files can be used on all cameras.

[akshayverma1]

Cropmarks will always be stretched to cover the 3:2 image area (even on 4:3 screens). So, the same files can be used on all cameras.

Yes, but scaling was causing aliasing with 4:3 screens. Isn't it best to have pixel perfect, unscaled marks?

[a1ex]

The image buffer in 4:3 screens is 720x480, but the display processor scales it somehow (probably downscales to 640x480, didn't check in detail). So, the 640x427 bitmaps will cause a bit of aliasing on 3:2 screens (not missing lines, but a few doubled lines).

[Northwinds]

After a really busy week I've finally had the chance to properly check my footage from last Friday and I must say I'm really happy with it overall!
So cheers and you now have a donation from me.
Now if by any chance you can get another alpha out by Christmas that includes the FPS modifier that would rally help me out for my mates' next club he wants me to shoot on the 28th!
Either way,
Cheers!

[g3gg0]

Now if by any chance you can get another alpha out by Christmas that includes the FPS modifier that would rally help me out for my mates' next club he wants me to shoot on the 28th!

thanks for feedback.
unfortunately FPS modification is not that "simple" as it is on e.g. 600D and some others.
still reverse enigneering, but i didnt find anything useful yet and no idea if this can be done this year.

[P337]

How far has fps override gone in Magic Lantern?  I thought it couldn't do much more frames per second than "Canon FPS" with issues for 180 degree exposures and high rolling shutter.  Can any of the cameras do 48 or 1080p60?

[nanomad]

FPS override it's not for increasing FPS, but for decreasing it

[P337]

FPS override it's not for increasing FPS, but for decreasing it

Ah, thank you for clearing that up.  So I guess it's for easy time lapsing or choppy blurry low light shots.  Timelapse mov files straight from the camera sounds like something fun to play with ;-D

[feureau]

FPS override it's not for increasing FPS, but for decreasing it

Didn't one of the models managed to get to 30-36ish fps?

[nanomad]

yes but as you can see the potential gain is minimal

[P337]

Unless you have a 500D ;-P

[feureau]

*crosses finger in hopes the 7D has enough processing power and bandwidth for 48fps*

[g3gg0]

*crosses finger in hopes the 7D has enough processing power and bandwidth for 48fps*

dont even think about that. it will take a few months until i understand how FPS timer are set up.

[jphansen]

Just send feureau that string of code.. And he will have it fixed in no time ;-)

[feureau]

dont even think about that. it will take a few months until i understand how FPS timer are set up.

Take your time. No worries.

Thanks again for all the hard work.

[Digital Corpus]

*crosses finger in hopes the 7D has enough processing power and bandwidth for 48fps*

The camera produces 40-45 Mbps video by default. Myself and others have been able to produce 150-200 Mbps video without much cause for alarm. Doubling frame rate and keeping QScale down a touch would result in the same bitrate and that is what matters to the camera. Once he understands how to configure the timers, then I don't see why it would be an issue.

[nanomad]

Don't confuse sensor readout speed with encoder speed, it takes twice the time to read a FullHD frame vs a 720p one

[P337]

True, unless it reads the entire sensor 60 times per second then scales for 720p ...or does it just skip more lines to begin with?

Also my "LiveV FPS" usually displays 60fps, but I'm not entirely sure what that means yet lol.

[Digital Corpus]

Don't confuse sensor readout speed with encoder speed, it takes twice the time to read a FullHD frame vs a 720p one

True, I had only considered the bandwidth of the bus, not the speed of the encoder. Thanks for the logic check.

I hope the hardware is up to encoding quickly enough for the task

[ideimos]

Regarding bitrate and cropmarks, I was wondering if it would be useful for example to have the option to record only the 2.35:1 frame area, and keep the rest black. That could improve bitrate efficency.

In any case, ML is an amazing work, BIG thanks and keep going.

[nanomad]

Are you suggesting to feed the "black cropmarks" to the encoder too? I think it's feasible (a1ex knows better), but I'm not so sure it would actually improve anything. I think the encoder will just go for a lower average bitrate due to a portion of the scene being a static black image

[a1ex]

Well... I'm pretty sure the CPU power needed to do this will negate any improvement and could cause jitter issues or maybe worse.