Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Digital Corpus

#26
Just consolidating some information here from what I've read as I find this thread highly intoxicating, despite not owning a 5D3.

Correct me if I'm wrong here, but a RAW frame will be composed of R, G, & B channels. However since the data is not debayered, R & B are 1/2 the horizontal and vertical resolution of a debayered frame, thus 1/4 of the frame's resolution is color data for either R or B. And since G is twice as pixels than either R or B, it'd consume 1/2 of the frame's resolution is color data. Overall, this add's us to just the pixel count of what a frame is. Now, this is 14-bits per pixel data, 8-bits in a byte, 23.976 fps (simplified to 24 fps for the sake of simplicity), frame_res*14/8*24= datarate in bytes/sec.

If my understanding of the data format is sound then this is what follows so far...

For the 5D3 with the KomputerBay 1000x cards being used, we've seen:
1920x900 @ 24 fps --> 1,728,000 pixels, 14 bpp @ 24 fps --> ~69.2 MB/sec write speed requirement
1920x1080 @ 24 fps --> 2,073,600 pixels, 14 bpp @ 24 fps --> ~83.1 MB/sec write speed requirement
1920x1152 @ 24 fps --> 2,211,840 pixels, 14 bpp @ 24 fps --> ~88.6 MB/sec write speed requirement

For the 600D, the reported card I happened to miss, we've seen:
1280x400 @ 24 fps --> 512,000 pixels, 14 bpp @ 24 fps --> ~20.5 MB/sec write speed
960x540 @ 24 fps --> 518,400 pixels, 14 bpp @ 24 fps --> ~20.76 MB/sec write speed

CF and SD cards are Flash memory. There is a bit of a principle of Flash memory that *will* affect  your write speeds, and though these memory cards are not what we consider SSD's, they have to abide by the same rules.

In order to provide a proper test, also to ensure your CF/SD card wears evenly, which not all manufacturers use or advertise if they have wear leveling, you should format your memory card in a computer with a "Full" format to make sure you get real world results. Initial writes may be faster, but that won't be how the rest of the card performs during the rest of it's life.
#27
We were at a stage where the 7D could not boot ML. One day we may have access to the master ARM chip. Just need another apiphany.

EDIT: Ah, well, UDMA6 goes up to 133 MB/s. Granted the highest regular benchmarks on the 7D I've seen are at ~55MB/sec. It's been a while since I've run a ML benchmark on my cards, but I only have Sandisk's 60MB/s cards.
#28
Quote from: edwmotion on May 16, 2013, 12:10:40 AM
7D isn't compatible with UDMA 7 cards, so maybe we'll never see full HD raw video working on 7D.   :-*
Um, no...
http://www.learn.usa.canon.com/resources/blogs/2011/20110426_eos7d_firmware125.shtml

g3gg0, please continue to develope the 7D firmware. We know you have a life, some people are just impatient. Your work on the 7D has been tremendous and a lot of us want to see it continue.  The rest of us who are quiet probably understand that you're developing the RAW video and that once you get it nailed down, then you'll have more time.

I'd love to see more work on the 7D, and a full version of ML on it if you can make that happen. I hope others agree, since it's been said, but please take your time and develop something great for us. I'd donate again if the options was present.
#29
Theoretically:
Quote from: 1% on May 13, 2013, 05:37:08 AM
7D has to be coded... should work tho.

I am eager to see where this leads. Granted out developer here is the one who made the breakthrough. Patience will reward us hopefully :)
#30
Quote from: feureau on March 08, 2013, 11:55:16 AM
Not sure if this has been reported or not but, can anyone confirm this:

With ML on, on video mode, if you zoom in, the exposure shifts about +1eV.

This is highly apparent on the highlights when using cinestyle. Set it so you have a large portion of the frame that almost clip the highlights. (set it so that you clip the highlights at 1x zoom, then go down until it doesn't clip) When you hit zoom, go to the highlights and it will clip.
Go into the ML menu, go to the smilie face prefs and go into the 2nd option, LiveView zoom settings...
Look at your Auto exposure on zoom and Increase SharpContrast.
Quote from: premini on March 12, 2013, 03:40:13 PM
Hi guys. i noticed that there's an experimental binary (bitrate monster) to play around with bitrates and GOPs,
Since this binary  was released prior to this alpha2 my question is, are these bitrate tweaking possibilities available in alpha 2?
Thanks in advance!
Yes, they are in Alpha 2. You have to enable bitrate hacks in order to use them.


I'm awaiting Alpha 3 :)
#31
Quote from: xmd5a on December 26, 2012, 02:24:57 PM
Can not confirm that. Beep works.
Double checking this morning and you're correct. Works fine now :\
#32
Quick Notes. If I don't make a comment after the feature, that means it seems to work fine and I love it :)

White Balance Manipulation
ISO Manipulation

REC/STBY - Beep doesn't work, We have no Blue LED

Bracketing
Mirror Lockup Tweaks

Follow Focus via Joystick (Bug, with zoom via half shutter, follow focus does not work, will look into further)
Adjustable speed settings

Disabling x5 zoom
Increase SharpContrast (You can see if more so when zoomed in)
LiveView Zooming on Half Shutter
Focus Box Settings
LiveView Power Savings


I know these notes are sparse, but you added oh so much, it's impossible to go through it with a fine tooth comb right now :)
#33
Archived porting threads / Re: First 7D alpha released!
December 12, 2012, 08:53:03 AM
This is an alpha and has to be re-loaded after each time the camera shuts down. Please search/read the release page... It would have taken less time than registering and waiting for such a reply.
#34
Archived porting threads / Re: First 7D alpha released!
December 11, 2012, 07:34:35 AM
g3gg0,

Thank you again for the hard work you have done. It's good to see that others were able to help out and create a workaround for the shutdown bug. I'm eagerly awaiting that Alpha 2. It's not fair that the 5D MK III is ahead of us in that regard ;). Anyhow, I see commits for the intervalometer and trap focus. What else might you have in store for the next alpha? :p
#35
That's normal. Canon 'could' fix it with a firmware update, and you only need black frame subtraction in a still image to fix it, but alas... I do admit that it is a tad annoying  :-\
#36
Archived porting threads / Re: First 7D alpha released!
November 18, 2012, 11:16:46 PM
Quote from: g3gg0 on November 18, 2012, 09:34:09 PM
still hunting the nasty shutdown bug.
good luck!
#37
Archived porting threads / Re: First 7D alpha released!
November 15, 2012, 06:07:21 AM
g3gg0,

Anything we can specifically help you with the development of the 7D's ML port?
#38
But that would force me to loose information :(
#39
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
#40
Archived porting threads / Re: First 7D alpha released!
November 12, 2012, 08:58:53 PM
On my vacation I shot more than 250 little videos with ML. Not a single issue. Even with numerous Err 70's due to mucking about.
#41
Archived porting threads / Re: First 7D alpha released!
November 08, 2012, 06:17:45 PM
Quote from: juanmelchor on November 08, 2012, 02:12:48 PM
Hi! Where I can download the latest version of the experimental .FIR? I want to try it on my 7D, it is great!!  :)
Follow this thread for latest changes that could brick your camera :) Keep in mind no one has managed to do that yet afaik, but ymmv.

Here is the post with teh latest firmware
#42
Archived porting threads / Re: First 7D alpha released!
November 07, 2012, 03:26:41 PM
Fixed ;)
#43
Quote from: Shizuka on November 04, 2012, 09:45:48 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.
#44
Archived porting threads / Re: First 7D alpha released!
November 07, 2012, 02:07:13 PM
@g3gg0

I forgot to mention my thanks for your speed up of focus peaking. having its response moved from ~2 fps to ~18 fps is much appreciated :). Kudos for that speedup
#45
Archived porting threads / Re: First 7D alpha released!
November 05, 2012, 04:33:06 PM
@ideimos
Have a look here:
http://www.magiclantern.fm/forum/index.php?topic=3404.0

@g3gg0
Aside from the bug of flush rate not being retained (not saved/read from the config file you have?), there is one other little bug to note. The repeat rate for the joystick seems to have been modified. I like it quick, except that the delay before repeating is too short. This makes it tedious to scroll in a zoomed image or moving the focus box.

That reminds me. Magic Zoom has a bit of an issue. First, configure it to be on top of the focus box. Set it Medium and it behaves fine. Set it to large, and we have another issue. If the zoomed area goes down below the image boundary, it's not erased properly when the box then moves box in bounds of the LV image. Now if you go to the top of the screen, the zoomed area stays in either top corner.
#46
Quote from: g3gg0 on November 04, 2012, 01:00:13 AM
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.
#47
Quote from: 1% on November 04, 2012, 04:26:56 PMdeadzone_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?
#48
Quote from: Shizuka on November 04, 2012, 11:01:34 AM
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.
#49
Archived porting threads / Re: First 7D alpha released!
November 04, 2012, 04:08:11 PM
Quote from: nanomad on November 04, 2012, 11:54:59 AM
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 :)
#50
Quote from: g3gg0 on November 04, 2012, 03:44:46 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.

Quote from: g3gg0 on November 04, 2012, 03:44:46 PM
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.
Quotedeadzone_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.

Quote from: g3gg0 on November 04, 2012, 03:44:46 PMyes 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?

Quote from: feureau on November 04, 2012, 03:52:49 PM
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.