First 7D alpha released!

[StefanKeller.AC]

I had this two times! (in good light-conditions) 
After first restart AF worked for 2 or 3 pictured than failed again, center AF-Point worked, after restart it works with and without ML...

yesterday again the same failure, after about 500 pics without ML,
I tried started ML and after some shots the AF of the outer points refused to work
Lens is a EF-s 17-55/2.8.
can I do some tests or logging for you when this happens again?

[dutchguy]

I tried reproducing the focusing problem once, but I could not reproduce it. I will try it some more when I have time.

[unimatrix098]

Once they get the decompiling software they need development will really speed up. Unfortunately it's really expensive so it's up to us to raise the money for it. I think they're fairly close to their goal and I plan on contributing a large sum pretty soon but it'd be cool if everyone that downloads ML could throw these guys a little support. I "imagine" they'd be able to get 70% working well before a year but that also depends on how quickly this software comes through for them too. The software will also aid in the development of all the other bodies as well AFAIK.

Hi, thank you for the great response! So I can look at a 7D as an option to buy and have ML in the near future. If I manage to buy it, I will try to help. But for now I can help by reviving my Paypal account and make a donation. Thank you for making the AWESOME Magic Lantern a reality! 

[imrantshah]

 
Thank you! Much excited for the release!
umm.. I cant seem to find the intervalometer.. its my first time using ML, is it just me that cant find the intervalometer or was it not included in this release?

[cbrgta]

Thank you! Much excited for the release!
umm.. I cant seem to find the intervalometer.. its my first time using ML, is it just me that cant find the intervalometer or was it not included in this release?

not included in the first alpha. looks like it might be available in the second alpha

[beej]

umm.. I cant seem to find the intervalometer.. its my first time using ML, is it just me that cant find the intervalometer or was it not included in this release?

The first post in this thread details what is and what isn't in this alpha version.

[imrantshah]

The first post in this thread details what is and what isn't in this alpha version.

With all due respect, maybe if you read, it also says:
"* and a lot more"

[Digital Corpus]

Found 2 bugs, but I'm not sure how important they are atm. I need to do some testing to determine which file writing issue is the one complaining and the other is one that requires a little digging to fix, I assume.

In brevity, poping a card into a 7D from a different Canon presents with a "dir error" but can still record video just fine. I noticed that this is prevalent to having Sensor Cleaning turned on, but w/o it seems to fix itself sometimes. I have to do more digging and testing when I'm back from vacation. Thought I lost 6 videos and about a dozen shots as a result of this. However, I had data recovery with me and then found out it's just being quirky.

Next up *should* be a simple fix. It is assumed that all movies start with "MVI", when in fact this can now be changed in v2 of the 7D's firmware. It's equivalent to ano annoyance so no rush to fix it.


I wanted to respond to the bit rate topic in general. First, as a forward I'm not a developer but I'll borrow the term "observant user" from another on here, I've had several years mucking around with x264 for encoding my own video for archival of TV shows on my server. I've followed the developement heavily a few years back and learned a few things from their forums. Generally speaking, lossy encoded video can easily be encoded at a near perceptibly-lossless quality at a data rate of 1 bit per pixel. H.264 uses a YUV image formate if memory serves. It's not encoded as RGB. The type of video format (wrong term, but I think you guys get the gist of it) is 4:2:0. This means that the color information is saved at 1/4th resolution of the luminosity information. An RGB image, like a JPEG or PNG or BMP is equivalent to 4:4:4, aside from any other forms of data compression applied to the image. To adjust the math from another user, this means that the total color in one of the 7D's video frames is 1/2 the amount of data as luminosity (1/4 res. color + 1/4 res. color = 1/2 res. luminosity). The numbers look a bit like this

1920*1080 x1 luminosity channel
960*540 x2 color channels

2073600 luminosity pixels
518400 x2 color pixels

Generally speaking our images are being recorded with 8 bit color depth across the 2 color channels and luminosity channel, and all at 24 fps (23.976, but for the sake of argument, let's keep the numbers simple right now )

8 bit depth, 2 color channels, 1 luminosity channel
24 fps

This gives us a total of 597,196,800 bits/sec required for uncompressed frames at 4:2:0. This number is half the previous one mentioned because it was assumed that we had RGB channels at full resolution when the image format for video is a little different.

Now remember me mentioning the 1 bit per pixel (bpp for short) for lossy encoded video? Take out number above, convert the 8 bits to 1 bit by dividing by 8, and that gives us a theoretical maximum bit rate of 74,649,600 bps or ~74.7 Mbps for optimal imformation capture. Granted, there are inefficiencies so going up to 100 Mbps should be okay, but 200-250 Mbps might be a touch excessive .


Now, the 4 GB limit bugs me. I know why it's there and I understand how it is a limitation when looking at the *whole* file. But when it comes to the 7D writing the data down to the file, is there any way we can hijack this process a little, because it's a bit retarded. When I recorded TV, the data stream can just keep writing data past the 4 GB limit because it's not caring about the file size. I didn't have any problems reading a 7 GB file on a Win XP or Mac OS computer. If it possible to just have the camera just write the data out, then the 4GB limit for writing a stream of data is irrelevant.

[P337]

Now remember me mentioning the 1 bit per pixel (bpp for short) for lossy encoded video? Take out number above, convert the 8 bits to 1 bit by dividing by 8, and that gives us a theoretical maximum bit rate of 74,649,600 bps or ~74.7 Mbps for optimal imformation capture. Granted, there are inefficiencies so going up to 100 Mbps should be okay, but 200-250 Mbps might be a touch excessive .

Thanks Digital Corpus!  You have obviously done a lot of homework on the subject but as you said each channel is 8-bit and each pixel has 3 channels (Y' Cb and Cr) so that's 24bits per pixel (3 8bit channels = 8+8+8) so wouldn't that be dividing by 24 in that theory? and I think it's Bpp(1 Byte per pixel) not bpp(1 bit per pixel) it's, but Bpp is uncompressed.

Anyway I tried crunching the numbers myself and this what I got:
Frame size: 1920x1080 resolution = 2,073,600 pixels

8bit Y' Channel: 1920x1080 resolution = 2,073,600 pixels * 8bits per pixel = 16,588,800 bits per frame
8bit Cb Channel: 960x540 resolution = 518,400 pixels * 8bits per pixel = 4,147,200 bits per frame
8bit Cr Channel: 960x540 resolution = 518,400 pixels * 8bits per pixel = 4,147,200 bits per frame

Total "YUV" Channels: (2,073,600 Y' pixels + 518,400 Cb pixels +518,400 Cr pixels) = 3,110,400 pixels * 8bits per pixel = 24,883,200 bits per frame (OR 3,110,400 Bytes which is 1 Byte per pixel)

Frame rate: 23.976 frames per second * 24,883,200 bits per frame = 596,599,603.2 bits per second

So 4:2:0 color encoding requires 597 Mbps to be recored "uncompressed".

Now H.264 has some compression method tricks up it's sleeve that I won't get into (cause I don't fully understand them all lol) but I've heard the average ratios are 7:1 compression for each "I-Frame", 20:1 compression for each "P-Frame" and 50:1 for each "B-Frame".  So assuming those are correct, average data rates for H.264 are:

H.264 I-Frame Compression: 24,883,200 bits per frame / 7 = 3,554,743 bits per frame (rounded up)
H.264 P-Frame Compression: 24,883,200 bits per frame / 20 = 1,244,160 bits per frame
H.264 B-Frame Compression: 24,883,200 bits per frame / 50 =  497,660 bits per frame

The 7D's H.264's compression mode is IPP and it records 24fps in GOP12 like this (IPPPPPPPPPPPIPPPPPPPPPPP for each second). That's 2 "I-Frames" and 22 "P-Frames" per second:

24fps IPP I-Frame data rate: 3,554,743 bits per "I-Frame" * 2 = 7,109,486 bits per second
24fps IPP P-Frame data rate: 1,244,160 bits per "P-Frame" * 22 = 27,371,520 bits per second
Total 24fps IPP data rate: (2 I-Frames) 7,109,486 bits per second + (22 P-Frames) 27,371,520 bits per second = 34,481,006 bits per second

So, if those "average compression ratios" for H.264 are correct then H.264 IPP at 24fps requires an average of 35 Mbps, a 17.4:1 compression of 1080p 4:2:0.  If we get "All-I" (Intra) working the average compression rate that should be used is 85,313,832 bits per second (86 Mbps) for a 7:1 compression.  Remember to get 4:2:0 subsampling to a 1:1 compression rate requires 597 Mbps.  So if we get Intra at 200Mbps that should give us a 1080p 4:2:0 image at about a 3:1 compression ratio ;-D

[Digital Corpus]

Anyway I tried crunching the numbers myself and this what I got:
Frame size: 1920x1080 resolution = 2,073,600 pixels

8bit Y' Channel: 1920x1080 resolution = 2,073,600 pixels * 8bits per pixel = 16,588,800 bits per frame
8bit Cb Channel: 960x540 resolution = 518,400 pixels * 8bits per pixel = 4,147,200 bits per frame
8bit Cr Channel: 960x540 resolution = 518,400 pixels * 8bits per pixel = 4,147,200 bits per frame

Perfect!

Total "YUV" Channels: (Y'+Cb+Cr=) 3840x2160 resolution = (Y'+Cb+Cr=) 8,294,400 pixels * (Y'+Cb+Cr=) 24bits per pixel = 33,177,600 bits per frame

First, 3840x2160 * 24 bpp = 8,294,400 * 24 = 19,9065,600 bits per frame based on that math.
You're close, but you forgot your order of operations, PEMDAS: Parenthases, Exponents, Multiply, Divide, Add, Substract; so a few things are off here.

When you summed the frame's components (yes, it's YCbCr, similar to YUV but I know YUV was close enough to jog someone elses memory for which it was, thanks You added up the dimensions 1920+960+960=3840 and then you multipled them together. You have to multiply them out first and then sum them.

This means Y'+Cb+Cr = 2,073,600 + 518,400 + 518,400 = 3,110,400 pixels of data we're looking at per frame, not 8,294,400 pixels.

Your initial math up on top is perfect so I don't know where you psyched yourself out and deviated from what you had. You summed your 8 bits per pixel before you multiplied them. Thus you computed a video frame that had a 24-bit depth. Damn, I *wish* the 7D could do that kind of dynamic range . A logical overview could explain the reasoning of your number based on doing file size calculations for the rendered frame in RGB, however. Each channel has an 8-bit color depth so you want to multiply each channel by 8 (2^8 = 256 which we love/hate for dynamic range). So...

Since:
2,073,600 * 8 + 518,400 * 8 + 518,400 * 8 = 8 * (2,073,600 + 518,400 + 518,400) = 8-bit depth * 3,110,400 pixels in a frame = 24,883,200 bits per frame

You'll note that this is the same as 16,588,800 + 4,147,200 + 4,147,200 (your numbers!) = 24,883,200 bits per frame

This next part then changes to:
Frame rate: 23.976 frames per second * 24,883,200 bits per frame = 596,599,603.2 bits per second
for uncompressed 1080p @ 4:2:0. For the rest of it, I'll round up to 24 fps to keep it a little simpler. This pushes the bps to 597,196,800 or ~597.2 Mbps

I've seen those same compression ratios. Adjusted numbers for the frame size put
H.264 I-Frame ~= 3,554,742.857 bits
H.264 P-Frame = 1,244,160 bits
H.264 B-Frame = 497,664 bits

1 sec of H.264 video with 2 I-Frames and 22 P-Frames is then ~7109485.714 bits + 27,371,520 bits = 34,481,005.714 bits.
If we had all I-Frame compression, that would then be ~85.3 Mbps. For a GOP of 3, which we know is doable, we'd get ~48.34 Mbps

From the content that I've recorded from my 7D already , I've seen data rates from 41-47 Mbps. We then know that Canon is overprovisioning a bit as it is. If I scale up the ~34.48 Mbps up to an assumed target average of 45 Mbps, then all I-Frame compression gives us a target of ~111.3 Mbps and GOP=3 data rate of ~63.09 Mpbs. Considering the ~597.2 Mbps for an uncompressed frame, that would give us a ~9.47:1 compression ratio compared to ~13.27:1 stock compression ratio.

B-Frames are out of the question since the encoder is hardware, not software. As the DIGIC chips haven't been fully cracked, then the hardware encoders are probably a bit futher off, though maybe this circuitry is in the DIGIC chips? My initial guestimate of 100 Mbps video being sufficient for the capabilities of the camera still match with the assumed ~63 Mbps of a GOP=3 scene. The best way to get better quality is seeing if the encoder can do 4:2:2 sampling and give us color detail back. This would inflate the frame size by 25%, thus our data rate as well. Our ~63 Mbps would go to ~78-79 Mbps, still under the 100 Mbps.

[Digital Corpus]

A more finite concern is the 7D's actual resolving power. I can scale a 1080p frame down to 720p, sharpen, and scale it back up to 1080p and scale it back up to 1080p and it's very hard to tell the difference between the two. Granted the camera can resolve pixel level detail at 18 MP and a 1080p frames is ~2.1 MP. Canon does some detail blurring when sharpenss is turned on and this removes quite a bit of aliasing, but not enough to remove moire. I now own a VAF-7D from Mosaic Engineering. When I get home from my travels/vacation/holiday, I'm going to do some pixel peeping to see to what degree it provides anti-aliasing. Prior to its use, I noticed that there is are quite a bit of scaling artifacts when sharpening is turned off. However, those were mitigated when sharpening was on 1. The VAF-7D might allow greating resolving power when sharpening turned off since we then don't have to deal with a smoothed then sharpened image with sharpening turned on. Plus it removes 80% of moire so I'm good with that

As for practicality, ignoring the 4 GB limit of FAT 32 is a more admirable goal. If there is anyway we can alter the paradigm of the file writing to make it behaving like a stream of data being written w/o prior knowledge of the begining of the file, then the 4 GB limit becomes moot. Granted, this might break playback of the files on the camera, but it would solve the scene time issue when recording at a higher bitrate.

But anyhow, I an anxiously awaiting alpha 2 and cannot wait to get home so I can help with bug testing .

[g3gg0]

uuuhhhh errrh. too much text for me

what is the advantage of all-I anyway?
about 90% of the P-frames are I-Macroblocks anyway.

setting GOP to 1 will enforce that all blocks (even ones that can be predicted very good) are definitely I-blocks.
this will improve only 10% of the single frames a little.
whereas increasing bit rate will improve quality of all macroblocks (I and P).

combining both would maybe give the best results.


@1%:
where did you patch the 600D to get all-I?
i found the GOP size variable but there are several checks for 12 and 15.
i would rather patch that somewhere in encoder routines so that canon firmware doesnt see that change.

[Northwinds]

Successfully used the alpha on Friday night videoing my friends' club for a promo.

The Focus peaks were extremely useful in a low light club situation and I found it easier to use in grayscale mode with the peak colour set to yellow. Last time I filmed a club with the 7D the focus was a bit hit and miss but this has really changed the results!

I will be donating in the next couple of days once I've been to the bank as this is a brilliant and well thought out firmware in my opinion - many thanks!

My only request (right now) from a video standpoint (as opposed to stills) woud be for some way of changing the frame rate for 1280 by 780 from 50 to 25.
I was carrying a lot with me on Friday so didn't bring my own laptop for downoading and the one I was told I could use ended up being used for a ticket scanner at the club entrance so I had to be very choosey as to what I did actually shoot as i only had 3 CF cards with me.
Considering this club footage is intended mainly for the web I don't really need 50fps and would much rather have the option of doubling my card usage in this scenario.

But otherwise brilliant!
Many thanks!

[P337]

Your initial math up on top is perfect so I don't know where you psyched yourself out and deviated from what you had. You summed your 8 bits per pixel before you multiplied them. Thus you computed a video frame that had a 24-bit depth. Damn, I *wish* the 7D could do that kind of dynamic range . A logical overview could explain the reasoning of your number based on doing file size calculations for the rendered frame in RGB, however. Each channel has an 8-bit color depth so you want to multiply each channel by 8 (2^8 = 256 which we love/hate for dynamic range). So...

Thanks again Digital Corpus!
I got lazy and added the resolutions together instead of the actual pixels lol
~((1920x1080+(960x540)*2) instead of ((2,073,600+(518,400*2)) 

I also adjusted the equation to keep all the channels 8bit, which sounds right, but still seems counter intuitive to me lol. (Can anyone explain why 3 8bit channels working together in one pixel still equals 8 bits per pixel?)

so now I get:
597 Mbps for a true 1:1 compression of a 1080p 4:2:0 image at 24fps
35 Mbps for the average 17:1 compression with "IPP" (Which is Canon's stock settings)
86 Mbps for the average 7:1 compression used for "All-I" (Canon gives around 95 Mbps for the 5D3 "All-I" mode)
and
We've seen the 7D maxed at about 250 Mbps which is about a 2.5:1 compression!

[P337]

uuuhhhh errrh. too much text for me

what is the advantage of all-I anyway?
about 90% of the P-frames are I-Macroblocks anyway.

setting GOP to 1 will enforce that all blocks (even ones that can be predicted very good) are definitely I-blocks.
this will improve only 10% of the single frames a little.
whereas increasing bit rate will improve quality of all macroblocks (I and P).

combining both would maybe give the best results.


@1%:
where did you patch the 600D to get all-I?
i found the GOP size variable but there are several checks for 12 and 15.
i would rather patch that somewhere in encoder routines so that canon firmware doesnt see that change.

@g3gg0
Well I agree that higher bitrates for IPP is more important than All-I, but since All-I "does less compression work" and since most compression artifact and glitches happens due to round off errors during compression it would be expected that All-I would reduce the opportunity for artifacts. 

The problem is that All-I needs quite a bit more bandwidth than IPP and if it doesn't get it then most fine details get lost in the "All-I process". For example, the GH2 with h.264 IPB at 88 Mbps gave a near 1:1 compression look but the 5D3 with h.264 All-I at 95 Mbps didn't.

Also about that GOP sizes, according to this: (http://learn.usa.canon.com/resources/articles/2012/ipp_ipb_all_i_compare.htmlp
) Canon's Interframe Codec uses GOP12 for 24fps and GOP15 for 30fps or 60fps.

The IPP compression method is used in many existing EOS models like the Canon EOS 5D Mark II, EOS 7D, 60D, and Rebel series models. This compresses video files in a way similar to that described immediately above. At 30 fps, the first frame in a group of 15 is a key frame, and the next 14 are predicted, based entirely on the data from the previous key frame and preceding predicted frames. With this compression method, each group of 15 frames (at 30 fps) is stored in what is known as a Group of Pictures (GOP). The drawback to this method is that frame-by-frame editing often results in slightly lower image quality.

[g3gg0]

see nitrate thread - i will post a new experimental version.
please move all bitrate and MPEG discussion there.

btw - its up to nearly 300MBit/s

[CaptainHook]

what is the advantage of all-I anyway?

In general? VFX work where having each frame is important. High motion footage. Less taxing on CPU. I'm sure everyone has read that stuff, so maybe the question was more direct to the math discussion above? In which case, i'm out. 

[P337]

btw - its up to nearly 300MBit/s

!

...2/1 compression

[Discopunx]

Hi all,

I have a Problem: I can not copy the Firmware to the root directory (Windows 7). It seems the root directory is write protected when I formatted my cf card with the camera.

[ilguercio]

Hi all,

I have a Problem: I can not copy the Firmware to the root directory (Windows 7). It seems the root directory is write protected when I formatted my cf card with the camera.

Are you using a card reader?

[Discopunx]

i tried both....camera and card-reader (in my printer). And google can´t help me :-D I thought I would not be the only one with this problem.

[nanomad]

You need to use a REAL card reader 

[Discopunx]

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  :-)

[fotto]

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.

[jplxpto]

Have fun! \o/

LoL