crop_rec on steroids: 3K, 4K, 1080p48, full-resolution LiveView

Started by a1ex, April 01, 2017, 11:15:41 AM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

g3gg0

Quote from: a1ex on June 28, 2018, 10:29:34 PM
And yes, 1/4000 is hardcoded in the code you have pasted (250e-6; don't remember why I wrote it like that; 1.0 / 4000 would have been the same).
250u, thats the scientist in you ;)
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

Levas

Quote from: a1ex on June 28, 2018, 10:29:34 PM
And yes, 1/4000 is hardcoded in the code you have pasted (250e-6; don't remember why I wrote it like that; 1.0 / 4000 would have been the same).
Stupid me  :P I should have known that it's the 250e-6.

And the part about the option to remap the shutter speed range is really helpful, helps to understand the piece of code.

I've heard of the crazy shuttertimes in video mode, and saw some evidence in the crop_rec module, but didn't know where it was used.
Thought it was used through full res silent pictures or something.
But anyway, that shutter remapping -> full range option is a hidden gem  :D

Gonna dive into crop_rec some more and hope I can solve the shutter mapping problem I have on the 6d.




Levas

Trying to figure out how shutter_blanking calculations work, but still don't get it.

Quote from: a1ex on June 28, 2018, 10:29:34 PM
In movie mode it has 1/4000 in Canon UI, but the hardware lets you set the exposure time to 2 units (that is, blanking set to timer B - 2). In microseconds, that would be 1 / (24e6 / timerA / 2). That gives 1/25000 in 50p (timer A = 480), "overclockable" to 1/30000 (timer A = 400), or close to 1/15000 in full-res LV (timer A = 792).

For the 6d :
Clockspeed 25600000
Timer A in 1080_25p = 639
Timer B in 1080_25p = 1599

When I want to calculate the max range in 1080_25p -> 1/25600000 / 639 / 2 = 1/20033
So I assume max shutter speed for 6d in 1080_25p is 1/20000th
But I don't get it, where is the B timer involved, or isn't the B timer involved in shutter speed, because it's the speed where 1 line of pixels is readout ?
And what does the value of the shutterbalnking registers mean , how can they be translated to exposure times ?

At the moment I think the problem is in the line in the middle of this piece of code

         ({
            /* map the available range of 1/4000...1/30 (24-30p) or 1/4000...1/60 (50-60p)
             * from minimum allowed (1/15000 with full-res LV) to 1/fps */
            int max_fps_shutter = (video_mode_fps <= 30) ? 33333 : 64000;
            int default_fps_adj = 1e9 / (1e9 / max_fps_shutter - 250);
            (orig_shutter - 250e-6) * default_fps_adj / current_fps;
        });


The values 33333 and 64000 are probably hardcoded for 5d3.
Tried to change value 33333 to 20033, it gave other shutter times, but still not the right ones (range goes from 1/34th to 1/120th, no further (1/120th is reached when Canon is on 1/4000).

EDIT, this is not it, I see the 33333 and 64000 values are max shutter time as in 1/33th and 1/64th for video modes...back to the drawing boards again  ::)


a1ex

To get an interval of N units, you write N-1 in the hardware timer register. That means, the timer will count from 0 to N-1, giving a periodic signal every N units. When doing the math, I use N, that is, value read from the hardware register (as displayed by adtg_gui) + 1. So, 25.6e6 / 640 / 2 = 20000 => fastest shutter is, indeed, 1/20000.

Timer A is incremented once by the main clock (so, 25.6 million times per second). When it reaches the value programmed in that register, it goes back to 0 and the image capture hardware moves on to read out the next line. If timer A is "too fast", at first you get some black columns on the right side (line readout does not finish), then the image breaks completely. If timer A is larger than needed, it works fine, you just get some more rolling shutter.

Every time timer A fires, the second timer (B) also gets incremented. When timer B reaches its programmed value, it goes back to 0 and the next frame is read out. Timer B needs to be large enough to read out all the lines (but can be larger).

Things are a bit more complex than that, there are also 4 HEAD timers that I don't fully understand yet, but for "simple" FPS adjustment, that's basically how it works.

Back to exposure time. For the ADTG register, you no longer measure the time in microseconds; you use timer A ticks for that. That is, time within one frame goes from 0 to timerB - 1. That's the unit you use to program the various timers (HEAD timers, exposure time, powersave timing etc).

Blanking = how much time the sensor is not capturing anything. So, frame_duration = exposure_time + blanking_time (or, exposure_time = frame_duration - blanking_time). That's what the hardware expects: you program how much time the sensor stays "off", rather than "on".

If you have an older model, FPS override at low frame rates will overexpose quite a bit. Why it's that? If you only override the timer registers and leave the ADTG stuff unchanged, the "shutter blanking" register will stay the same. However, the frame duration (aka timer B) will increase, so the exposure time will also increase.

For example, if you cut the FPS in half by doubling timer B, the old method will not be able to get a shutter speed faster than 1 / (FPS/2), even if you dial 1/8000 in Canon menu. Why? Canon code will set the blanking register close to the original timer B, but the frame duration is now double.

If you do the same thing by doubling timer A, the exposure time (and the rolling shutter) will just double (from what you dial in Canon menu). In this case, timer B will not change, so the ratio between blanking and exposure will stay the same, but one unit will now be twice as many microseconds.

BTW, before knowing this stuff, the following was found by writing down shutter values and trying to find an explanation:


    // FPS override will alter shutter speed (exposure time)
    // FPS "difference" from C0F06014 will be added as a constant term to exposure time
    // FPS factor from C0F06008 will multiply the exposure time (as scalar gain)
   
    // TG = base timer (28.8 MHz on most cams)
    // Ta = current value from C0F06008
    // Tb = current value from C0F06014
    // Ta0, Tb0 = original values
    //
    // FC = current fps = TG / Ta / Tb
    // F0 = factory fps = TG / Ta0 / Tb0
    //
    // E0 = exposure time (shutter speed) as indicated by Canon user interface
    // EA = actual exposure time, after FPS modifications (usually higher)
    //
    // If we only change Tb => Fb = TG / Ta0 / Tb
    //
    // delta_fps = 1/Fb - 1/F0 => this quantity is added to exposure time
    //
    // If we only change Ta => exposure time is multiplied by Ta/Ta0.
    //
    // If we change both, Tb "effect" is applied first, then Ta.
    //
    // So...
    // EA = (E0 + (1/Fb - 1/F0)) * Ta / Ta0


Now it seems to match the above theory.

Levas

Quote from: a1ex on June 29, 2018, 10:36:08 AM
Blanking = how much time the sensor is not capturing anything. So, frame_duration = exposure_time + blanking_time (or, exposure_time = frame_duration - blanking_time). That's what the hardware expects: you program how much time the sensor stays "off", rather than "on".
Aha, now I get at least what the shutter blanking value means.

Aslo enabled the debug in the crop_rec.
and enabled a preset I made.
I have set shutter time to 1/50th on Canon top display and ML shows 1/27th.
Console:

[80440] c0f06014: 493 -> 2f2
FPS 25000 -> 25005
Timer B 1599 ->755
Exposure 1128 -> 709 (Timer B units)
Shutter 28217 -> 37555us
Blanking 471 -> 46
ADTG2[805f] = 39
ADTG2[8061] = 39

Now there are a few things wrong here, but first, what is right.
New value of Timer B is right, I have set it to 2f2 in this crop_rec preset.
New FPS value is right, I have 25005 FPS in this preset (Timer A = 54b)

But what is wrong here, I see 2 values used for what Timer B was, the first line says, 493 (which is right, because I'm in 5x zoom, where Timer Normally is 493. )
And further on I see a 'before' Timer B value of 1599 -> comes from plain 1080_25p mode, not from 5x zoom mode.
Furthermore it says FPS was 25000, but that's from 1080_25p mode, 5x zoom has 29921 fps /1000

I can imagine that the this happens when I enable Crop_rec in 1080_25p mode, but the above console values are also showed when I enable Crop_rec preset in 5x zoom mode.



Levas

Now I changed the second column in the sensor timing table to values of 5x zoom crop mode (where I first had values for 1080_25p mode)

/* from SENSOR_TIMING_TABLE (fps-engio.c) */
/* hardcoded for 6d */
const int default_timerA[] = { 0x221, 0x2d9, 0x21f, 0x27F, 0x27f };
const int default_timerB[] = { 0x7a2, 0x493, 0x61b, 0x31f, 0x334 };
const int default_fps_1k[] = { 23982, 29921, 29978, 50000, 59964 };


Now the shutter time range behaves a lot better, almost right. exactly right  :D (ouch, I had full range option enabled at first)
1/30th top display is 1/25th ML and 1/4000th top display is 1/9400th ML. Values for full range

But if I remember correct, the values in the second column are in the original Crop_rec code for 5d3 from 1080_p video mode and not 5x zoom ?

As seen here:

/* from SENSOR_TIMING_TABLE (fps-engio.c) */
/* hardcoded for 5D3 */
const int default_timerA[] = { 0x1B8, 0x1E0, 0x1B8, 0x1E0, 0x1B8 };
const int default_timerB[] = { 0x8E3, 0x7D0, 0x71C, 0x3E8, 0x38E };
const int default_fps_1k[] = { 23976, 25000, 29970, 50000, 59940 };

a1ex

Hm, I think you just found something I need to fix. There needs to be an additional entry for the x5 zoom...

theBilalFakhouri

Experimental crop_rec with higher resolutions for 700D (it Should work for EOS M)

The presets are:

  • Full-res LiveView 5208x3230   @  6.5 fps
  • 3K 2.35:1 3072x1304           @  20 fps
  • 3.5K 3540x1080 Very Wide    @  22 fps
  • 4K 4096x2560                      @  9.5 fps
  • UHD 3840x2160                   @  12 fps
  • 2520x1386 16:9                   @  23.976 fps
  • 1920x1920                           @  23.976 fps (Not working yet)

VRAM0" border="0

The code:
https://bitbucket.org/bilal_fakhouri/magic-lantern-crop_rec/commits/a6ea137785ea1d36f417f5db6e020c8447f48545

Thanks for @mk11174 for helping.

Of course the code need to be cleaned and editing somthings (maybe I can't clean the code since I am not programmer  :P) --> But for now you can chose the resolution you want in one click instead of adtg_gui steps --> So feedback for current presets and enjoy!

Note: sd_uhs is only for getting better recording times (by overclocking write speed) --> it's not necessary to make crop_rec working but it's a good choice.
Use all of new presets in x5 mode even Full-res (It's working in normal mv1080 but with vertical stripes) and in 14-bit lossless not 12-8bit lossless (You will have corrupted frames if you chose this).

Download and replace crop_rec under crop_rec_4k build.

For Full-res LiveView sometimes it's stuck when selecting it you need to press PLAY button then get back to live view
then x5  mode (Don't worry about these things it will be fixed). And I think 5208x3230 is the limit for Full-res (With more or less pixels --> if you can getting better result maybe I am wrong tell us that please).

For higher shutter speeds in Full-res --> It's need to adjust something in the code --> Look above maybe @Levas and @a1ex talking about that :P I didn't try yet.

BURN THE CAMERA  :D


theBilalFakhouri


Danne

Great effort here @theBilalFakhouri
Ran the setting on my eosm and following works:
2520x1384
3072x1304
3544x1080

Corruption:
4096x2304
4096x696(fullres liveview?) can´t remember.

Only briefly tested. More tests ahead.
Cool!

alpicat

Thanks so much for this @theBilalFakhouri, that makes life so much easier!
Have tested the 2520x1384 setting on the EOS M and it's working flawlessly, tried recording lots of short clips and resulting footage looks incredible - great to have true 16:9 aspect ratio at 2.5k. I also tried a lower resolution with that setting (at 2288x1236) to get longer record times (hope it's ok to do that) - that works fine too.

mothaibaphoto

Hallo, guys! Thank you for your work!
Maybe I'm too late for this party, but until now I used this incredible mode only in FullRes for timelapsing and hyperlapsing.
Now I plan to make some videos of people, with sound and made some tests.
Now feedback:
1. First of all, thanks g3gg0 for 2018-06-26 23:36 build: sound is great, imports to DR automatically in sync.
I didn't shoot anything with sound with mlv_lite before, so i'm unsure, is it fixed, or simply works.
But, need to say, i didn't even used last mlv_dump, but "mlv_dump on steroids".
It has feature to analyse every frame for stripes.
So, i didn't tested last build of mlv_dump, but what i have for converting MLV, works perfectly.
2. Need to be very careful whether to use compressed formats, if you plan to shoot something fine-grained :)
The fun part, the camera keeps shooting after glitch and video continues,
it's just no possible, due to messages on screen.
3. Canon AutoISO works correctly only in 14bit. In other modes it should be disabled with notice for user.
4. Exposure shift in 3.5K 1:1 centered mode. maybe it discussed, i didn't find, sorry.
Look at video from OP: https://vimeo.com/217313287 at 05:35:
as zoom button is pressed and x5 mode entered, exposure changed from 1/50 to 1/35.
It need to be manually corrected every time? Nobody noticed that?
And only this mode supports compressed with reduced bitdepths thus allows maximum resolutions! :(

g3gg0

Quote from: mothaibaphoto on June 30, 2018, 04:48:29 AM
1. First of all, thanks g3gg0 for 2018-06-26 23:36 build: sound is great, imports to DR automatically in sync.
I didn't shoot anything with sound with mlv_lite before, so i'm unsure, is it fixed, or simply works.
But, need to say, i didn't even used last mlv_dump, but "mlv_dump on steroids".
It has feature to analyse every frame for stripes.

you are welcome.
for DR i use MLVFS which works smooth in all situations i had so far.
saves a lot of time and space
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

IDA_ML

Quite exciting times for the ML community!  Congratulations, Bilal!

Will your crop_rec_4k build work on the 100D too?

For those who wish to gain an impression on what quality to expect from their Rebels at 2520x1304 resolution, here is some test footage with sound shot on the 100D at 18 fps:

https://we.tl/1MZVexsbjw

At this frame rate, the 100D provides continuous recording in the above resolution.  More details here:

https://www.magiclantern.fm/forum/index.php?topic=16040.1425

andy kh

#IDA_ML    evrything looks good and very impressive accept the focus dots. my 70D get lots of moire and color artifacts which is not the case with other cameras like 550D and 650D which i had own in the past and sold out to get a 70D to shoot better raw. but 70D is the worse camera for shooting raw. my 70D can't shoot any tress bcoz of color artifacts. i have unsinstall ML from my 70D few months back. now i think i should get a used 100D as i love shooting raw
5D Mark III - 70D

Danne

Added 100D to the mix in crop_rec.c code. Thanks to @theBilalFakhouri  for publishing his code. Could follow and add. Still things to fix like engio stop(disabled atm). Some other stuff to look through as well.
https://bitbucket.org/Dannephoto/magic-lantern/branch/crop_rec_4k_mlv_lite_snd_sd_uhs_HDR_croprec

Settings working in menu(actually 3x3 720p is not working atm):
    "OFF",
    "2.5K 2520x1304",
    "3K 3096x1320",
    "4K 4056x2552",
    "3x3 720p",


Test version(use at own will and risk):
https://bitbucket.org/Dannephoto/magic-lantern/downloads/magiclantern-Nightly.2018Jun30.100D101_2K-3K-4K.zip

Tip: if settings aren´t applied enter canon menu and go back, also turn raw video on and off if new aspect ratios don´t apply directly...

a1ex

@Bilal, Levas, Danne, mk11174,

I've just reworked the PowerSaveTiming and ReadOutTiming registers in a generic way, according to this description. That means, you no longer have to hardcode these in your presets - they should work out of the box if you override the other registers like usual. Can you test on your models? Didn't do the integration yet (working on that); just adapt this commit to your local branches.

If it works, that would reduce the number of camera-specific bits, making the code more portable.

One additional test:

                 int readout_end = shamem_read(0xC0F06804) >> 16;    /* fixme: D5 only */
+                readout_end -= 10; /* with this added, you should get about 10 bad lines at the bottom of the image */

Levas

Updating my working folder with ML. We're working on the 'Crop_rec_4K_MLV_SND' branch, right ?
I see the MLV_Lite is updated 3 days ago, so this is probably the newest branch we're working in for crop_rec_4K

I noticed an error in lossless.c while compiling MLV_lite.

It's in Line 345: (Last two lines in this piece of code)

    /* there are a few registers possibly related to RD2/WR2 - we don't use them */
    /* 5D3: [0xC0F375B4] <- 0xF6D0B8F, [0xC0F12020] <- 0x18A0127  =>  slice width / 10, slice height / 10 */
    /* 6D:  [0xC0F375B4] <- 0xE7B0ADF, [0xC0F12020] <- 0x13400E7  =>  slice width / 12, slice height / 12 */
    /* 70D: [0xC0F37300] <- 0xE7B0ADF, [0xC0F12020] <- 0x13400E7  =>  slice width / 12, slice height / 12 */
    /* 650D, 700D, 100D, EOSM, EOSM2:
     *      [0xC0F375B4] <- 0xDC70A4F, [0xC0F12020] <- 0x1B80149  =>  /* slice width / 8, slice height / 8 */


Needs to be fixed to:

    /* there are a few registers possibly related to RD2/WR2 - we don't use them */
    /* 5D3: [0xC0F375B4] <- 0xF6D0B8F, [0xC0F12020] <- 0x18A0127  =>  slice width / 10, slice height / 10 */
    /* 6D:  [0xC0F375B4] <- 0xE7B0ADF, [0xC0F12020] <- 0x13400E7  =>  slice width / 12, slice height / 12 */
    /* 70D: [0xC0F37300] <- 0xE7B0ADF, [0xC0F12020] <- 0x13400E7  =>  slice width / 12, slice height / 12 */
    /* 650D, 700D, 100D, EOSM, EOSM2: [0xC0F375B4] <- 0xDC70A4F, [0xC0F12020] <- 0x1B80149  =>  slice width / 8, slice height / 8 */


Don't know if it gave any bugs while using it  :P

Danne

@a1ex
Tested PowerSaveTiming and ReadOutTiming commit and put it here in my latest crop_rec code for 100D(is it even supose to work for this cam out of the box?)

This part:
   if (is_100D)
    {
        switch (crop_preset)
        {
            /* 3x3 binning in 720p (in 1080p it's already 3x3) */
            case CROP_PRESET_3x3_1X:
                /* ADTG2/4[0x800C] = 2: vertical binning factor = 3 */
                adtg_new[0] = (struct adtg_new) {6, 0x800C, 2};
                break;

case CROP_PRESET_2K_100D:
                /* adjust vertical resolution */
                adtg_new[2] = (struct adtg_new) {6, 0x8172, nrzi_encode(0x87c + delta_adtg0)};
                adtg_new[3] = (struct adtg_new) {6, 0x8178, nrzi_encode(0x87c + delta_adtg0)};
                adtg_new[4] = (struct adtg_new) {6, 0x82B6, nrzi_encode(0x8F4 + delta_adtg0)};
                break;

case CROP_PRESET_3K_100D:
                /* adjust vertical resolution */
                adtg_new[2] = (struct adtg_new) {6, 0x8172, nrzi_encode(0x77C + delta_adtg0)};
                adtg_new[3] = (struct adtg_new) {6, 0x8178, nrzi_encode(0x77C + delta_adtg0)};
                adtg_new[4] = (struct adtg_new) {6, 0x82B6, nrzi_encode(0x7F4 + delta_adtg0)};
                break;

case CROP_PRESET_4K_100D:
                adtg_new[2] = (struct adtg_new) {6, 0x8172, nrzi_encode(0x8FD + delta_adtg0)};
                adtg_new[3] = (struct adtg_new) {6, 0x8178, nrzi_encode(0x8FD + delta_adtg0)};
                adtg_new[4] = (struct adtg_new) {6, 0x82B6, nrzi_encode(0x8F4 + delta_adtg0)};
                break;

        }
    }


Into this:
   if (is_100D)
    {
        switch (crop_preset)
            {
                /* assuming FPS timer B was overridden before this */
                int fps_timer_b = shamem_read(0xC0F06014) & 0xFFFF;
                int readout_end = shamem_read(0xC0F06804) >> 16;    /* fixme: D5 only */

                /* PowerSaveTiming registers */
                /* after readout is finished, we can turn off the sensor until the next frame */
                /* we could also set these to 0; it will work, but the sensor will run a bit hotter */
                /* to be tested to find out exactly how much */
                adtg_new[4]  = (struct adtg_new) {6, 0x8172, nrzi_encode(readout_end + 1) }; /* PowerSaveTiming ON (6D/700D) */
                adtg_new[5]  = (struct adtg_new) {6, 0x8178, nrzi_encode(readout_end + 1) }; /* PowerSaveTiming ON (5D3/6D/700D) */
                adtg_new[6]  = (struct adtg_new) {6, 0x8196, nrzi_encode(readout_end + 1) }; /* PowerSaveTiming ON (5D3) */
                adtg_new[7]  = (struct adtg_new) {6, 0x8173, nrzi_encode(fps_timer_b - 1) }; /* PowerSaveTiming OFF (6D/700D) */
                adtg_new[8]  = (struct adtg_new) {6, 0x8179, nrzi_encode(fps_timer_b - 1) }; /* PowerSaveTiming OFF (5D3/6D/700D) */
                adtg_new[9]  = (struct adtg_new) {6, 0x8197, nrzi_encode(fps_timer_b - 1) }; /* PowerSaveTiming OFF (5D3) */
                adtg_new[10] = (struct adtg_new) {6, 0x82B6, nrzi_encode(fps_timer_b - 3) }; /* PowerSaveTiming ON? (700D) */
                /* ReadOutTiming registers */
                /* these shouldn't be 0, as they affect the image */
                adtg_new[11] = (struct adtg_new) {6, 0x82F8, nrzi_encode(readout_end + 1) }; /* ReadOutTiming */
                adtg_new[12] = (struct adtg_new) {6, 0x82F9, nrzi_encode(fps_timer_b - 1) }; /* ReadOutTiming end? */
                break;
            }
    }

Results were bad when viewing with preview set to on compared with the older code. Also tested the readout_end -= 10; and it seemd to shave of bottom part.
Take this with a grain of salt. Pretty tired over here so confirming from others are welcome.

Codebase:
https://bitbucket.org/Dannephoto/magic-lantern/branch/crop_rec_4k_mlv_lite_snd_sd_uhs_HDR_croprec

a1ex

Almost there - leave your custom definition for 0x800C, since that one is not covered in the generic block.

I'd expect these registers (PowerSaveTiming & ReadOutTiming) to work out of the box on any D5 model (tested on 60D, to some extent), but the other registers still need to be configured manually.

If it's still not working, try to figure out which register is causing issues. To do that, leave the old values for a subset of them, until you narrow down.

Edit: hold a second, found a typo at register 0x82B6 (not used on 5D3). Pushed the fix. The above still applies.

theBilalFakhouri

@a1ex

The generic way for (PowerSaveTiming & ReadOutTiming) is working in 700D in all presets  ;D
Updated code in this commit .


theBilalFakhouri

@a1ex

I'd like to fix something about detecting x5 mode and patch or don't patch this mode ,, as I understand you are using CENTER_Z preset (a preset for normal x5 mode when pressing zoom button twice so no registers were overridden except for centering preview) for checking if we in x5 mode or not --> Then apply the preset we chose in the right mode (e.g If I chose UHD preset the message appears I should got into x5 mode to use this preset the problem is this is not happening it's only patch x1 mode or mv1080 ).

Okay what I did (actually @mk11174 did it)  for force patching x5 to change this:

    /* cmos_vidmode_ok doesn't help;
     * we can identify the current video mode from 0xC0F06804 */
    for (uint32_t * buf = (uint32_t *) regs[0]; *buf != 0xFFFFFFFF; buf += 2)
    {
        uint32_t reg = *buf;
        uint32_t old = *(buf+1);
        if (reg == 0xC0F06804)
        {
if (is_5D3)
{
engio_vidmode_ok = (crop_preset == CROP_PRESET_CENTER_Z)
                ? (old == 0x56601EB)                        /* x5 zoom */
                : (old == 0x528011B || old == 0x2B6011B);   /* 1080p or 720p */
}

if (is_700D)
{
    engio_vidmode_ok = (crop_preset == CROP_PRESET_CENTER_Z_700D)
                ? (old == 0x4540298)                        /* x5 zoom */
                : (old == 0x4a601d4 || old == 0x2d701d4);   /* 1080p or 720p */


To this:


if (is_700D)
{
    engio_vidmode_ok =
                  (old == 0x4540298) ||/* x5 zoom */ (old == 0x4a601d4 || old == 0x2d701d4);   /* 1080p or 720p */
}


And this mean there are a problem with CENTER_Z_700D:
I think it's in this part of code ? 5D3 Uses CMOS 1 too for detecting x5 mode and there are something related to CENTER_Z ?

static int FAST check_cmos_vidmode(uint16_t* data_buf)
{
    int ok = 1;
    int found = 1;
    while (*data_buf != 0xFFFF)
    {
        int reg = (*data_buf) >> 12;
        int value = (*data_buf) & 0xFFF;
       
        if (is_5D3)
        {
            if (reg == 1)
            {
                found = 1;

                switch (crop_preset)
                {
                    case CROP_PRESET_CENTER_Z:
                    {
                        /* detecting the zoom mode is tricky;
                         * let's just exclude 1080p and 720p for now ... */
                        if (value == 0x800 ||
                            value == 0xBC2)
                        {
                            ok = 0;
                        }
                        break;
                    }

                    default:
                    {
                        if (value != 0x800 &&   /* not 1080p? */
                            value != 0xBC2)     /* not 720p? */
                        {
                            ok = 0;
                        }
                        break;
                    }
                }
            }
        }


I tried CMOS 7 or 5 for 700D (which have different values in mv1080, mv720 and x5) in the same way above but it didn't work.

Why we just detect current mode by ADTG2[800C] ? and if needed with C0F0[6804] ?

Short question:
How I can patch only x5 mode and get normal view (not patched) in mv1080 and mv720 like 5D3 when crop_rec on ?

Something related:
In old 720p 3x3 preset it's also patch mv1080 for 700D and give RAW detect error (white bar in the bottom) ,, we can make it only to patch 720p mode --> this will be something better for changing between the mods without worry about turning on and off crop_rec in mv1080.

Ballinger

Quote from: theBilalFakhouri on June 29, 2018, 04:47:20 PM
Experimental crop_rec with higher resolutions for 700D (it Should work for EOS M)

This is a great accomplishment in terms of unlocking these higher resolutions of course.  Realistically, from my own personal experience with the 700D and a class 3 write speed Sandrisk Extreme Plus SD card, everything is severely limited unless one overclocks the SD bus via Danne's Crop 4K build.  I can only yield maybe about 3 seconds of footage before frame skipping, even at the 2.5K preset.  Does anyone have any different experience?