Author Topic: 7D at Halloween: The Bitrate-Monster (EXPERIMENTAL)  (Read 126149 times)

StefanKeller.AC

  • Freshman
  • **
  • Posts: 54
Re: 7D at Halloween: The Bitrate-Monster (EXPERIMENTAL)
« Reply #100 on: November 04, 2012, 11:19:26 AM »
how can I switch Audio recording of ?

g3gg0

  • Developer
  • Hero Member
  • *****
  • Posts: 3157
Re: 7D at Halloween: The Bitrate-Monster (EXPERIMENTAL)
« Reply #101 on: November 04, 2012, 11:22:34 AM »
how can I switch Audio recording of ?

in canon menu. audio recording off instead of automatic.
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: paypal@g3gg0.de
ONLY donate for things we have done, not for things you expect!

Digital Corpus

  • Freshman
  • **
  • Posts: 66
Re: 7D at Halloween: The Bitrate-Monster (EXPERIMENTAL)
« Reply #102 on: November 04, 2012, 12:22:45 PM »
If you have a super fast card I recommend setting CBR to 20x and Flush to 1.  Then enable spotmeter and select the 0-255 option.  Then set ISO to 128,000 and use your shutter or ND filters to underexpose to "25" on the 0-255 spotmeter.  This always shoots my bitrate up to it's max but my cards, which are "200x" 170Mbps (21MB/s)*, peak at 200 Mbps for 1 second then the buffer can't keep up** so the recording stops :/

*ML Benchmarked my card at 21.5MB/s
**my Flush rate is set to 2 (my camera throws err70 if flush=1)
What is the significance of setting the flush rate so much lower? Is it useful so that when we record at a higher bitrate we won't overflow the buffer? If that's all, I would keep the flush rate at 2-4. I didn't have a single issue in my dozen or so test recordings that were all 150-200 Mbps. Setting it to a lower flush rate requires a faster card. Not in terms of bandwidth, but latency of access. Use the buffer as a buffer and it'll behave properly.

I am using SanDisk's Extreme 16 GB cards. You can get them on sale at ~$50, normally at $60. For the price vs performance, it's hard to beat this card. Have a look here:
http://www.robgalbraith.com/bins/camera_wb_multi_page.asp?cid=6007-10294
For comparing all of the cards. This has been the most reliable site for card performace. Caveat: Rob has retired the website. This happened before rumors of the 2.0 firmware that Canon released which drastically improved memory handling and thus performance. However, it's a solid baseline for at least another 6 months.


You shouldn't have to use CBR only, set qscale to max (do you guys have that yet?) and then camera records at fixed quality. All frames will be QP10.

There is no such thing as real CBR on canon anyways. Its all VBR just with constraints via quality/qp H264 parameters. You're not directly controlling the rate, you're just telling the camera "even if frame size is *friggin huge* pick a high QP for the next frame.
Fixed quality would be fixed quantizer, which would be VBR, no? Due to general ignorance (which it looks like you guys do a really good job at helping alleviate) most think that CBR > VBR in terms of quality. However, VBR > CBR because it's much closer to assuming fixed quality for each frame. THis really is a better mode to record in.


Thanks 1%
Does that mean a static scene may just ignore "CBR" settings and base it off the first frame's complexity?
Well I don't have a problem maxing out the bitrate indoors, by underexposing with ISO set to 128000, which get my card's full 160Mbps but it's too noisy so I'm trying to get that max bitrate with proper exposure.
Go find some grass. First attempts at all I-Frame encoding gave me ~230 Mbps. I haven't gotten around to 'CBR' testing yet.


@1%:
> You guys haven't pushed luma/chroma quality up yet
you mean QP(Y;U;V)? that is according to analysis tools exactly the same as QP (10).

one correction: you said, camera flushes after each GOP - you meant after each two GOPs, as this is one second :)
at least via x.264, you could control the quantizer based off of scalar values. Do you guys have controls equivalent to deadzone_inter, deadzone_intra, and chroma_qp_offset?


to explain myself the way how the encoding works and what i am tuning, i made some screenshots.
...
thats the reason why I-frames eat so much bandwith without huge improvements.
It took me a long while to understand this process back in the day when I first started working with video encoding. This explanation you just gave is perhapse the best I've ever seen online. It'll be a valuable resource for those just starting out trying to figure out what mode to use.

As a followup to restate what others have said, the chief reason why all-I is required is for special effects work. Most pieces of software that do this need to cut into a video at an I-Frame and not havfing to wait 3, 4, 5, 10 frames later works much more easily without losing quality
7D w/ ML | Tokina ATX 11-16 | Canon 24 mm pancake | Canon 40 mm pancake | Canon 17-55 f/2.8 IS | Sigma 150-600 Sports

feureau

  • Hero Member
  • *****
  • Posts: 604
Re: 7D at Halloween: The Bitrate-Monster (EXPERIMENTAL)
« Reply #103 on: November 04, 2012, 01:10:16 PM »
As a followup to restate what others have said, the chief reason why all-I is required is for special effects work. Most pieces of software that do this need to cut into a video at an I-Frame and not havfing to wait 3, 4, 5, 10 frames later works much more easily without losing quality

Yep. It also helps when color correcting. I like All-I.

xmd5a

  • New to the forum
  • *
  • Posts: 25
Re: 7D at Halloween: The Bitrate-Monster (EXPERIMENTAL)
« Reply #104 on: November 04, 2012, 03:15:19 PM »
Noticed than Magic Zoom no more flickers. Also when REC/STBY notification is set to "Red Crossout" red box does not disappears properly when recording is started. Got a "dir error" message after Err70. "Flush rate" setting does not restores after reboot. True VBR feature is very useful.

g3gg0

  • Developer
  • Hero Member
  • *****
  • Posts: 3157
Re: 7D at Halloween: The Bitrate-Monster (EXPERIMENTAL)
« Reply #105 on: November 04, 2012, 03:44:46 PM »
at least via x.264, you could control the quantizer based off of scalar values. Do you guys have controls equivalent to deadzone_inter, deadzone_intra, and chroma_qp_offset?

It took me a long while to understand this process back in the day when I first started working with video encoding. This explanation you just gave is perhapse the best I've ever seen online. It'll be a valuable resource for those just starting out trying to figure out what mode to use.

As a followup to restate what others have said, the chief reason why all-I is required is for special effects work. Most pieces of software that do this need to cut into a video at an I-Frame and not havfing to wait 3, 4, 5, 10 frames later works much more easily without losing quality

thanks :) i hope that was correct.
its just high-levle explained by watching what i see. not sure if that is the corrent process

about those quantizer parameters. i am sure we have access to them, its just hard to identify them.
we are looking for canon dev's log/assert messages to find them.
maybe the 5D3 ini file and the registers where data goes to will help.
what would you expect from the parameters you said?

yes all-i is good for post. so i think the best is to configure the GOP size.
the ones wo dont do post will benefit from better details with larger GOP groups.

the others can choose all-i for post processing.
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: paypal@g3gg0.de
ONLY donate for things we have done, not for things you expect!

feureau

  • Hero Member
  • *****
  • Posts: 604
Re: 7D at Halloween: The Bitrate-Monster (EXPERIMENTAL)
« Reply #106 on: November 04, 2012, 03:52:49 PM »
"Flush rate" setting does not restores after reboot.

I thought I was the only one having this issue. :D Yep, flush rate kept defaulting to 4 after restart on mine too...

Digital Corpus

  • Freshman
  • **
  • Posts: 66
Re: 7D at Halloween: The Bitrate-Monster (EXPERIMENTAL)
« Reply #107 on: November 04, 2012, 04:03:15 PM »
thanks :) i hope that was correct.
its just high-levle explained by watching what i see. not sure if that is the corrent process
As far as I know it's dead on. The difference between I, P, and B frames is fairly simple. It's the algorithms used to determine which macroblock does what that makes things become very complex very quickly.

about those quantizer parameters. i am sure we have access to them, its just hard to identify them.
we are looking for canon dev's log/assert messages to find them.
maybe the 5D3 ini file and the registers where data goes to will help.
what would you expect from the parameters you said?

chroma_qp_offset
Chroma requires less detail since the human eye is more sensitive to detail/luminosity than it is color. Thus color information does not need to be encoded with the same quality. However, green/blue screen scenes will benefit from this being increased.

As for the deadzone parameters, they affect small, fine details and grain/noise retention. They can help when shooting at high ISO to aid in not flattening ISO noise into a macroblock to help clean up the frames. For a more complete description, here is a copy & paste from the man page.
Quote
deadzone_inter=<0−32>
Set the size of the inter luma quantization deadzone for non-trellis quantization (default: 21). Lower values help to preserve fine details and film grain (typically useful for high bitrate/quality encode), while higher values help filter out these details to save bits that can be spent again on other macroblocks and frames (typically useful for bitrate-starved encodes). It is recommended that you start by tweaking deadzone_intra before changing this parameter.

deadzone_intra=<0−32>
Set the size of the intra luma quantization deadzone for non-trellis quantization (default: 11). This option has the same effect as deadzone_inter except that it affects intra frames. It is recommended that you start by tweaking this parameter before changing deadzone_inter.

yes all-i is good for post. so i think the best is to configure the GOP size.
the ones wo dont do post will benefit from better details with larger GOP groups.

the others can choose all-i for post processing.
Yeah, I'd like this one a lot. Because P-frames are a lot less expensive to encode, it's easier to save bits and increase quality with this.

I noticed earlier comments about how the interval of when Canon's firmware flushes frames in terms of GOP size. Does this account for why an Err 70 occurs when trying to record audio under this [alpha] firmware?

I thought I was the only one having this issue. :D Yep, flush rate kept defaulting to 4 after restart on mine too...
I can confirm as well with the initial CBR firmware you posted. I haven't check the all I-Frame or most recent one you posted in the past couple of days.
7D w/ ML | Tokina ATX 11-16 | Canon 24 mm pancake | Canon 40 mm pancake | Canon 17-55 f/2.8 IS | Sigma 150-600 Sports

Digital Corpus

  • Freshman
  • **
  • Posts: 66
Re: 7D at Halloween: The Bitrate-Monster (EXPERIMENTAL)
« Reply #108 on: November 04, 2012, 04:13:30 PM »
Is there any reason that 422 JPEG recording makes sense?

Let's look at Canon's 1056x704 live view:
This resolution is acquired at the sensor by line skipping: every five rows are read from a sensor area of 5202x3465 (3:2).
The resulting 5202x693 RAW is demosaiced and rescaled to 1056x704 4:2:2 for live view.
A 5202x693 bayer sensor has a chroma resolution of 2601x396.
The final resolution is the minimum of every step above: 1056x693 luma resolution, and 528x396 chroma resolution. Vertical chroma resolution is limited by bayer line skipping.

5202x693 RAW Bayer -> 5202x693 Y / 2601x396 UV [assuming 2x2 superpixel required for chroma determination]
1056x704 422 YUV -> 1056x704 Y / 528x704 UV

We can also look at the 1728x792 recording live view:
This resolution is acquired at the sensor by line skipping: every three rows are read from a sensor area of 5202x2925 (16:9).
The resulting image, 5202x975, is demosaiced and rescaled to 1728x792.
A 5202x975 bayer sensor has a chroma resolution of 2601x487.
The final resolution is the minimum of every step above: 1728x792 luma resolution, and 864x487 chroma resolution. Again, line skipping limits our vertical chroma resolution.

5202x975 RAW Bayer -> 5202x975 Y / 2601x487 UV [assuming 2x2 superpixel required for chroma determination]
1728x792 422 YUV -> 1728x792 Y / 864x792 UV

If the video was saved as a 1728x792 4:2:0 H.264 video, we would actually lose vertical chroma resolution. But Canon upscales this to 1920x1080 before encoding it:
A 1920x1080 4:2:0 video frame contains a 1920x1080 Y (luma) and 960x540 UV (chroma) planes.

The final resolution available is 1728x792 Y / 864x487 UV, noticing that these values fit comfortably within the resolution limits in 1920x1080 4:2:0 video. Canon's 1080p is large enough to capture all of the detail in 1920x1080 4:2:0 as provided in the 1728x792 4:2:2 (since there are only ~480 real lines of color information).
I am very very much interested into how the 7D does it's image scaling. Where did you come across this info? I'd like to look more into it especially due to tests with resolution and what have you. The upscaling explains a little bit about the softness of a 1080p frame and gives me a good base to start some testing on with and without my VAF-7D.
7D w/ ML | Tokina ATX 11-16 | Canon 24 mm pancake | Canon 40 mm pancake | Canon 17-55 f/2.8 IS | Sigma 150-600 Sports

1%

  • Developer
  • Hero Member
  • *****
  • Posts: 5936
  • 600D/6D/50D/EOSM/7D
Re: 7D at Halloween: The Bitrate-Monster (EXPERIMENTAL)
« Reply #109 on: November 04, 2012, 04:26:56 PM »
I think its mostly correct, from hours of screwing with 600D.


Quote
about those quantizer parameters.


There might be a way to access them directly, I actually hope so because then we can try QP below 10. But the parameter that both CBR and "VBR" modify is sliceqpd. It is the direct "quality" of the frame.  How sliceqpd turns into a QP of 10 (or X) on the output side I don't know, it might be internal to digic.

Quote
We can also look at the 1728x792 recording live view:

Looks like a real good interpretation on why they picked the sizes they did. So crop mode really has that little chroma resolution, wow. But does that mean the numbers won't work out to scale it to something else? Non crop HD is even more skips and a lower resolution. Looking in the logs, it says the available area is bigger, close to that 2000 size but non at 396 or 487. But also the window being used is smaller.

Code: [Select]
[GMT][WAKU] Avail WinW:H(1036:1036)->(1036:1036)
[GMT][WAKU] Avail X:Y(2920:1268)->(2920:1268)

deadzone_inter- May be D1/D2 in MVR config. But not sure what low level parameter is being modified on the hardware encoder. All I found affecting Jpcore was sliceqpd/deblocking/picqpy/picqpc.

Digital Corpus

  • Freshman
  • **
  • Posts: 66
Re: 7D at Halloween: The Bitrate-Monster (EXPERIMENTAL)
« Reply #110 on: November 04, 2012, 06:04:04 PM »
deadzone_inter- May be D1/D2 in MVR config. But not sure what low level parameter is being modified on the hardware encoder. All I found affecting Jpcore was sliceqpd/deblocking/picqpy/picqpc.
Stupid question. I cannot check because I don't have the tools with me nor the time to install them on this computer, but is there nothing stored as a header in the video files for us to peak at?
7D w/ ML | Tokina ATX 11-16 | Canon 24 mm pancake | Canon 40 mm pancake | Canon 17-55 f/2.8 IS | Sigma 150-600 Sports

Shizuka

  • New to the forum
  • *
  • Posts: 36
Re: 7D at Halloween: The Bitrate-Monster (EXPERIMENTAL)
« Reply #111 on: November 04, 2012, 06:15:12 PM »
Looks like a real good interpretation on why they picked the sizes they did. So crop mode really has that little chroma resolution, wow. But does that mean the numbers won't work out to scale it to something else? Non crop HD is even more skips and a lower resolution. Looking in the logs, it says the available area is bigger, close to that 2000 size but non at 396 or 487. But also the window being used is smaller.

Code: [Select]
[GMT][WAKU] Avail WinW:H(1036:1036)->(1036:1036)
[GMT][WAKU] Avail X:Y(2920:1268)->(2920:1268)

You kids are so pampered; back in the NTSC days, we had thirty lines of color information!

The human eye is terrible at picking out color resolution, so bayer sensors take advantage of that weakness. I wouldn't expect the "low" chroma resolution to have any visible impact. (Worst case scenario: sharp edged highly saturated objects - see footnote)

The 396/487 figures (which are estimates) are post-demosaic "chroma resolution" values, which are estimated by reducing the source resolution by two due to the assumption that a 2x2 superpixel is required to get color information for a group of pixels. The reality is somewhat murkier (think PenTile displays) - demosaicing inherently blurs in the vertical and horizontal direction. Regardless of the actual resolution, the fact that demosaicing reaches above and below the current line means that the reduced chroma resolution of 4:2:0 is probably more appropriate than 4:1:1 or 4:2:2.

TLDR: you won't find these values in the firmware because they are an estimate of the resolution; the doubled values may be lurking around though.

{footnote}
I'll use an example of 4:2:0 chroma resolution artifacts here, although it's not completely relevant. (What is relevant is a live view 4:2:2 dump - and seeing how Canon deals with chroma there)
http://upload.g3gg0.de/pub_files/ec9400781e1b25f5ff9df7cde66b96a7/mpeg_frame_1.PNG - see the red color blocking at the mop on the floor? This artifact is produced by nearest neighbor upscaling of the U and V planes to the Y plane's size. A filter to interpolate it goes a long way to reducing these artifacts. :)

Of course, the real question is: how does the Canon demosaic the sensor to 4:2:2? The cynic in me thinks that since it's going to be rescaled to video resolution anyway, there's not much reason to do a good job during the demosaic. Determining actual chroma resolution from 422 files is difficult: Canon does image processing *before* the Live View image is provided to us. I looked, I saw sharpening and scaling artifacts.

1%

  • Developer
  • Hero Member
  • *****
  • Posts: 5936
  • 600D/6D/50D/EOSM/7D
Re: 7D at Halloween: The Bitrate-Monster (EXPERIMENTAL)
« Reply #112 on: November 04, 2012, 06:40:19 PM »
Quote
how does the Canon demosaic the sensor to 4:2:2
You can look at raw 4:2:2 dumps of what the input to the encoder is. The "while recording" sizes are exactly what is being encoded.

Just drop a .422 while recording, or in my case any time in video mode. Available image from that log is full sensor size so we can probably chose the line skips. Might be worth comparing 422 at zoomed out, 3x, 5x (much smaller), 10x (very tiny), etc.

Shizuka

  • New to the forum
  • *
  • Posts: 36
Re: 7D at Halloween: The Bitrate-Monster (EXPERIMENTAL)
« Reply #113 on: November 04, 2012, 06:53:23 PM »
You can look at raw 4:2:2 dumps of what the input to the encoder is. The "while recording" sizes are exactly what is being encoded.

Just drop a .422 while recording, or in my case any time in video mode. Available image from that log is full sensor size so we can probably chose the line skips. Might be worth comparing 422 at zoomed out, 3x, 5x (much smaller), 10x (very tiny), etc.

I have a T2i, but I'll take a look at it. I noticed rescaling artifacts in 1056x704 modes, but that's the only size I've taken silent pics in.

Full image pipeline, as interpreted by me:

[Sensor] --lineskip--> [LineSkip RAW] --demosaic--> ?DIGIC image? --DIGICprocessing--> {YUV422}
This is used for live view
{YUV422} --video_rescaler--> {YUV422-to-H264} --h264_encode--> (H.264)

DIGICprocessing - sharpness, color, contrast, curves (Standard, cinestyle, flaat_10, etc.), rescaling
[raw data], ?unknown data?, {yuv data}, (compressed data)

1%

  • Developer
  • Hero Member
  • *****
  • Posts: 5936
  • 600D/6D/50D/EOSM/7D
Re: 7D at Halloween: The Bitrate-Monster (EXPERIMENTAL)
« Reply #114 on: November 04, 2012, 07:23:24 PM »
I should make some pics at all sizes. 600D can do 1728x956 down to like ~640x480 YUV size. Zoomed out is I think the same size as you have while recording.

Digital Corpus

  • Freshman
  • **
  • Posts: 66
Re: 7D at Halloween: The Bitrate-Monster (EXPERIMENTAL)
« Reply #115 on: November 04, 2012, 08:18:06 PM »
here is another experimental build.

i set GOP to 4 and enabled VBR/CBR selection.
also the flush rate is now limited to 2-50.
flush rate is on both digics set via cache hacks now - this means it is less likely to abort recording after the first 100ms, although
it is likely to happen if you start recording the first time, as the drivers seem to read some filesystem information which takes some time (?)
successive recordings will fail less likely.

what do you think about that?
i think i will make the GOP selection configurable somewhen, so you can choose your favorite.
I'm loving this new version right now. VBR is very lovely. Time for some low light video =D.
7D w/ ML | Tokina ATX 11-16 | Canon 24 mm pancake | Canon 40 mm pancake | Canon 17-55 f/2.8 IS | Sigma 150-600 Sports

Shizuka

  • New to the forum
  • *
  • Posts: 36
Re: 7D at Halloween: The Bitrate-Monster (EXPERIMENTAL)
« Reply #116 on: November 04, 2012, 09:45:48 PM »
Got 422s from my T2i. Turns out I was using the wrong values for FullHD live view image resolution, but it's the same idea.

1720x974 and 1056x704 - not scaled at all :)
1024x680 - scaled! (5x / 10x zoom modes) - massive bilinear resize artifacting - don't use this mode!

--

Now with a 1720x974 figure, we can take a look at how Canon does it:
5202 x 3465 sensor -> 5160 x 2922 16:9 sensor -> 5160 x 974 every-3-horizontal-lineskipped sensor
This is assuming Canon actually does full reads for each line, instead of skipping every three pixels...

I'm not sure whether the demosaic engine does vertical line skipping. If it does:
5202 x 3465 sensor -> 5160 x 2922 16:9 sensor -> 1720 x 974 every-3-horiz+vert-lineskipped sensor
That's a very familiar resolution, don't you think?
We would also see massive moire / aliasing in the vertical direction. I didn't see this, so I think Canon isn't doing vertical line skipping.

My guess is Canon thought they might have to do H+V line skipping, but did not end up needing to.

Also, ML 2.2 had FullHD silent picture. Was this feature removed in ML 2.3, or is there some other way to access it without actually recording a movie?

ideimos

  • New to the forum
  • *
  • Posts: 7
Re: 7D at Halloween: The Bitrate-Monster (EXPERIMENTAL)
« Reply #117 on: November 06, 2012, 10:24:42 AM »
Tried with Sandisk Extreme CF with no issues at x20. Crisp detail improvement is AMAZING, but for any reason, soft detail looks very close to Canon's default bitrate (blocky). Can't decide between regular mode or ALL-I. Can't wait to go home and do more testing.

It stills drive me crazy that a 25mbps HDV looks better in detail and compression artifacts than a Canon's 50mpbs+ H.264.
Is this beacuse of the encoder Canon uses? settings?

g3gg0

  • Developer
  • Hero Member
  • *****
  • Posts: 3157
Re: 7D at Halloween: The Bitrate-Monster (EXPERIMENTAL)
« Reply #118 on: November 06, 2012, 10:46:04 AM »
soft detail looks very close to Canon's default bitrate (blocky).

maybe i can play with deblocking.
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: paypal@g3gg0.de
ONLY donate for things we have done, not for things you expect!

Shizuka

  • New to the forum
  • *
  • Posts: 36
Re: 7D at Halloween: The Bitrate-Monster (EXPERIMENTAL)
« Reply #119 on: November 06, 2012, 05:21:22 PM »
Is this beacuse of the encoder Canon uses? settings?

Canon's encoder uses the bare minimum subset of H.264 in order to say they use H.264. No B-frames, no CABAC compression, only one reference frame... and worst of all, no adaptive quantization, which spends bits in areas that needs them the most.

ideimos

  • New to the forum
  • *
  • Posts: 7
Re: 7D at Halloween: The Bitrate-Monster (EXPERIMENTAL)
« Reply #120 on: November 06, 2012, 10:02:10 PM »
Canon's encoder uses the bare minimum subset of H.264 in order to say they use H.264. No B-frames, no CABAC compression, only one reference frame... and worst of all, no adaptive quantization, which spends bits in areas that needs them the most.
Makes sense. Thanks for the explanation.

Digital Corpus

  • Freshman
  • **
  • Posts: 66
Re: 7D at Halloween: The Bitrate-Monster (EXPERIMENTAL)
« Reply #121 on: November 07, 2012, 02:29:47 PM »
...
Now with a 1720x974 figure, we can take a look at how Canon does it:
5202 x 3465 sensor -> 5160 x 2922 16:9 sensor -> 5160 x 974 every-3-horizontal-lineskipped sensor
This is assuming Canon actually does full reads for each line, instead of skipping every three pixels...
...
Aside form line skipping, there is pixel binning. Effective pixel count of the sensors is 5184x3456. However, DXO reports 5360x3515 for the 7D and DP Review states that the T2i's sensor is just a little different than the 7D's. Despite the same effective resolution, it is possible that the skipping and binning is a little different between the two.

On a similar note, according to Cambridge in Color, the aperture range where we may start to see loss in resolution is f/19 to ~f/28. However, our sensor is not 2.1 MP so there may be some interesting results as we hit that range. This is next on my list of things to test which are currently

1) Visually perceptible difference between the 7D w/ & w/o the VAF-7D
1.1) Pixel peeping difference as well
2) Tests to try and establish the pattern for which Canon skips rows of pixels and bins them together to help more finely establish resolution information
2.1) Establish the same baseline for 720p recording, which currently suffers from horizontal scaling artifacts
3) Test theoretical diffraction limits of 2 and see how the image holds up.
7D w/ ML | Tokina ATX 11-16 | Canon 24 mm pancake | Canon 40 mm pancake | Canon 17-55 f/2.8 IS | Sigma 150-600 Sports

Shizuka

  • New to the forum
  • *
  • Posts: 36
Re: 7D at Halloween: The Bitrate-Monster (EXPERIMENTAL)
« Reply #122 on: November 07, 2012, 11:21:08 PM »
Aside form line skipping, there is pixel binning. Effective pixel count of the sensors is 5184x3456. However, DXO reports 5360x3515 for the 7D and DP Review states that the T2i's sensor is just a little different than the 7D's. Despite the same effective resolution, it is possible that the skipping and binning is a little different between the two.

On a similar note, according to Cambridge in Color, the aperture range where we may start to see loss in resolution is f/19 to ~f/28. However, our sensor is not 2.1 MP so there may be some interesting results as we hit that range. This is next on my list of things to test which are currently

1) Visually perceptible difference between the 7D w/ & w/o the VAF-7D
1.1) Pixel peeping difference as well
2) Tests to try and establish the pattern for which Canon skips rows of pixels and bins them together to help more finely establish resolution information
2.1) Establish the same baseline for 720p recording, which currently suffers from horizontal scaling artifacts
3) Test theoretical diffraction limits of 2 and see how the image holds up.

The 7D sensor resolution figure is the number of addressable pixels on the array. Doesn't exclude the masked (always black) pixels. See http://lclevy.free.fr/cr2/#app for a table of sensor sizes - but note that the masking values are the Canon values, which exclude extreme edge pixels. More pixels can be extracted from the sensor dump. I have a modified version of dcraw available that can reveal these edge pixels.

I took a look anyway (it was a two-byte change) at the 7D vs. the T2i. The difference is that the 7D's sensor has 16 additional black mask pixels on the left side, and 16 additional total pixels. Imaging area remains the same.

I think there is horizontal line skipping and vertical pixel binning from my experiments. More interestingly, I saw vertical and horizontal stepping artifacts in the 1720x974 YUV dump from my T2i, suggesting it's possible that the movie recording YUV buffer is actually upscaled from a lower resolution.

Digital Corpus

  • Freshman
  • **
  • Posts: 66
Re: 7D at Halloween: The Bitrate-Monster (EXPERIMENTAL)
« Reply #123 on: November 12, 2012, 10:37:57 PM »
Brother doing some welding on my car
Anyway we can have ML set the flag on the video files so that RGB values from 0-15 are not crushed to black?

# Magic Lantern v2.3.NEXT.2012Nov04.7D203

Start          : 2012/11/12 12:57:16
Lens name      : EF-S17-55mm f/2.8 IS USM
ISO            : 1250
Shutter        : 1/48.194s
Aperture       : f/4.9
Focal length   : 55 mm
Focus distance : 1180 mm
White Balance  : 5500K, Magenta 0, Blue 0
Picture Style  : Marvel's Adv 3.4.1 (1,-4,-3,0)
FPS            : 23.976
Bit Rate (VBR) : QScale -12

CSV data:
Time,ISO,Shutter,Aperture,Focal_Len,Focus_Dist
12:57:16,1250,48,4.9,55,118
7D w/ ML | Tokina ATX 11-16 | Canon 24 mm pancake | Canon 40 mm pancake | Canon 17-55 f/2.8 IS | Sigma 150-600 Sports

g3gg0

  • Developer
  • Hero Member
  • *****
  • Posts: 3157
Re: 7D at Halloween: The Bitrate-Monster (EXPERIMENTAL)
« Reply #124 on: November 13, 2012, 12:17:37 AM »
well, a picture style would help you with that :)
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: paypal@g3gg0.de
ONLY donate for things we have done, not for things you expect!