Magic Lantern Cinema Camera - Dual ISO without aliasing & without quality loss!

Started by theBilalFakhouri, September 18, 2018, 10:00:59 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.



How to get 1x3 binning on MKIII?
I compiled "bleeding-edge" 700D crop_rec - it's not workig on MKIII, as advertised :(
Then, I uncommented 1x3 preset in crop_rec from the crop_rec_4k_mlv_snd branch -
yes, it already has one for MKIII, just commented out.
And it works!!! But, vertical resolution is wrong!!!
It shoots 1920x1258 - 1920x419 after resizing.
I tried to increase target YRES in crop_rec settings - no difference.
It looks like I need to fix mlv_lite code - it doesn't recognize that binning and don't let to choose correct resolutions...



I don't think vertical resolution is wrong. Everything is normal the "bleeding-edge" crop_rec is completely different from crop_rec in crop_rec_4k_mlv_snd branch. And maybe the settings like target YRES wouldn't help in this case. The Y resolution is looking like this in new crop_rec "bleeding-edge" : (See the screenshots in camera)

After applying 1x3 binning without changing Y resolution in 700D it gave 1736x1160 resized to 1736x386 it's similar to what happened in 5D3. But without increasing the vertical resolution.

I don't really know when the new crop_rec will be ready for 5D3. If you really want to increase vertical res in 1x3 binning make a preset in current crop_rec using adtg_gui. like this. Or maybe the new crop_rec is very easy to be ported in 5D3 I think a1ex will help you to get it working. I don't have 5D3 sorry.



What you are doing and demonstrating here with the 700D is so exciting !!!  Would it be possible that you also provide a build with this same functionality for the 100D?  So many 100D owners including me, eager to test and provide feedback, should greatly appreciate that.



Sorry for my late responding, We have tried me and Danne for getting a preset in old crop_rec for 100D and EOS M, Unfortunately it didn't work. 1x3 Binning is working but without increased resolution so you will have very wide aspect ratio 1736x386 I don't think it will be very exciting. It's needs some more tweaking for making it working.


Yes, minor road block. Will dive into it some more next week. Thanks for helping out Bilal.


Quote from: Danne on October 12, 2018, 02:26:46 PM
Yes, minor road block. Will dive into it some more next week. Thanks for helping out Bilal.

Great news, Bilal and Danne!  I will be looking forward to a hopefully working build!  Keeping my thumbs pressed for you!


Quote from: theBilalFakhouri on October 07, 2018, 01:53:18 AM
After applying 1x3 binning without changing Y resolution in 700D it gave 1736x1160 resized to 1736x386 it's similar to what happened in 5D3. But without increasing the vertical resolution.
Did some testing by uncommenting in crop_rec.c in crop_rec_4k to get into 1x3 on my 5D mark III and it works with a somewhat limited resolution as the end result the same as reported by mothaibaphoto.

MLV file:

Now I tried some adtg_gui tinkering but without any success. I don´t think registry changes can be applied when crop_rec setting is applied so changing 713c and 6804 won´t fly. I did some testing without enabling crop_rec but can´t really find all registrys so even if I could expand height to 1440 it wouldn´t contain any image and buggy.
So what are the possiblities here? Is height expandable as with the 700D? Could we enable a version for testing this 1x3 setting specifically?


Jumping into registry(got the relevant ones from Bilal and some figures to test)

Check below registers what´s working or not.
Problematic as the file contain no image at the bottom.
example MLV:


    CMOS 1  0x200
    CMOS 6  0x170

    800C       0x0
    8178 N    0x729
    8196 N    0x729
    8179 N    0xa91
    8197 N    0xa91(not working) c91 working

    713C       0x85e(not working)  0x75e(working)
    6804       0x828011b(not working)  0x728011b(working)


MLV file:
Oops, wrong link, try this one:

Thanks to Bilal of course:
1920x1770. Let´s see if we can go it even higher:


Danne and Bilal,

You seem to be creating history here!  What you guys are doing is absolutely insane! 

I have a question for you.  This 1x3 method with and without Dual ISO, how does it compare with the normal crop-recording method in terms of noise and overall image quality?  I have been filming a lot at 2520x1304 (16:9) resolution with my 100D and am very pleased with the results.  Moreover, using SD-card overclock and 18 fps, I get continuous recording at 14-bit lossless.  Dual ISO also gives me a great advantage in terms of noise and greatly improves my low-light videos.  Am I right by saying that the 1x3 method eliminates the crop factor that you get with crop recording but is limited by resolution due to limited card write speed?  Anyway, to have both options would be fantastic!  The 1x3 method for full-sensor usage and shallow DOF and the crop recording mode for high-resolution shots.  I would love to test and compare both methods.  Any chance for a new build with both options for the 100D?



I will not accept "creating history" I have only used the tools in different way and it was creative or something new yeah especially with Dual ISO the real creative thing in this game :D. Talking about history you should mention Trammell Hudson, Alex and the early and other developers that bring these things to our hands.

Quote from: IDA_ML on October 16, 2018, 07:23:30 PM
This 1x3 method with and without Dual ISO, how does it compare with the normal crop-recording method in terms of noise and overall image quality?

You should read the first post and the link there. Of course it's has less noise compared to x5 mode. The details is the same in normal RAW video but without aliasing or moire. When using Dual ISO you are bringing the quality to the next level the 14 stops of dynamic range with previous benefits, It's perfectly fantastic thing!

Quote from: IDA_ML on October 16, 2018, 07:23:30 PM
Am I right by saying that the 1x3 method eliminates the crop factor that you get with crop recording but is limited by resolution due to limited card write speed?

It can be true but not really, The resolution is the same in normal RAW video but in 1x3 Max aspect ratio is 2.35:1 or a little bit more. In 700D 1736x2214 resized to 1736x738 @ 23.976 FPS, this requires about 70MB/s write speed in 10-Bit lossless (10-Bit lossless is working yeah using Analog gain and without any problem), I can get from 3 to 4 seconds using sd_uhs.

If I want continuous recording I should drop the resolution to 1504x1920 resized to 1504x640 (@ 53MB/S) Now we will have a small crop factor 1.85x crop . I have some hope to get more write speed in the future maybe it will be continuous in full sensor width! 1504x640 is very enough for me with no aliasing and 14 stops in 10-bit with less noise :) 1736x738 Will be great option too!


For 100D
I am trying my best .. no luck with me but it's doable if I had the camera. I will try again.



By saying "creating history" by no means do I neglect the invaluable contribution of A1ex and all the other early developers that made this remarkable project possible and gave ML to all of us.  On the contrary, I have always stated that Magic Lantern is much more a revolutionary than an evolutionary project.  It is an excellent example of what a joint  iternational effort is up to in which not money, corporate interests and profits but intelect, creativity, science, inovation and enthusiasm are the major driving force.  Many of the developments, pioneered by our Magic Lantern developers, such as MLV RAW video, ISO research, Dual ISO, MLVFS, MLV Producer, MLVApp etc., are unique to DSLR technology and turn our cheap amateur cameras into powerful cinema shooting tools while processing RAW video has never been easier and faster - something that has not been demonstrated by any of the mighty camera manufacturers yet.  In my opinion, implementing these developments into future camera models, especially into the mirrorless ones, is just a question of time and therefore, the "creating history" statement is not exaggerated.  In that respect, every small step of progress in ML dvelopment is a giant leap towards making our cameras better. I cannot find the right words to express my deepest gratitude to all people involved in this remarkable project.  I can only hope that the efforts will continue and the ML community will continue to grow and enjoy the results of this fantastic joint international effort.

As far as your continued efforts on implementing your Dual ISO developments into the 100D is concerned, I greatly appreciate them and thank you for that.   Not having this camera in your hands is a problem of course but if you could help Danne who has it and understands its peculiarities, I am sure, you guys will eventually succeed. 


Some progress:
Dualiso MLV:

1920x2368 after 0.33 set in Mlv App we got 1920x789(not bad)

This was achieved after step by step "schooling" from Bilal. Register settled like so after tested in adtg_gui:
   switch (reg)
        case 0xC0F0713c:
            return 0x97e;
        case 0xC0F06804:
            return 0x97e011b;

        case 0xC0F06008:
        case 0xC0F0600C:
            return 0x1800180;

        case 0xC0F06010:
            return 0x180;

        case 0xC0F06014:
            return 0xa27;


cmos_new[1] = 0x280;

So this will work with fps 23.976 if I remember correctly and 1920x2368. Now question is if there are more variables/registers to include to go even higher?




Exactly, who needs liveview if you have raw  :D
Just fix it in post  :P



Your words are in the right place :) I have the same thing here as you said exactly, I can't add more words above your writing.
Great man.

What is the next stage for ML? :P I can't imagine more than the latest developments in the past two years. Maybe in next 1st April :D


Quote from: theBilalFakhouri on October 17, 2018, 06:03:10 PM
What is the next stage for ML? :P I can't imagine more than the latest developments in the past two years. Maybe in next 1st April :D

I think, for the near future, we should try to improve what we already have on our camera models, (it is enormous and extremely useful for practical work),  rather than trying to invent and implement more and more new features.  Many people using ML on a regular basis, including me, would like to see one single stable build that works without glitches, a build one can rely on in real-life filming conditions.  This includes:

1) Fast and accurate focusing;

2) WySiWiG preview - bright enough, for proper framing during filming;

3) High-resolution 10/12-bit lossless video in crop mode providing continuous recording with SD/CF-card overclocking.  (Note that the 2520x1304 resolution is working already on the 100D but at 14-bit lossless and 18 fps.  It would be extremely useful to have continuous recording at 2560x1440 resolution and 24 fps at 10 or 12 bit lossless compression);

4) Stable Dual ISO operation for high-contrast and low-light scenes.

5) Stable operation after switching modes;

6) Hard coded optimum ISO values for each camera providing maximum dynamic range and lowest shadow noise, accordingly.

7) Better white balance and faster render speeds for MLV video in MLVApp. 

Let me share with you a small discovery that I made recently trying to process my Dual ISO files with MLVApp.  It concerns the built-in H.265 codec.  I discovered that rendering the MLVApp processed videos in that format goes pretty fast, video quality is stunning and H.265 file sizes are very small (about 50x smaller than the original MLVs at the same resolution).  I was shocked when I opened these files in Resolve.  They playback smoothly and video editing goes really fast if you don't use any complex color grading in Resolve.  Export from Resolve is also blazingly fast.   I may seriously consider this workflow for my future edits since it saves me a lot of time and disk space.  This is just an example of how far ML has gone in terms of video post processing.


Me and Bilal are trying to reduce analog gain in crop_rec.c code but there is one issue here. The 5D mark III has two sets of iso registers so seems these registers will simply override each other giving corrupted image:
8882 0x41a
8884 0x41d
8886 0x41d
8888 0x41c

8882 0x41d
8884 0x41b
8886 0x41d
8888 0x41c

Tried putting this after powersave timing register but not working. Works fine with adtg_gui manually outside but not when applied as shown below:

adtg_new[13] = (struct adtg_new) {2, 0x8882, 0x20};
                adtg_new[14] = (struct adtg_new) {2, 0x8884, 0x20};
                adtg_new[15] = (struct adtg_new) {2, 0x8886, 0x20};
                adtg_new[16] = (struct adtg_new) {2, 0x8888, 0x20};

adtg_new[17] = (struct adtg_new) {4, 0x8882, 0x20};
                adtg_new[18] = (struct adtg_new) {4, 0x8884, 0x20};
                adtg_new[19] = (struct adtg_new) {4, 0x8886, 0x20};
                adtg_new[20] = (struct adtg_new) {4, 0x8888, 0x20};

Also needed to expand this:
    /* expand this as required */
    struct adtg_new adtg_new[20] = {{0}};

Would be great if we could shove those missing registers in there to get into 10bit in crop_rec.c.

Commented out following and getting 1920x2400 now:
        case CROP_PRESET_3X:
     /* case CROP_PRESET_1x3: */
            skip_top        = 60;


You've got 21 registers there (from 0 to 20).

Overwriting each other would only give some barely noticeable vertical stripe pattern (nothing that our stripe correction algorithm won't fix). These are exactly the registers used to fine-tune the column gains in hardware, so if one is going to implement stripe correction directly in the camera, these are the registers that will have to be touched.

At such low values, it won't be able to correct the stripes, but that's not needed as long as the software correction works.



This is how it looks and works on 6d, indeed put in the part with the power save timers:

  adtg_new[13] = (struct adtg_new) {6, 0x8882, 108};
  adtg_new[14] = (struct adtg_new) {6, 0x8884, 108};
  adtg_new[15] = (struct adtg_new) {6, 0x8886, 108};
  adtg_new[16] = (struct adtg_new) {6, 0x8888, 108};

So first thing you could try is removing the '0x' before the '20' at the end, maybe it needs decimal values ?

Furthermore all the registers in powersave part uses the number 6 before them.
Even the lineskipping registers etc, all number 6, no 4, no 2 as you did.
Not sure where that 6 stands for, but maybe try to use 6 instead of 4 and 2  :-\

adtg_new[12] = (struct adtg_new) {6, 0x800C, 0};