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

[denishogan]

Thanks Alex, I will test tomorrow and ensure I wait a few seconds

cheers
Denis

[a1ex]

Based on the record LED the frame gets captured on half press (not release) but the delay on the release may be holding up other functions.

That's correct - the buffered is queued for saving to card shortly after the half-shutter press (at the next LiveView frame). If you try this at a very low frame rate, you will see the delay (uniform distribution between 0 and 1/FPS). What actually gets saved, is the frame that was already captured (in memory) at the moment of queuing (so you can usually expect some part of the frame to be captured before the trigger signal). Didn't actually test this behavior; it's just what I'd expect to happen. Such a test can be easily done with some ambient light activated at the same time as the half-shutter trigger.

I don't expect any side effects from the half-shutter release delay - this event is not even handled by ML in this trigger mode. Canon firmware will handle it in background (e.g. for exposure metering or whatever else they do on half-shutter press).

So, whatever the "duty cycle" of the trigger signal may be, as long as it's detected, I expect the results to be identical - the only important factor being when half-shutter state changes from "not pressed" to "pressed" (and the phase difference between that event and the LiveView image capture clock).

[miket]

On my 5d3 with 1.1.3 the 3K crop mode only goes to 3072x1504.  I am trying to get to 1920 verticle.  I can get to 3075x1920 in 3K crop mode once but after making a few recordings and shutting down to remove the CF card the verticle res is lower and won't go any higher in raw video menu.  What am I forgetting to check?  I have live view at 1920 30p all I frames (or IPB).  Leaving menus, leaving live view and returning or shutting down and powering back up don't help.   Thanks!

[dfort]

I've been doing some lossless compression full resolution lossless compression testing on the 700D and EOSM. Looks like this has been a problem for a long time and I didn't notice it until recently. This might also have something to do with video recording stopping prematurely with lossless compression on these cameras. I was able to revive one of my closed branches where this was working but am having a tough time merging it with the current crop_rec_4k branch.

Another issue that came up was that the EOSM raw buffer seems to have shifted 8 pixels on the X axis in this branch so the focus pixels are showing up again in the various MLV processing apps. Need to do more testing to see what settings are affected and what caused the shift.

[Danne]

Lossless 14/12bit movie shooting seems to work here both crop_rec and regular mv720(no premature stops). Did you set FPS override to 24fps?
Didn´t manage to save into a lossless fullres DNG but saves to DNG if not lossless.
I tested on an eosm.

[a1ex]

@dfort: if the linked changeset is working fine, try this to compare it to current crop_rec_4k:

Code: [Select]

hg diff -r 1df43b139bc -r crop_rec_4k > changes.patch

but there are a lot of changes. It may be helpful to test the current crop_rec_4k with lossless.c from 1df43b139bc:

Code: [Select]

hg up crop_rec_4k -C
hg revert -r 1df43b139bc modules/silent/lossless.c

If that works, the change we are looking for is in lossless.c; otherwise, it's somewhere else.

It may be helpful to try "hg bisect", considering the changes made on top of crop_rec_4k (1df43b139bc vs 6591b1c69642, or even a31a03714911 vs b98026c9978f) - at least a31a03714911 should be working:

Code: [Select]

hg diff -r 6591b1c69642 -r 1df43b139bc > 700d-eosm.patch
hg diff -r b98026c9978f -r a31a03714911 > 700d.patch

However, these patches won't apply cleanly to future revisions of crop_rec_4k, so it's best to see whether FRSP lossless compression was working in vanilla crop_rec_4k, immediately after merging (ebf206a3a2d1).

Code: [Select]

hg diff -r ebf206a3a2d1 -r 1df43b139bc

This shows minor differences in lossless.c (except for a missing decompress_init, which shouldn't matter), so I expect it to work. If so, narrowing down will be as easy as running "hg bisect" on crop_rec_4k:

Code: [Select]

hg bisect --reset
hg up ebf206a3a2d1 -C
hg bisect --good
hg up crop_rec_4k -C
hg bisect --bad


[dfort]

Code: [Select]

hg diff -r ebf206a3a2d1 -r 1df43b139bc

This shows minor differences in lossless.c (except for a missing decompress_init, which shouldn't matter), so I expect it to work.

Nope--it doesn't work. That's one of the early revisions that had the scary null pointer warning but it doesn't save a lossless compressed FRSP DNG on either the EOSM or 700D.

On the EOSM it does flash a warning. I had to shoot a video with my phone to read it:



Maybe that's a clue?

If so, narrowing down will be as easy as running "hg bisect" on crop_rec_4k:

I had to read up on "hg bisect" and it looked like something I was thinking about doing manually--start with a working version and step through the revisions until it breaks. Unfortunately the only revision that works with both the 700D and EOSM is 1df43b139bc so if I try this:

Code: [Select]

hg bisect --reset
hg up 1df43b139bc -C
hg bisect --good
hg up crop_rec_4k -C
hg bisect --bad
abort: starting revisions are not directly related

I'm pretty sure lossless compression for EOSM/700D was done by cherry picking bits from ErwinH and me. At least I can't find a formal pull request. Back when this was going on I was looking at only video files on the crop_rec_4k branch. I didn't even know it was supposed to be able to do lossless compression with the silent module.

So the next thing I'm going to try is to make small changes on the working version until it breaks.

[a1ex]

In this case, I'd try something like this:

Code: [Select]

hg bisect --reset

# take Erwin's compression changes only (less chances for conflicts)
hg diff -r b98026c9978f -r 5b6936ed7aab > 700d-compress.patch

# crop_rec_4k revision Erwin started from
hg up b98026c9978f -C

# make sure the patch applies cleanly
patch -p1 < 700d-compress.patch

# compile and test again, just to be sure it works
# the result should be identical to 5b6936ed7aab -
# Erwin's version before decompression and 5D3 patch
hg bisect --good

# crop_rec_4k after merging (not working)
hg up ebf206a3a2d1 -C
hg bisect --bad

then, at every step, before compiling, apply the changes from 700d-compress.patch:

Code: [Select]

patch -p1 -F 100 < 700d-compress.patch

then compile and test as usual,

then, undo the patch before answering whether the build was working or not:

Code: [Select]

hg revert --all; hg bisect --good # or hg bisect --bad

and re-apply it again at the next iteration.

[dfort]

Thanks a1ex, that's a lot more sophisticated than my kindergarten method of adding one file at a time to the branch that works. Though I have managed to isolate it to something, I don't know what yet, in silent.c.

[EDIT] Getting closer but not worth bringing too much attention to it because I didn't follow instructions--yet. I started with the working version of silent.c and copied pieces of the current silent.c until I narrowed it down to the save_lossless_dng function. Yeah, that makes sense. Now to figure out which commit broke FRSP lossless compression on the EOSM/700D. Probably best if I go back and re-read the previous post.

[dfort]

Continuing on the quest to find what's going on with FRSP lossless compression on the 700D/EOSM. Knowing that the problem is with the save_lossless_dng function in modules/silent/silent.c, there's what I did:

Code: [Select]

# Made a copy of my repository using the Mac Finder
# Yeah--I know, bad form. Got a space in the path name but hey.
# Why did I make a copy? You'll see in a minute.
cd magic-lantern\ copy/
hg bisect --reset
hg diff -r b98026c9978f -r 5b6936ed7aab > 700d-compress.patch
hg up b98026c9978f -C
217 files updated, 0 files merged, 381 files removed, 0 files unresolved

# Apply patch
patch -p1 < 700d-compress.patch
patching file modules/silent/lossless.c
patching file src/boot-hack.c
patching file src/debug.c
patching file src/raw.c
patching file src/tasks.c

# Looks like Erwin didn't touch modules/silent/silent.c so I'll be copying
# silent.c to my "real" repository -- now it should be clear Why
# I made a copy. I wanted to isolate just the changes in silent.c
# This also allowed me to stay on 700D.115 for these tests.
hg bisect --good
hg up ebf206a3a2d1 -C
130 files updated, 0 files merged, 7 files removed, 0 files unresolved

hg bisect --bad
Testing changeset 16504:8040bdc22e2f (24 changesets remaining, ~4 tests)
89 files updated, 0 files merged, 12 files removed, 0 files unresolved

# At first I was applying the patch and reverting but then I realized that
# since there were no changes to silent.c in the patch this had no effect
# so I stopped doing that. Cutting to the chase:
...

The first bad revision is:
changeset:   16504:8040bdc22e2f
branch:      crop_rec_4k
user:        alex@thinkpad
date:        Sat Aug 19 01:18:35 2017 +0300
summary:     exmem: do not keep track of full shoot memory allocations
Looking up that commit, it didn't touch silent.c. However, what I did discover is:

This works--lossless compressed DNG on FRSP:

Code: [Select]

static int save_lossless_dng(char * filename, struct raw_info * raw_info)
{
    struct raw_info out_raw_info = *raw_info;

    ASSERT(out_raw_info.bits_per_pixel == 14);

    /* compress the image in-place */

    /* skip the top bar (that way, we'll be able to avoid race conditions) */
    int dy = out_raw_info.active_area.y1;
    int dm = dy * out_raw_info.pitch;
    void * output_buffer = out_raw_info.buffer;     /* output buffer = real buffer */
    out_raw_info.buffer += dm;                      /* input buffer = real buffer + top bar size */
    out_raw_info.frame_size -= dm;
    out_raw_info.height -= dy;
    out_raw_info.active_area.y1 -= dy;
    out_raw_info.active_area.y2 -= dy;

    struct memSuite * out_suite = CreateMemorySuite(output_buffer, raw_info->frame_size & ~0xFFF, 0);
    out_raw_info.frame_size = lossless_compress_raw(&out_raw_info, out_suite);
    ASSERT(out_raw_info.frame_size < raw_info->frame_size);
    out_raw_info.buffer = output_buffer;
    DeleteMemorySuite(out_suite);

    int ok = save_dng(filename, &out_raw_info);
    if (!ok) bmp_printf( FONT_MED, 0, 83, "DNG save error (card full?)");

    return ok;
}

But what is in the latest version of silent.c doesn't work:

Code: [Select]

static int save_lossless_dng(char * filename, struct raw_info * raw_info)
{
    struct raw_info out_raw_info = *raw_info;

    ASSERT(out_raw_info.bits_per_pixel == 14);

    /* fixme: not all models are able to allocate such a large contiguous chunk */
    int max_compressed_size = ((uint64_t) raw_info->frame_size * 80 / 100) & ~0xFFF;
    struct memSuite * out_suite = shoot_malloc_suite_contig(max_compressed_size);

    if (!out_suite)
    {
        bmp_printf( FONT_MED, 0, 83, "Out of memory");
        return 0;
    }

    ASSERT(out_suite->size == max_compressed_size);

    out_raw_info.frame_size = lossless_compress_raw(&out_raw_info, out_suite);

    if (out_raw_info.frame_size > out_suite->size)
    {
        bmp_printf( FONT_MED, 0, 83, "Warning: output truncated (%s)", format_memory_size(out_suite->size));
        out_raw_info.frame_size = out_suite->size;
    }

    out_raw_info.buffer = GetMemoryAddressOfMemoryChunk(GetFirstChunkFromSuite(out_suite));

    int ok = save_dng(filename, &out_raw_info);
    if (!ok) bmp_printf( FONT_MED, 0, 83, "DNG save error (card full?)");

    shoot_free_suite(out_suite);

    return ok;
}

Still trying to narrow this down even further.

[a1ex]

Just to double-check: does it execute this line?

Code: [Select]

        bmp_printf( FONT_MED, 0, 83, "Out of memory");

(if in doubt, add a beep or some LED blinks)

[dfort]

I don't get the "Out of memory" message but do get the "DNG save error (card full?)" message.

Note that with the working version of the save_lossless_dng function I get a "RAW error, falling back to YUV overlays" but the compressed DNG is saved.

[a1ex]

I know, I was asking whether that line of code gets executed, not how the visible feedback looks like.

[dfort]

Code: [Select]

    if (!out_suite)
    {
        beep();
        bmp_printf( FONT_MED, 0, 83, "Out of memory");
        return 0;
    }

No beep no message no lossless compressed DNG saved.

[dfort]

Found  out that if I back up all the way to the silent.c in a9c8ad4 and keeping everything else at the lastest in crop_rec_4k the FRSP lossless compression DNG issue with EOSM/700D is not present. Updating to commit f6d95f2 the issue shows up. The commit message is:

silent: do not compress DNGs in place
(fixes various issues, but memory management is more difficult)

Not sure if I've got my terms correct, changeset, commit, revision, whatever but these are the changes in the save_lossless_dng function. Maybe there's just one little thing in there that should be tweaked?

Code: [Select]

static int save_lossless_dng(char * filename, struct raw_info * raw_info)
 {
     struct raw_info out_raw_info = *raw_info;
 
     ASSERT(out_raw_info.bits_per_pixel == 14);
 
-    /* compress the image in-place */
+    /* fixme: not all models are able to allocate such a large contiguous chunk */
+    int max_compressed_size = ((uint64_t) raw_info->frame_size * 80 / 100) & ~0xFFF;
+    struct memSuite * out_suite = shoot_malloc_suite_contig(max_compressed_size);
+
+    if (!out_suite)
+    {
+        bmp_printf( FONT_MED, 0, 83, "Out of memory");
+        return 0;
+    }
 
-    /* skip the top bar (that way, we'll be able to avoid race conditions) */
-    int dy = out_raw_info.active_area.y1;
-    int dm = dy * out_raw_info.pitch;
-    void * output_buffer = out_raw_info.buffer;     /* output buffer = real buffer */
-    out_raw_info.buffer += dm;                      /* input buffer = real buffer + top bar size */
-    out_raw_info.frame_size -= dm;
-    out_raw_info.height -= dy;
-    out_raw_info.active_area.y1 -= dy;
-    out_raw_info.active_area.y2 -= dy;
+    ASSERT(out_suite->size == max_compressed_size);
+
+    out_raw_info.frame_size = lossless_compress_raw(&out_raw_info, out_suite);
 
-    struct memSuite * out_suite = CreateMemorySuite(output_buffer, raw_info->frame_size & ~0xFFF, 0);
-    out_raw_info.frame_size = lossless_compress_raw(&out_raw_info, out_suite);
-    ASSERT(out_raw_info.frame_size < raw_info->frame_size);
-    out_raw_info.buffer = output_buffer;
-    DeleteMemorySuite(out_suite);
+    if (out_raw_info.frame_size > out_suite->size)
+    {
+        bmp_printf( FONT_MED, 0, 83, "Warning: output truncated (%s)", format_memory_size(out_suite->size));
+        out_raw_info.frame_size = out_suite->size;
+    }
+
+    out_raw_info.buffer = GetMemoryAddressOfMemoryChunk(GetFirstChunkFromSuite(out_suite));
 
     int ok = save_dng(filename, &out_raw_info);
     if (!ok) bmp_printf( FONT_MED, 0, 83, "DNG save error (card full?)");
 
+    shoot_free_suite(out_suite);
+
     return ok;
 }

[g3gg0]

holy moly.... the first thing i can think of - steampunk
cool!

[g3gg0]

1 frame half press trouble

Thank you ML devs and testers for the awesome features in the crop_rec exp builds!  I have been testing the many recent versions on a telecine machine I have been building and will exhibit next weekend at the NYC Maker Faire.  The project uses the crop_rec with half press / 1 frame only externally triggered by a movie projector synced with a reed switch to capture each frame of the film into an mlv file.

could you possibly genlock your steampunk device's motor to the camera?
so the camera's card LED blinks a msec whenever a MLV frame was captured, signalling the stepper should advance one frame?
then the projector runs as fast as the camera is recording...

[dfort]

Found a fix for EOSM/700D to get lossless compression working on full resolution silent pictures. Posted it in the Full-resoution silent pictures topic so instead of double posting, I'll just quote myself:

Did a very hackish fix to get lossless compressed Full Resoution Silent Pictures DNG files working with the EOSM and 700D without breaking it on the 5D3. Put up test builds on my bitbucket download page and submitted a pull request.

Not the ideal solution, basically it just uses the newer version of save_lossless_dng for the 5D3 and the older version of that function for all other cameras. The "RAW error, falling back to YUV overlays" warning has returned to the EOSM and 700D but the current version of silent.mo doesn't save the DNGs and gives no warning on these cameras.

The movie projector scanner that @miket posted reminds me of a similar project from a user who was trying to adapt a EOSM for his film scanner to do full resolution (>4K) scans. It was challenging on that camera because after shooting a full resolution silent picture (FRSP) the LiveView would blank out and the EOSM does nearly everything through LiveView including triggering the shutter via an audio signal (Audio Remote Shot). The solution was to make a special build that put the camera into LiveView after every FRSP exposure. I preferred returning to LiveView rather than leaving LiveView paused but there's probably a good reason why a1ex paused LiveView so I also made it a menu option. It still needs some more work but maybe it is worth resurrecting?

A new menu item can change the way FRSP behaves, the default is to pause LiveView as it currently does:



or you can choose the option to return to LiveView after each exposure:



If you're in a mode other than Full-res, the menu item is greyed out and the tool tip shows that the option is only for full-res pictures.



I took another look at it and it is working in the crop_rec_4k branch. I believe where we left off was to hide instead of grey out the menu item, like the Slit-Scan Mode options and there is an annoying beep every time a shot is saved that is probably telling me that I'm doing something that I shouldn't be doing by forcing the camera into LiveView.

[miket]

If the camera frame rate is a few times higher than the projector frame rate, I don't expect any sync issues

@A1ex
After reworking the magnet glued to the projector gear and many changes to the reed switch orientation and timing, along to changing crop mode to 3k, it finally all works!  I ran 200 frame demos all weekend at the NYC World Maker Faire at the New York Hall of Science this weekend and I didn't have a single blurred frame.  That was running the projector at 10 FPS (about 600 shaft RPM), 3072 x 1728 with 14 bit lossless.

My cousin and I were presenting 2 projects as "DIY Vintage Film Restoration with a Pi or DSLR" which was a hit with both the attendees and the staff.  Joe and I are now sharing 3 editors choice blue ribbons.  Thanks for Magic Lantern! I will be writing up the details to post in the forum soon.

[g3gg0]

@miket:
if you get some problems with speed or reliability - as i wrote before - we can modify mlv_lite to use the card LED to genlock your projector to the MLV frame rate.

[Walter Schulz]

Congratulations for your achievements! Learned about projector Ampro Stylist (built around 1952?) using bakelite for some parts. Just out of curiosity: Are all those bakelite parts original or do you had to replace some parts using 3D-printing (or else)?

@g3gg0: Yes, it resembles steampunk but it is doing something and actually is producing something. A projector about 65 years old + Arduino + Magic Lantern. Worlds collide and making an impression!

[miket]

@g3gg0 and @Walter Schulz, thanks for the kind words!  I don't think I could easily genlock the projector with a signal from the camera due to the mechanics of it - for example startup and stopping needing motor acceleration and decel, the Arduino is running the AccelStepper library to handle this currently.  But the overall goal is simplicity as a first priority. 

Primarily I'm building this to digitize my family films, but the secondary goal is to make the build easy enough so that others will adapt the ideas to fit other projectors and massively digitize the worlds family and historical films.  The barrier to having film collection digitized/scanned is often the high price.  If a DIY machine based on Magic Lantern can be(relatively)easily made and have a high-quality output then I think more people will give it a try.

To that end, the recording this weekend were working at 10FPS which is more than normal projection half speed.  If it can get to 16 to 18FPS or so then the stepper motor would not be needed, eliminating some more of the complexity.  Testing higher speeds is on the to-do list.

I don't know the age of my projector, I picked it up used from craigslist but early 50's sounds right. The operation manual first edition date was 1949.  All of my bakelite is in great shape and most of the main bakelite and metal parts look identical to the older Ampro Imperial used in the pi project.  My Super Stylist has Sound on Film built in.  I never turned on the vacuum tube amp though, none of our films have sound. The machine looks cool and sounds great when it's running too. 

[DeafEyeJedi]

...Primarily I'm building this to digitize my family films, but the secondary goal is to make the build easy enough so that others will adapt the ideas to fit other projectors and massively digitize the worlds family and historical films.  The barrier to having film collection digitized/scanned is often the high price.  If a DIY machine based on Magic Lantern can be(relatively)easily made and have a high-quality output then I think more people will give it a try.

Oh I'm with you on this one @miket!

[ibrahim]

Which of the builds is the most stable to use on 5d3 firmware 1.1.3?
I am mostly interested in shooting at 24p in 16:9 and 2.20:1 with sound with the highest resolution possible, therefore mostly continuous.
Can I use MLV producer for converting these footages to cDNGs?

[pc_bel]

@Ibrahim
For me (and this is a personal opinion based on my own testing) is crop_rec_4k.2017Sep06.5D3113
I tested all versions, included the last one (Sep27).

I'm using it in producction, but it has a risk that I asume... Only using it in raw HD with proxy recording for the sound  (never 3k) and in 3x3_50p for slowmotion.