Developing Magic Lantern > Feature Requests

Features that are NOT possible - please don't request them

(1/18) > >>

Features copied from another Canon camera
Copying Canon code or functionality may carry legal risk for us. We do respect the Canon company and love their products and we are strict about staying on the right side of the law.

1080p 60fps, 2K, 4K, RAW video...
The best we could do was 1080p 35fps on 60D and 600D. Update: 4K works, but has major limitations.

Custom codecs
Codecs are not implemented on the general-purpose ARM processor. We can only use what Canon has already included in hardware (H.264, JPEG, LJ92) and fine-tuned their parameters (such as the H.264 bit rate).

The lossless compression used for raw video is the same "codec" Canon uses for CR2. The same processing path (codenamed JPCORE) might be able to handle (M)JPEG. However, we cannot implement additional codecs (such as H.265, JPEG2000 or ProRes). Even if these might be able to run on Canon's image processing hardware, we simply don't know where to start.

Things that can be done in post
Why spending development time on things like in-camera HDR? Magic Lantern is not a replacement for Photoshop ;)

Previewing is OK (e.g. HDR preview, anamorphic preview, fisheye correction preview).

Real-time video processing (e.g. stabilization, sharpness algorithm)
We can't program the image processor. These things can only be done if the functionality is already in Canon firmware (i.e. some parameters that can be tweaked - like in the Image Effects menu).

AF microadjustment
Not possible to control AF outside LiveView.

Image on both LCD and external monitor at the same time
Not possible (unless proven otherwise by DIGIC investigation).

AF confirmation without chipped adapters
Not possible (camera refused any attempts to fake lens info).

Very difficult (see ). The 5D Mark III has it.

Continuous AF in movie mode
Very difficult to do it right (we couldn't).

Scrollwheel controls
It's not possible to remap them while recording. In standby, ML menu uses a trick: it opens some Canon dialog in background to steal wheel events from it, but this trick doesn't work while recording.

1D support
These cameras are way outside our reach. Even if we could buy them, very few 1D users would benefit from ML.
There are also legal concerns regarding Canons Pro line of cameras.

Sure, at some point, some of these might become possible, but chances are extremely small. Spending time on those is effectively searching for the needle in the haystack.

A detailed explanation by dmilligan, on why Magic Lantern cannot increase the FPS of cameras. 

--- Quote from: dmilligan on May 02, 2014, 11:57:05 PM ---Your question really boils down to this:
"Why can't I capture more information, by throwing away information?"

Now from a more practical standpoint:
Compression (what you refer to as "lowering the bitrate") is a difficult, computationally intensive task (it's also impossible). It is not a magical process where you throw some data in and it comes out smaller. The only way to get enough of an effective compression ratio for the incredibly huge size of a video data stream, is to just throw away some of it. The goal here being to throw out the least important information, but we are throwing away information nonetheless. The better an algorithm is at throwing away data (i.e. the better it is at figuring out what data is unimportant), typically the more complex it is. There are very easy ways to throw away data, such as reducing the resolution and line skipping, and there are very hard ways of throwing away data such as DCT

Lets now consider (a very oversimplified) pipeline that a video stream goes through in the camera:
Sensor -> Raw Data -> Image Processing (demosaic, wb, pic style, curves, etc.) -> H.264 Encoder -> Storage

When you talk of "bitrate" you are only talking about the bitrate at the very last step of this pipeline, the bitrate out of the encoder to the storage media. There are many other steps prior to this to consider. If you want a 1080p stream out of the encoder, you also need that 1080p stream to make it's way through the rest of that pipeline (at 60fps). That's where the limitation is, in fact there are probably many, I'll just go over some of the possible ones:
1. The H.264 encoder, can't handle 1080p of video data coming into it at 60 fps (remember it has to do something very complex and computationally intensive with the data and then spit out that result very quickly)
2. The image processing electronics can't handle 1080p of raw data at 60 fps
3. The internal buses that move the raw data from the sensor to the image processors can't handle that much data (1920*1080*14bit*60fps = 1.7 Gigabits per second)
4. The sensor itself isn't fast enough to sample 1080 lines at 60 fps (it takes some finite amount of time to read out each line, and they are read one by one)

I'm not saying that all of those are true, but at least one or more of them are, and that's why 60p mode is a lower resolution. Overcoming any of these obstacles is possible, but it would require more transistors (i.e. faster, more complicated electronics), which would make the camera more expensive. So without more expensive internal electronics, the only way to get enough "compression" to be able to even get our video data to the encoder, is to "compress" the data starting at the sensor itself, and what's the only way to do that? line skipping and reducing the resolution -> basically don't read in as many pixels.
--- End quote ---

Michael Zöller:
A1ex, should 1080i/p HDMI out be on this list, too? Or is there still some hope?

There is a small hope for 5D3, from the digic investigation thread.

Adding a bit of FAQ to FPS since it's a hot topic

When looking at FPS in video mode we have several limits:
- Canon's firmware. This includes the encoder used to compress video. Each firmware has multiple encoders, one for each combination of supported resolution AND FPS

- Video buffer, this is linked to the previous point. The camera can process only much information before running out of it. You'll notice that when using ML bitrate control, for example.

- Processor and sensor readout speed (the latter limits live view to about 39FPS)

- SD write speed, the least important of the group if you ask me.

Just forget what I just wrote... I have read around some more now. Seems to be impossible anyway :)

Keep up the good work!


[0] Message Index

[#] Next page

Go to full version