mv1080 on EOSM

[dfort]

On EOS M, in standby, the LiveView is configured as 720p, even if you have selected 1080p in Canon menu...

Let's see if I got this right. So that means that this bit of code in src/raw.c is never true in standby:

Code: [Select]

    int mv1080 = mv && video_mode_resolution == 0;

Because of this in src/propvalues.h:

Code: [Select]

extern int video_mode_resolution; // 0 if full hd, 1 if 720p, 2 if 480p
However, this can be true:

Code: [Select]

    int mv1080crop = mv && video_mode_resolution == 0 && video_mode_crop;

Does this mean that LiveView on the EOSM is configured as 1080p when Movie crop mode is active? (This is also true in ZOOM mode, right?)

Tip: you can see the default LiveView configuration from the FPS override submenu, without turning it on.

I'm a little lost here. Where can I see the LiveView configuration?



Digging into src/fps-engio.c there's this:

Code: [Select]

#elif defined(CONFIG_EOSM)
    #define TG_FREQ_BASE 32000000
    #define FPS_TIMER_A_MIN (ZOOM ? 666 : MV1080CROP ? 532 : 520)
    #undef FPS_TIMER_B_MIN
    #define FPS_TIMER_B_MIN ( \
    RECORDING_H264 ? (MV1080CROP ? 1750 : MV720 ? 990 : 1970) \
                   : (ZOOM || MV1080CROP ? 1336 : 1970))

So are the timer values a hint at what the LiveView configuration is? There doesn't seem to be a definition for MV1080, is that because it just doesn't happen on the EOSM unless it is actually recording H.264?

Sorry if I'm asking too many questions. I'm just hoping something that I bring up sparks an idea.

The EOSM and 700D (and 650D) are very similar in many respects. They even have the same size LCD and show the same focus pixel patterns in raw video. I keep thinking there must be a way to get the EOSM to record mv1080 without having to simultaneously record H.264 but it is beyond my limited knowledge of this stuff.

I have focus pixels on my footage. I'm using 5:3 aspect ratio though 1.66..

How is that possible? When I try to set a 5:3 aspect ratio I get a warning, "Could not get 5:3. Max vertical resolution: 692." Are you using 1280 for your horizontal resolution? Could you upload a short sample MLV so I can check the focus pixel pattern and see if the tools to remove them are working?

[a1ex]

Where can I see the LiveView configuration?

Actual FPS. The resolution of the raw buffer (active area) can be seen under Rolling Shutter, if raw recording is enabled. Or, in the error messages from the raw recording submenu (if you try to select a higher resolution).

The full resolution (including black borders) can be seen on the console if you enable RAW_DEBUG in raw.c, or by taking a silent picture (which contains the full raw buffer) and developing it with "dcraw -4 -E". Its size is autodetected from EDMAC registers (it used to be hardcoded in raw.c, but it's no longer the case).

So that means that this bit of code in src/raw.c is never true in standby:

Code: [Select]

    int mv1080 = mv && video_mode_resolution == 0;


Correct.

However, this can be true:

Code: [Select]

    int mv1080crop = mv && video_mode_resolution == 0 && video_mode_crop;

Does this mean that LiveView on the EOSM is configured as 1080p when Movie crop mode is active?

IIRC yes (you can double-check).

There doesn't seem to be a definition for MV1080, is that because it just doesn't happen on the EOSM unless it is actually recording H.264?

No, mv1080 is handled on the "else" branch. But notice the EOS M uses RECORDING_H264 for choosing FPS_TIMER_B_MIN, and the reason for this is what you stated above.

I keep thinking there must be a way to get the EOSM to record mv1080 without having to simultaneously record H.264 but it is beyond my limited knowledge of this stuff.

This one is also beyond my knowledge, although not exactly in the "pipe dream" category (probably doable, given enough time and motivation).

[Teamsleepkid]

shot in 1152x692 1.66 aspect ratio 720 3x3 mode. I realize this looks like crap it was shot at iso 3200 with like a 30 watt light bulb in my room. you can see white focus pixels on the pillow in the middle. I also boosted contrast so they are easier to see. You can also tell by the vignette on the lens that the picture isn't centered its more towards the top of the frame. link to video

https://vimeo.com/189469270

[dfort]

...you can see white focus pixels on the pillow in the middle...

Yes I can see that and I was also able to reproduce the issue over here with your 1152x692 frame size. MLVFS unsqueezed the frame so the aspect ratio is wrong and it didn't removed the focus pixels while Danne's new cr2hdr.app has the right aspect ratio but didn't remove the focus pixels either. Darn it, no focus pixels was too good to be true. I think the frame I was using was so far off center that it missed the focus pixel area in the center of the sensor.

@a1ex -- thanks for taking the time to answer my questions. Here's what I discovered with the various MLV settings. I didn't check H.264 or raw v1.0. I'm using the 700D as a baseline and hopefully people reading this won't confuse Movie Crop Mode with the Crop Record module.

700D:
Canon menu set at 1080/24p - Actual FPS = 23.970  Rolling shutter : 19.1 ms at 1736x1158
Canon menu set at  720/60p - Actual FPS = 59.946  Rolling shutter : 11.5 ms at 1736x695
Canon menu set at 1080/24p - Actual FPS = 23.970  Rolling shutter : 17.6 ms at 1800x1082 <- Movie Crop Mode
Canon menu set at 1080/24p - Actual FPS = 29.954  Rolling shutter : 24.2 ms at 2520x1080 <- ZOOM Mode

EOSM:
Canon menu set at 1080/24p - Actual FPS = 29.973  Rolling shutter : 11.4 ms at 1734x693
Canon menu set at  720/60p - Actual FPS = 29.973  Rolling shutter : 11.4 ms at 1734x693
Canon menu set at 1080/24p - Actual FPS = 23.970  Rolling shutter : 17.5 ms at 1798x1026 <- Movie Crop Mode
Canon menu set at 1080/24p - Actual FPS = 29.975  Rolling shutter : 24.0 ms at 2518x1074 <- ZOOM Mode


EOSM using crop_rec.mo:
Canon menu set at 1080/24p - Actual FPS = 29.973  Rolling shutter : 11.4 ms at 1734x693
Canon menu set at  720/60p - Actual FPS = 29.973  Rolling shutter : 11.4 ms at 1734x693

I used that "dcraw -4 -E" a lot when working on the focus pixel project so I'm familiar with the raw buffer. So if the raw buffer is an indicator of whether we're in mv1080 mode then it looks like the EOSM does go into mv1080crop mode but doesn't go into mv1080 mode even when using the Crop Mode module. Also note that if the frame rate is an indicator of mv720p mode, the EOSM doesn't really go there either.

[EDIT] Added ZOOM mode just for completeness.

[dfort]

Good news everyone. a1ex made a commit on the crop_rec branch so you no longer need to press PLAY twice to get into crop_rec mode. I built a new version with rbrune's modifications and put it in my bitbucket download area for testers.

[Teamsleepkid]

Thanks. I kept forgetting to push the playback button twice. Very helpful.

[Teamsleepkid]

is it hard to get it centered?

[rbrune]

I just pushed some new code to the pull request. The recorded area is now centered.

Here's a build to play around with, it includes the auto update code from a1ex:

https://drive.google.com/open?id=0B5FJDsqHlkJ6RmVrcUVXYk1kTHc

[Teamsleepkid]

Rbrune love you:)

[Danne]

rbrune, marvellous work.

[dfort]

@rbrune - Quick test on your latest binary and centering looks good. I only checked the 3x3 720p (1x wide) setting.

Noticed you have dot_tune in your modules. It shouldn't be in there for the EOSM. I see DeafEyeJedi had problems with it on your previous binary when he turned it on.

The focus pixel removal tools still aren't working. I'll need more time to figure it out but the way it works is that it uses the raw buffer size for that camera model to determine what focus pixel map file (fpm) to use. It looks like crop_rec (3x3) has the same 1734x693 raw buffer size as "regular" 720p mode (3x5) so this is going to be a challenge.

The focus pixel removal function also looks at the Crop and Pan values to figure out what portion of the fpm file to use. mlv_dump -v is reporting these values:

Code: [Select]

    Crop: 304x28
     Pan: 298x28


[rbrune]

@rbrune - Quick test on your latest binary and centering looks good. I only checked the 3x3 720p (1x wide) setting.

Noticed you have dot_tune in your modules. It shouldn't be in there for the EOSM. I see DeafEyeJedi had problems with it on your previous binary when he turned it on.

The focus pixel removal tools still aren't working. I'll need more time to figure it out but the way it works is that it uses the raw buffer size for that camera model to determine what focus pixel map file (fpm) to use. It looks like crop_rec (3x3) has the same 1734x693 raw buffer size as "regular" 720p mode (3x5) so this is going to be a challenge.

The focus pixel removal function also looks at the Crop and Pan values to figure out what portion of the fpm file to use. mlv_dump -v is reporting these values:

Code: [Select]

    Crop: 304x28
     Pan: 298x28


Yes, the focus pixel removal needs to be adapted. A1ex suggested a new internal structure that will be saved out in the mlv file that would make fixing focus pixels easier and compatible with the crop_rec module.

[dfort]

Yes, the focus pixel removal needs to be adapted. A1ex suggested a new internal structure that will be saved out in the mlv file that would make fixing focus pixels easier and compatible with the crop_rec module.

Up until now the full raw buffer sizes of each raw video mode were different. Now on the EOSM we have the current mv720 and the new crop_rec mv720 both a full raw buffer size of 1808x727 and active area of 1734x693 but of course with different focus pixel patterns. a1ex pointed out this problem a while back on the Dealing with Focus Pixels in raw video topic a while back.

I'll work on getting a new pixel map for this crop_rec mode and post my notes on the focus pixel discussion.

[Teamsleepkid]

so is this the same as mv1080 on the other cameras? or are we getting a little more moire and aliasing than the others? this is mv720 3x3 right not mv1080? just wondering...

[nikfreak]

@dfort while we are at it can you take a look over here please:

https://bitbucket.org/hudson/magic-lantern/pull-requests/746/700d-rawc-finetune-raw-photo-raw-liveview/diff

Then afterwards compare with my PR:

https://bitbucket.org/hudson/magic-lantern/pull-requests/757/adding-support-for-the-eos-100d-sl1/diff#Lsrc/raw.cF579

My gut feeling says we should unify the offsets for EOSM/650D/700D/100D as seen on Matthew's declined PR. On the other side this looks like to cause some troubles. As far as I recall MLVProducer implemented your dots map

Just wanted to shoot out some kind of warning for you to be prepared  for a unifying scenario

Back to topic

[a1ex]

Right, if the focus maps can be updated, I also think it's best to unify the offsets.

[dfort]

I've been working on making a focus pixel map file for this @rbrune pull request. I almost forgot what a PITA it is finding all the focus pixels. This new map appears to match the mv1080 map which makes sense because it is a 3x3 pattern though the full raw buffer size is the same as the mv720 (3x5). The focus pixel map files are based on the full raw buffer so if the Crop and Pan offsets are changed it shouldn't affect the map file.

I thought I had it all figured out last night but it failed the lens cap test. Basically, shooting a dark frame and adjusting the develop settings to reveal the noise will also reveal the focus pixels.

@Teamsleepkid - to answer your questions, the focus pixels in this new video mode are more subtle, the aliasing is less of a problem and the frame doesn't need to be stretched in post to correct the aspect ratio. For all practical purposed this is just like mv1080 mode except that the vertical resolution is limited to a maximum of 692 pixels instead of 1158.

[dfort]

Ok--got the pixel map for the @rbrune crop_rec EOSM module. If anyone is interest in how the pixel map file was made:

http://www.magiclantern.fm/forum/index.php?topic=16054.msg174322#msg174322

The focus pixel map file lives here until we can figure out how to deal with two video modes that share the same raw buffer size.

If anyone wants to test this I made a binary along with the focus pixel map file that can be used with MLVFS. But wait, there's more! I also included a special version of MLVFS for Mac that has the fpm file installed and has a slight tweak Danne made to deal with with aspect ratio of the crop_rec video format. Windows and Linux users can install the fpm file but I can't help you there. Finally, I also included a dcraw badpixels formatted text file for 1280x692 if anyone wants to use dcraw. It is in my bitbucket download area:

https://bitbucket.org/daniel_fort/magic-lantern/downloads

I do have some comments now that I've played around with this crop_rec module. Of course the most obvious anomaly is that the LiveView is stretched vertically so things look a bit weird. Another thing that is more of a problem with me is that the frame rate runs at 29.97 instead of 23.98. Sure, you can use FPS override but then you can't record sync audio with mlv_snd. The higher frame rate also reduces the largest frame size that you can record continuously. Not to mention that being an old film guy I prefer the look of 24fps video. Of course if the EOSM could run mv720 at 59.94 like the other cameras then I'd be all over that for slow motion even if it means having to use a smaller image size.

[Teamsleepkid]

tried it but i still have focus pixels.. maybe i missed somethin? reinstalled the version of magic lantern in the download and installed the new tweaked mlvfs for mac..focus pixels on my footage after trying normal and aggressive settings. are we supposed to do something with the fpm file that in missing?

[dfort]

Are you using both the crop_rec and mlv_rec modules? crop_rec needs to be set to the 3x3 setting and on the bottom of the LV screen if you see a warning icon then try going into and out of the ML menu, had that happen to me once. Other than that it should be working with the MLVFS in the package, the new focus pixel map file is installed.

If you're still having issues, upload a small MLV file so we can take a look at it.

[Teamsleepkid]

https://vimeo.com/190420176

in the bookshelf area focus pixels they are really hard to see but if you add sharpness and contrast they come out. easier to see if you watch in 1080p on vimeo.

[Teamsleepkid]

https://drive.google.com/open?id=0B_4dpBYObDvEZHZGekdMdUlBX28

mlv file with focus dots made sure i was in 3x3 mode no warning sign. i am using the 1.66 aspect ratio does that make a difference? does this only work in 16x9? used mlvfs tweeked version from your post.

[dfort]

Yes, I see them. Darn it. Some of these focus pixels are hard to find and they only show up in certain situations. I'm able to find some of the ones I missed by shooting a dark frame. For some reason the focus pixels in crop_rec are more subtle than other video modes and it also seems to have a different pattern.

Here are some of the suspected focus pixels that show up in your sample footage:



(Talk about pixel peeping!)

If you want to help out, here's how to make a focus pixel map file:

http://www.magiclantern.fm/forum/index.php?topic=16054.msg174322#msg174322

[Teamsleepkid]

Just wanted to let you know. Not trying to be a jerk. Still wondering if true mv1080 would have less aliasing..I've been taping plastic in front of the sensor to try to make a fake vaf. . Funny thing is the best one so far was taping a piece of 35mm film in front. Not practical at all though cause I lose a stop or more of light. Does help with the aliasing though..

[rbrune]

Just wanted to let you know. Not trying to be a jerk. Still wondering if true mv1080 would have less aliasing..I've been taping plastic in front of the sensor to try to make a fake vaf. . Funny thing is the best one so far was taping a piece of 35mm film in front. Not practical at all though cause I lose a stop or more of light. Does help with the aliasing though..

This mv720 mode with 3x3 binning has exactly the same amount of aliasing as mv1080 would have. It is 3 horizontal columns binned while recording every third line. The EOSM won't ever have the quality of 5D3 binning where pixels are binned in both horizontal and vertical direction - at least as far as we know this is part of the digic processing in the 5D3.