Messages

Hi. Do you have fps override enabled when changing modes with memory hack on?

If so, I think the problem resembles the one I have on 6D. This issue is no related to recording:  LV is NOK also. The change of video modes (memory hack requires a set_lv_zoom to return from pause lv) with fps override (with overrides far from fps native) and shutter speed high (1/500 and beyond) is prone to sporadic LV problems.  The same thing if we change video mode with the loupe.

But on 6D it's worst than green tint, there are other artifacts.

Hi, baldand. With several fps overrides on source, for instance 36 fps on no crop mode over 1080p canon video mode (RAW or MLV), the resulting movs are NOK (the video flickers up and down). I think that it's not able to guess the source fps. The  DNG's are OK.

Perhaps it's not the solution, but in either case it will be useful that we can choose the mov fps (source, 24, 25, 30, 48, 60) for instance.

Another handy improvement will be that if we are viewing in anamorphic unsquetched(A), and we save to mov, the mov saved would be unsquetched also.

I've tested from a Canon 6D and 1.1.3 over Mac OSX.

Very good work!!!! Thanks a lot.

I think it's OK.

For instance 1808 and 2672, the resolutions that crashed the 6D (prior changing  %16 to %32 on raw_rec) verify the condition:  dst_width%8 != 0, so the crash is gone and the safety check is fault tolerant enough.

Thanks a lot.

[if ( dst_width % 16 ) return 0;]

There are also no more crashes on 6D with %32.

The problem was the check at edmac_copy_rectangle_cbr_start that you suggested in the patch and I modified a bit (changing src_width by dst_width)
if ( dst_width % 16 ) return 0;   at some resolutions, the check verifies and returns.

for instance 2656 because dst_width is 4648 and 4648%16 != 0.

We have to remove this check or choose  this one if ( ( dst_width*8 ) /14 % 16) return 0

Whatever we do, it works.

[if ( ( dst_width*8 ) /14 % 16) return 0]

Well, the problem is dst_width is transformed previously by a factor 14/8, and 2656*14/8 = 4648 % 16 != 0

Perhaps this safety check in edmac should be :

if ( ( dst_width*8 ) /14 % 16) return 0

For 1x works with %32, but for 5x we need %64. I get data corruption: it selects 2656.

Of course. I applied it manually (I've a a slightly modified version)

OK for %64 only (tested in raw_rec).

The upper patch I think it's obsolete (the resolutions). I don't apply them.

The changes at edmac-memcpy at 5x cause data corruption at all resolutions. But it's OK if we check only dst_width.

Humm. OK. Several battery removes and I can conclude:

Only when I select a resolution that excedes cam capabilities, for instance 1920 for 1X. Or 3584 for 5X.

At 1X the cam selects 1808 as x_resolution for 1X and 2672 as x_resolution max for 5X.

As I  record sometimes  at different resolutions for 1X and 5X and I found very handy the automatic computation.




   

[edmac-memcpy.c]

About the backporting to ML.

I'm doing a lot of tests on raw_rec and mlv_rec on 6D ML version.
I've found two issues.
1)  edmac-memcpy.c dmaFlags should be  0x20001000, as we have in TL. The other 0x40001000 hangs the cam (battery remove and so on) and get error EDMAC timeout in raw_rec. mlv_rec doesn't hangs but the recordings no OK. I propose something like that:

void* edmac_copy_rectangle_cbr_start(...
{
    take_semaphore(edmac_memcpy_sem, 0);
    
    /* see wiki, register map, EDMAC what the flags mean. they are for setting up copy block size */
    #if defined(CONFIG_6D)
      uint32_t dmaFlags = 0x20001000;
    #else
      uint32_t dmaFlags = 0x40001000;
    #endif

2) raw_rec.c hackliveview there is no reference to 6D. It's necesary to inform it

uint32_t dialog_refresh_timer_addr = /* in StartDialogRefreshTimer */
            cam_50d ? 0xffa84e00 :
            cam_5d2 ? 0xffaac640 :
            cam_5d3 ? 0xff4acda4 :
            cam_550d ? 0xFF2FE5E4 :            
            cam_600d ? 0xFF37AA18 :
            cam_650d ? 0xFF527E38 :            
            cam_7d  ? 0xFF345788 :
            cam_700d ? 0xFF52B53C :
            cam_60d ? 0xff36fa3c :
            cam_6d  ? 0xFF52BE94 :

[With fps override off]

Hi, on 6D (ML version, but in TL it's the same thing) I've perceived a pair of days ago some flickering with fps override when I adjust the shutter speed to 1/600 and up. Mostly at very high shutter speeds. The effect is notorious even on the screen on liveview. That implies no post-processing issue. Of course all exposure settings manual.

After more close investigation I can say:

1) With fps override off,  no issue

2) With High Jello setting no issue

3) With all other settings it's NOK. But with  High fps sometimes ok sometimes nok. Switching modes helps to get OK on high fps mode.

4) Only issues on 1x. At 5x. all OK.

[set_lv_zoom]

I've been testing the nightly build of 6D an I found:

1) raw_rec Small hacks don't work. "Hack Error on screen expected xxxxxx, obtained yyyyyy". Tragic Lantern compiled version is OK (well, no error on screen).

2) fps override 18 fps on 24 1920x1080 IPB video mode, for example, High FPS for example, high shutter speed < 1"/800, when I change from 1x to 5x, sometimes image on "false color" (see example images on URL). Changing modes, image recovers, then no big issue. The problem arises in callings to function set_lv_zoom . The problem is most important when activating memory hack in raw_rec or mlv_rec, because callings to ResumeLiveView that calls itself to set_lv_zoom. Then sometimes when start recording the image gets "false color" and record is KO.

As a workaround I modified raw_rec calling fps_disable and fps_enable before and after calls to ResumeLiveView. It works but it's ugly and frames 3 and 4 are overexposed (perhaps because fps_enable is not instantaneous).

The issue is on ML and TL versions.

https://www.dropbox.com/sh/0s7ayi40o6w4ted/fvPZXHrIZt

Well 1%, alex.  As an user, I've been compiling and intensively using the magic lantern unified branch for 550D, and the tragic lantern branch for 6D for a lot of months, and I only can say that stability never be an issue in none of them. It's indeed astonishing, because of continuous changes on the code that arised almost every day, and the reverse engineering nature of designs.

Risks, if there are, were primarily related to my own experiments with the code :-(

What I believe is that it's a pity, the fact that there are not a consensus between you two, to unify the two branches. Perhaps you need to accept the point of view of the other in some items, a posible way for that it's refactoring some things in 6D as modules (birate...?), I don't know but I think it will be a great benefit for the project.

I want to encourage you to reach that consensus.

Whatever happens, I have only thanks to both of you and all the team of developers and testers.

Buf, yes is a big difference in isos, but no perceived issues in crop mode (indeed very powerful tool for macro video (invaluable) : raw+dualiso+3x crop, no significant detail loss and good control of highlights in flowers and so on) It's the mode that I are using mainly.

At this folder I put another test ("mike wasorsrki" test with silent pics and iso 100/6400), The dots are far less perceived than  the previous example (only in the edges of the speaker holes in the right). The silent pics are better.

https://www.dropbox.com/sh/mlawr8tgfsb25zm/C1CcLNwK2M

edit 1: I don't use lv_af_raw (I supose because I don't know what is this  , another module?)

Thanks a lot.

Of course. The same frame processed with raw2dng.exe mono_iso:

https://www.dropbox.com/s/br7jllyqe6rjpu9/M24-1127000012.interlaced.dng

I've been trying differents methods of demosaicing in rawtherapee whitout luck.

Yes, it works very well in crop mode. In normal mode we obtain coloured groups of dots, I think probably aliasing. An example.

https://www.dropbox.com/s/823nmk7d7zwvsmh/M24-1127000012.dng

Same result if I process with raw2dng.exe mono_iso and apply cr2hdr or cr2hdr_exp to dngs, obtained by raw2dng.exe dual_iso.

(6D)

No, it's similar than processing monoiso raw video. You only need a specific version of raw2dng.exe from first post of the thread http://www.magiclantern.fm/forum/index.php?topic=7139.0. No need of cr2hdr.

I found a bug with 720P and fps override, after recording finishes, it does something with timing and messes up the LV, you have to press play to get it back.

I think this is what nanotide was talking about. Its like FPS doesn't update some times when mode changes. Also happens going from 720 -> 24 and its most prevalent at exact FPS, 23.976. I never saw it from those other FPS modes.

Yes it seems the same issue, but I found it on other FPS modes. Perhaps it's necessary to set a sleep time somewhere.

No its no zebras sometimes pinkish or greenish. Its there i think after adtg fps override.
If I repeat zoom with the loupe button one or more times from 1x to 5x its ok. Sometimes its not only false color, also the image becomes half image. Changing from photo to video it happens also.
Fps override whatever the override mode and whatever the fps.

With fps override when i change between 1x and 5x modes sometimes I get false colour on display. This issue also happens sometimes when i stop record raw video.
Thanks a lot for this very good job. Dual iso is a new gift.

Can anyone try how many seconds is it possible to record at highest resolutions  3k 3.5k at 24fps and 18-20 fps witnout frame skip?
Thanks a lot

Hi, time to use RAW on field: macro video for flying insects (lepidoptera, odonata, neuroptera, ... )

I've shooting compiling latest 6D sources. A resume of my configuration-equipement
   6D, of course
   canon 300mm F4L
   teleconverter kenko 1.4x
   sandisk extreme pro 95 32 GB exFat
   sandisk extreme 64 GB (exFat)  (note: no difference with pro)
   raw modes I prefer 1808x678 (2.67) or 1792x762 (2.35) at 1x or 5x and 2560x958 (5x)
   24 fps or 18fps (duplicating frames in post, no resampling in vegas, no interpolation (twixtor))
   tripod manfroto mkc3-h1


Well, I take photos and video, depending on shot conditions. It's very difficult take a long (or short) video to a flying insect, because they remain only a few
seconds over a flower (then for me a few seconds (7"-10") of RAW continuous shooting is a extraordinary gift)

Then, most of the time I take photo, but if I think I've a chance to take a video I need switch modes speedly,
reusing camera settings (focus, aperture, ..., framing and so on). And camera on tripod all the time.

My present field workflow is focus and framing with evf in photo mode, (take a photo sometimes), swhitch to video mode (perhaps another framing in 5x), and take a video.
Manual mode, shutter and aperture fixed, iso auto.

I've been in field for 12 hours, four different days. A lot of GB of raw video and photos on the cards and I can say I've no stability issue.
Perhaps one time I remember need to take off the battery. Truly very very good job!!!

I've some problems.

1) Flickering. See video. The exposure changes as the butterfly covers more or less frame surface, opening and closing the wings. ¿It's a expected result from iso auto?. These are 5x  takes.
Note: Perhaps expo override is the solution.  I need to try it more. I shot without expo override, because for that I need change my workflow (no autoiso), no valid photo configuration.

http://www.youtube.com/watch?feature=player_detailpage&v=U14qXH2X-L8

2) With fps override I need to check Fast Tv, to match photo settings because this mode has the most shutter range to match my phot settins (Tv < 1/800, 1/1000, ...).
Exact FPS and low light don't have so shutter range. But Fast Tv is high jello and sometimes brings to undesirable results last shot in video (2560x958 18fps has apparent jello effect). But in previous builds I think it was
possible to have high shutters with Exact FPS or Low Light.  ¿It will be possible to have fast shutter speeds on these modes?

Best regards

xEightLives, you have lost one live in this forum   

The developers have chosen 1792 over 1824 for optimization purposes: more  frames saved on disk without skips. There is a mathematical-algorithmic trick based on getting sizes multiples of certain number.

And 1792 scales very well to 1824.

sparedog,  5x is a digital teleconverter of 3x, 24 mm becomes a 72mm equivalent

we call this 5x because we get that with the 5x mode zoom of the cam, but the image we obtain is 3x.

but no more than 3x: 5x mode is not linked to video mode.

the good, the image is on the center of the lens. distortions. less than full frame image

optical quality better than full frame image but image quality less than a raw photo image: it's a 100% crop of a raw photo image, but better than full frame raw video image, because this one  is "like" a crop of the sensor (same number of points selected)  but getting points sparsely over all the surface of the sensor = moire and aliasing.

The best cams for 5x mode: the cams with the less sensor density of points: full frames, ... 6D perhaps the best
 

on 5x mode the moire is 0x, or nearly.

Gobian, in order to get the memory hack from Alex you need select Memory hack ON on RAW menu and photo quality RAW, not jpg (the oposite as nr noise reduction, that needs jpg). Because that trick I thought at first (and I think 1% also) that the hack didn't go on 6D.
And really is better than 5Dm3. We have 3 more 32m buffers. 5Dm3 only 2 (but they have CF...) (Then with this hack you can take RAW photos and RAW videos without changing configuration)

Doing so, you get 7 buffers on raw recording, video or photo

For raw video stabilization in photo mode I use start delay to 2 sec. on raw menu, to get time to start pressing  the shutter button all the time while recording (M mode)