First 7D alpha released!

[Shizuka]

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

But could this also be used to remove hot pixels in video?

[a1ex]

The video buffer can be altered before compression in theory, but is there any reason for not doing it in post? It's not easy to implement it without side effects.

[ideimos]

Ok, thanks for the answers. It was just a wild idea.

Can't wait to adjust 7D bitrate, then. 

[Digital Corpus]

@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.

[g3gg0]

@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.

saving: its still experimental - i dont care if its saved or not. its just about the question "does the feature make sense?"
repeat rate: its not 7D-specific. its ML base. see prefs -> focus box settings -> speed
magic zoom: thanks. lets call it "bottom black bar not redrawn when MZ (large) painted over it"

[feureau]

saving: its still experimental - i dont care if its saved or not. its just about the question "does the feature make sense?"

I have several cards of differing speeds. On my slowest card, I need to set flush to 12 in order for it to be able to record All-I CBR at 20x. With flush set to default at 4, if I forgot to change this, it will err70, and I'd have to reload ML again. /firstworldproblems

On my fastest card, I find that if I set flush at 1, I can record All-I at CBR 20.0x with very minimal buffer, leaving a lot of processing power for other ML features to run. I can set the buffer warning to 30% and record without worrying of buffering out. This reminds me, can you let the flush minimum at 1 instead of 2 on future releases?

Anyway, the feature makes sense because it lets you customize the flush in order to maximize bitrate to your card.

And as always: Thanks for all the hard work, g3gg0!

[g3gg0]

Anyway, the feature makes sense because it lets you customize the flush in order to maximize bitrate to your card.

thanks for feedback.
if it makes sense for future ML releases is still questionable.
this feature is definitely not idiot-proof and will cause a lot of bug reports.

and even if users are warned enough, there might be bug reports that say "in one of 100 recordings my camera fails with ERR70. why??"
thats not what we want.

[ideimos]

@ideimos
Have a look here:
http://www.magiclantern.fm/forum/index.php?topic=3404.0

I miss that. Thanks!

[feureau]

thanks for feedback.
if it makes sense for future ML releases is still questionable.
this feature is definitely not idiot-proof and will cause a lot of bug reports.

and even if users are warned enough, there might be bug reports that say "in one of 100 recordings my camera fails with ERR70. why??"
thats not what we want.

Just a quick thought: Hide it in the advanced/debug section, or have an option in the advanced/debug section thing to enable advanced not-idiot-proof settings like this, with a warning. This way, people who likes to experiment with ML can get that sweet sweet experimenting joy while idiots would probably never find it.

[g3gg0]

they will.

[feureau]

It would be quite unfortunate to not have access to certain settings just because some people would be using it wrong and complain about it.

Anyway, you mentioned that you managed to hit 300mbps. I've been playing with the experimental bitmonsters, but I can't seem to get a bitrate that high. How did you do it?

[ideimos]

I guess you are not recording something that has enough detail to achieve the highest possible bitrate. Try to use f5.6 - f8 with high ISO and something like beach sand, grass, trees...

[jmalmsten]

Reading the number-crunching that went on after my own crude crunching made me think about something I've been looking at for some time now... but it does require us to get into how it reads off the sensor. Which may be off-limits for firmware. It's basically a feature-request. But I just need to brain-dump a bit.


Either we maybe could lower the amount of pixels to Scope (1920x800) to lessen the load of the encoder to enable 48fps or the like without increasing the amount of bandwidth per second (by lessening the amount per frame)


Or... this might be fun. Non-square PAR readout. If can muck about with how the image is read from sensor. We could possibly use full 1920x1080 for a 2.4:1 area. Gaining a bit in vertical resolution when we later squeeze it down to appropriate size with vertical oversmpling. 0.67:1 PAR if I understand it correctly... or maybe it's just 1:1.33 PAR.


Or we could do something similar to get a 4:3 area recorded to the full 1920x1080. It probably would gain a bit in vertical resolution after scaled down to 1440x1080. Or full 3:2 sensor readout to 1920x1080.



---
So far so good anyways when it comes to stability though.

I'll probably not go much higher than 100Mbps if given the option. Mostly because of storage-issues if anything.

[RenatoPhoto]

thanks for feedback.
if it makes sense for future ML releases is still questionable.
this feature is definitely not idiot-proof and will cause a lot of bug reports.

and even if users are warned enough, there might be bug reports that say "in one of 100 recordings my camera fails with ERR70. why??"
thats not what we want.

Maybe that is the reason why Canon does not provide any of the great stuff that we get from ML.

Thanks for all the amazing things and great work that you do!

[Digital Corpus]

@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

[Pelican]

. Judos for that speedup

Do you wanna fight with him? 

[Digital Corpus]

Fixed

[neofg]

Reading the number-crunching that went on after my own crude crunching made me think about something I've been looking at for some time now... but it does require us to get into how it reads off the sensor. Which may be off-limits for firmware. It's basically a feature-request. But I just need to brain-dump a bit.


Either we maybe could lower the amount of pixels to Scope (1920x800) to lessen the load of the encoder to enable 48fps or the like without increasing the amount of bandwidth per second (by lessening the amount per frame)


Or... this might be fun. Non-square PAR readout. If can muck about with how the image is read from sensor. We could possibly use full 1920x1080 for a 2.4:1 area. Gaining a bit in vertical resolution when we later squeeze it down to appropriate size with vertical oversmpling. 0.67:1 PAR if I understand it correctly... or maybe it's just 1:1.33 PAR.


Or we could do something similar to get a 4:3 area recorded to the full 1920x1080. It probably would gain a bit in vertical resolution after scaled down to 1440x1080. Or full 3:2 sensor readout to 1920x1080.



---
So far so good anyways when it comes to stability though.

I'll probably not go much higher than 100Mbps if given the option. Mostly because of storage-issues if anything.

I ask from months for this feature (particularly the 4:3 one for 2X anamorphic lenses). A1ex say that this isn't possible because this is a DIGIC feature. And you Can't modify it with ML...
I hope they find the way in the future...

[jmalmsten]

I thought so... I'm actually surprised at how few camera-makers would consider using tricks like those. 

[neofg]

I thought so... I'm actually surprised at how few camera-makers would consider using tricks like those. 

Yes. And I don't know why Canon never do something with A1ex.
If I use Canon is because him.

[juanmelchor]

Hi! Where I can download the latest version of the experimental .FIR? I want to try it on my 7D, it is great!! 

[Digital Corpus]

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

[ArturoKiwi]

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

I don't know why, but I can't open both your link

[xmd5a]

I don't know why, but I can't open both your link

Correct link http://www.magiclantern.fm/forum/index.php?topic=3404.msg17691#msg17691

[ArturoKiwi]

Correct link http://www.magiclantern.fm/forum/index.php?topic=3404.msg17691#msg17691

Thanks