Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Thomas Worth

#51
Tragic Lantern / Re: 7D Raw Thread
October 13, 2013, 06:20:36 AM
I apologize if this is a known issue, but I thought I'd mention it anyway and provide some examples.

When shooting in RAW mode on the 7D at 50fps, the recording size is 1728x694. You are then instructed to stretch the image vertically in post by 1.4x to correct the aspect ratio to a proper 1.78:1 (16:9) frame, which gives 1728x972. This is the same resolution you'd get if you shot at 24/25fps.

However, stretching by 1.4x still does not give a correct aspect ratio, despite filling the frame up to 16:9. The picture is still squished vertically. In order to fix this, you must stretch by 1.56x. But, if you do this and then resize back to a height of 972, you cut off the left and right sides of the frame which results in a pillarboxed image.

I haven't tried this on the 5D3 as the camera is out on a job at the moment. Once it's back, I'll test it as well.

Here are examples that show the result of stretching the image by both 1.4x and 1.56x:

1.4x:


1.56x:
#52
Quote from: g3gg0 on September 22, 2013, 01:22:33 AM
now it supports resizing and different debayering algorithms.
Where did you get the debayer code? Did you write it yourself or are you using code from say, dcraw?
#53
Tragic Lantern / Re: 7D Raw Thread
September 20, 2013, 06:25:31 AM
1%, I enabled FPS override for the 7D by commenting out #undef FEATURE_FPS_OVERRIDE in /platform/7D.203/features.h. I now have the FPS override menu, but no matter what I set it to the data rate remains the same when shooting in crop mode. In other words, reducing the frame rate doesn't seem to reduce the amount of data being written. Is it simply being ignored? Is there something else that needs to be done?
#54
Tragic Lantern / Re: 7D Raw Thread
September 19, 2013, 12:03:25 PM
Quote from: a1ex on September 19, 2013, 07:46:26 AM
Maybe this threshold needs adjusted or computed dynamically?
I'm of the opinion that image processing should be avoided altogether if it isn't absolutely necessary. In the case of the 5D3, the code is needed and works well. So, my thought was to auto-enable the "VSC" code when the 5D3 or other cameras that need it are detected. For other cameras like the 7D, it is bypassed. This should also save a little CPU, although the cost seems negligible on a fast Mac.

I also think the user should be able to "opt out" if they want to (as was done here, which resulted in a cleaner image).
#55
Tragic Lantern / Re: 7D Raw Thread
September 19, 2013, 07:36:50 AM
Quote from: a1ex on September 19, 2013, 07:01:51 AM
Can you upload a small raw file that shows this?
Layer these two images on top of each other, then turn the top one on/off and you'll see the difference. This is zoomed in about 400%, I believe.

http://www.mediafire.com/convkey/5a9f/8bjux3fnl4il7g9fg.jpg (VS On)
http://www.mediafire.com/convkey/6478/usofobjks2hhh5nfg.jpg (VS Off)

This is repeatable with any RAW file as long as the image is pushed hard during color correction (as was the frame above).
#56
Excellent! Got it working. :D Thanks!

For others who encounter this problem: the solution is to change the entry points in /platform/7D.203/stubs.S to match the undefined references, e.g:

From:
NSTUB(0xff0162f0, malloc)

To:
NSTUB(0xff0162f0, _malloc)
#57
Up until a few days ago, I could compile ML for the 7D without a problem. I can't anymore, although compilation still works fine for 5D3 and other cameras (I didn't try all of them). Here's what I get when I try to compile "7D":

dietlibc.a(vsscanf.o): In function `vsscanf':
vsscanf.c:(.text+0x5c): warning: warning: the scanf functions add several kilobytes of bloat.
dietlibc.a(sprintf.o): In function `sprintf':
sprintf.c:(.text+0x14): warning: warning: Avoid *sprintf; use *snprintf. It is more secure.
mem.o:(.data+0x14): undefined reference to `_malloc'
mem.o:(.data+0x18): undefined reference to `_free'
mem.o:(.data+0x5c): undefined reference to `_AllocateMemory'
mem.o:(.data+0x60): undefined reference to `_FreeMemory'
mem.o:(.data+0x64): undefined reference to `_alloc_dma_memory'
mem.o:(.data+0x68): undefined reference to `_free_dma_memory'
collect2: error: ld returned 1 exit status
make[1]: *** [magiclantern] Error 1
make: *** [7D] Error 2


I get the error on both Mac and Linux with my GCC 4.8.1 toolchain. Again, this was working fine a few days ago. Here's what I get when I compile "5D3":

dietlibc.a(vsscanf.o): In function `vsscanf':
vsscanf.c:(.text+0x5c): warning: warning: the scanf functions add several kilobytes of bloat.
dietlibc.a(sprintf.o): In function `sprintf':
sprintf.c:(.text+0x14): warning: warning: Avoid *sprintf; use *snprintf. It is more secure.
[ OBJCOPY  ]   magiclantern.bin
[ STAT     ]   magiclantern.bin
magiclantern.bin: 437384 bytes
[ CC       ]   reboot.o
[ LD       ]   autoexec

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  EXIDX          0x06ad80 0x000d4180 0x000d4180 0x00008 0x00008 R   0x4
  LOAD           0x000100 0x00069500 0x00069500 0x6ac88 0x7e87c RWE 0x100
[ OBJCOPY  ]   autoexec.bin
[ STAT     ]   autoexec.bin
autoexec.bin: 438016 bytes
[ SYMBOLS  ]   magiclantern.sym
[ CP       ]   5D3_113.sym


It compiles okay. What gives?
#58
Tragic Lantern / Re: 7D Raw Thread
September 19, 2013, 02:23:22 AM
Quote from: arrinkiiii on September 19, 2013, 02:01:07 AM
Hi Thomas, the rawmagic it's only for mac?
At the moment, yes. I have a CLI version that runs on Windows, but no GUI yet.
#59
Tragic Lantern / Re: 7D Raw Thread
September 19, 2013, 01:09:30 AM
For users of RAWMagic and raw2dng: I did some tests with and without the vertical stripes correction code, and I get a cleaner result from 7D RAW footage when this correction is bypassed. I will add the ability to disable the correction in the next RAWMagic update (as of now it is always enabled).
#60
Tragic Lantern / Re: 7D Raw Thread
September 18, 2013, 09:08:16 AM
Hey guys, I finally got some time to continue testing ML on my 7D. Here are a few observations:

Recording at 1728x972 works continuously at both 24 and 25 fps with a 64GB KomputerBay 1000x CF card. This is good! However, if I have global draw enabled during recording, I get corrupted frames every now and then. Also, if I have software focus peaking enabled, I can't record continuously. It this because software peaking is sucking up too much CPU?

DIGIC peaking (hardware peaking?) works great, and allows me to record continuously at 972p while it's on. I'd like to use the edge detect peaking variant, but don't want it enabled all the time -- only for checking focus. I can half-press to get back my preview, but what I'd really like is to invert this behavior. In other words, half-press turns on DIGIC peaking.

I can record for a while (not continuous, unfortunately) at 50p at scope-ish aspect ratios. However, there is some bad aliasing with red/blue shifts. It's the same type of aliasing you notice with an unmodified Canon DSLR prior to the 5D Mark III. This doesn't seem to be an issue when recording up to 30p. Why only 50p and up?

Looking good so far. I almost feel comfortable using this on a shoot! I'd be interested in seeing how well RAW 5D3 and 7D cut together.
#61
FYI, I was finally able to get continuous recording working (I only tried 960x540) with a locked up LV. Certainly more moire than the 5D3. RAWMagic seemed to work okay.
#62
Here's raw_rec.mo with Pelican's changes:

http://www.mediafire.com/download/17wrac41a1oi4bu/raw_rec.mo
#63
I'll compile this and upload it later today. However, I should mention that I have not been able to get raw recording to work properly on the 7D. After starting a raw take, my preview locks up and I get a bunch of "corruption" messages as the buffer is flushing. I then have to reboot the camera to get the preview back. Has anyone had this problem? I suppose it could be the media, but I used this same CF card with a 5D3 and it worked perfectly. And that still doesn't explain the LV lockup.

If someone can upload a known working raw_rec.mo (or at least working better than mine) I'd like to try it.
#64
Quote from: John Kesl on August 10, 2013, 11:36:16 PM
I Used raw magic. The corruption is not so bad either. it's mostly on the bottom of the 2.35:1 frame.
I haven't tested RAWMagic with the 7D. I own a 7D, and if I can get things compiled and working I'll have a look.
#65
Quote from: Pelican on August 10, 2013, 06:00:47 PM
No, I put CONFIG_MEMCHECK=n
So the module loads, but you can't record? Can you get to the raw recording menu where you pick a resolution, etc?
#66
Also, I can actually get the raw options, but since I can't compile with CONFIG_MEMCHECK enabled, recording fails.
#67
Did you compile with CONFIG_MEMCHECK = y? Did you not get an error about conflicting types? You seem a little farther along than me, even though I can get the raw module to load.
#68
I was having a problem with this same error when compiling for the 7D. If I added edmac-memcpy.o to /src/Makefile.src it compiled without any problem. See here: http://www.magiclantern.fm/forum/index.php?topic=7561.0

The only problem I'm having now is when CONFIG_MEMCHECK = y is enabled in Makefile.user.default. If I enable this, compilation fails with a "conflicting types" error: http://www.magiclantern.fm/forum/index.php?topic=7593.0 If I comment out the prototype in memcheck.h, compilation completes but I just get a black screen on the camera. If don't enable CONFIG_MEMCHECK, everything works file but I can't get RAW recording to work.
#69
In memcheck.h:

extern void *memcheck_malloc( size_t len, const char *file, unsigned int line, int mode);
extern void *memcheck_free( void * buf, int mode);


in memcheck.c:

void memcheck_free( void * buf, int mode)

{

    unsigned int ptr = ((unsigned int)buf - MEM_SEC_ZONE);

    unsigned int failed = 0;

    unsigned int failed_pos = 0;


GCC doesn't like it:

../../src/memcheck.c: At top level:
../../src/memcheck.c:163:6: error: conflicting types for 'memcheck_free'
void memcheck_free( void * buf, int mode)
      ^

#70
Just an FYI, I tried compiling the latest source for the 7D (Mac OS X, GCC 4.8.1), but ran into the following error. Compiling 5D3 worked fine. Only when attempting "make 7D" did I run into this:


debug.o: In function `mem_test_edmac_copy_rectangle':
debug.c:(.text+0x304): undefined reference to `edmac_copy_rectangle_adv'
debug.o: In function `run_test':
debug.c:(.text+0xb28): undefined reference to `edmac_memcpy_res_lock'
debug.c:(.text+0xb6c): undefined reference to `edmac_copy_rectangle_adv'
debug.c:(.text+0xbbc): undefined reference to `edmac_copy_rectangle_adv'
debug.o: In function `mem_benchmark_task':
debug.c:(.text+0x3528): undefined reference to `edmac_memcpy'
collect2: error: ld returned 1 exit status
make[1]: *** [magiclantern] Error 1
make: *** [7D] Error 2


Adding edmac-memcpy.o to /src/Makefile.src in the following place (line 127) fixed it:

ML_SRC_OBJS = \
boot-hack.o \
ico.o \
edmac.o \
menu.o \
edmac-memcpy.o \
debug.o \
#71
I installed Alpha 2 on my 7D to see how far I could push the H.264 recording bitrate. However, ML refuses to shoot anything more than about 48-55mbps ("Q-16" in top right corner) at 1080p/24 no matter how high I jack up the CBR setting. It looks as though the camera tries to shoot at a high bitrate, but then "drops back" to the low bitrate after about 1 second. I don't get any warning or anything. The benchmark reports the card is capable of 56.8 MB/sec writes, which is of course well over 400 Mbit/sec. I even checked the files out of the camera and they are indeed no more than around 50 Mbit/sec.

Is this a limitation of the H.264 encoder in the 7D? Does it top out at ~50 Mbit/sec at 1080p/24?