Canon 650D / T4i

Started by nanomad, August 03, 2013, 07:27:52 PM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

Walter Schulz

Tried taking FRSP with compression on:


Compression off:


dfort

Which build did you use?

crop_rec_4k.2017Oct16.650D104.zip - This is a build of what has already been merged into crop_rec_4k

crop_rec_4k_with_lossless_FRSP.2017Oct16.650D104.zip - This build has a hack that works on the EOSM/700D and should apply to the 650D.

Something that might be complicating the testing is that we also consolidated the offsets for EOSM, 100D, 650D and 700D. I don't think this was tested on the 650D. Just to make sure we're testing the latest changes use the new test builds on my Bitbucket downloads page. I removed the builds listed above because there have been some updates in the last couple of weeks.

It would help if you could list the Mercurial changeset from the info screen when posting test results.

A note on my FRSP hack. I never expected for it get merged the way it is. I'm getting hints on how to track down why FRSP is failing but I could really use some help with this. In the meantime, if the hack works we can at least see whether or not the lossless compression is working. On the 650D it looks like there's some issues going on with some of the lossless compression settings and we need to track these down.

Walter Schulz

Build used: a1ex_test.2017Oct18.650D104.zip
The one you and a1ex asked to be tested.
Where to go from here?

esas

Quote from: Walter Schulz on October 26, 2017, 08:46:54 PM
Build used: a1ex_test.2017Oct18.650D104.zip
The one you and a1ex asked to be tested.
Where to go from here?

Same here. FRSP not working corectly. Tried Simple, and that works -> saving both a DNG and a L-DNG.

$ dcraw -4 -E 17350000.DNG 17350001.DNG
$ md5sum 17350000.pgm 17350001.pgm
722b5f8d4c5a8b78f44c2c6dcc69444c  17350000.pgm
6dffb7230f910ee6d16287edda191134  17350001.pgm


https://1drv.ms/f/s!AhnvH_WJbJIold559uSjdgZbedKjlg


esas

Installed octave, but I really have a lot of reading to do before I'm able to troubleshoot further. Starting with the RAWguide A1ex posted..

dfort

Ok--so you're trying to run the tests a1ex asked for. Great! That build you're using should work on regular movie modes but not FRSP. I'm still trying to get confirmation whether or not the FRSP hack is working on the 650D.

The a1ex test build has this patch applied:

diff -r 8ee7858f0d7e modules/silent/silent.c
--- a/modules/silent/silent.c
+++ b/modules/silent/silent.c
@@ -560,3 +560,5 @@
             if (!ok) bmp_printf( FONT_MED, 0, 83, "DNG save error (card full?)");
-            return ok;
+            extern void reverse_bytes_order(char*, int);
+            reverse_bytes_order(raw_info->buffer, raw_info->frame_size);
+            /* fall through */
         }


So let's try it again. Assuming that the hack works for the 650D try the test build named crop_rec_4k_FRSP_hack_a1ex_test from my downloads page.

esas

Quote from: dfort on October 26, 2017, 11:01:31 PM
So let's try it again. Assuming that the hack works for the 650D try the test build named crop_rec_4k_FRSP_hack_a1ex_test from my downloads page.

Tried. I can now save FRSP again. Found  a difference that might mean something (?). The resolution are not the same (Full size):
$ dcraw -i -v 17350000.DNG 17350001.DNG

Filename: 17350000.DNG
Timestamp: Thu Jan  1 00:00:00 1970
Camera: Canon EOS 650D
DNG Version: 1.3.0.0
ISO speed: 400
Shutter: 1/1.5 sec
Aperture: f/2.9
Focal length: 24.0 mm
Embedded ICC profile: no
Number of raw images: 1
Thumb size:   128 x 84
Full size:   5280 x 3529
Image size:  5208 x 3477
Output size: 5208 x 3477
Raw colors: 3
Filter pattern: RGGBRGGBRGGBRGGB
Daylight multipliers: 2.266767 0.938615 1.281072
Camera multipliers: 2.111331 1.000000 1.602564 0.000000

Filename: 17350001.DNG
Timestamp: Thu Jan  1 00:00:00 1970
Camera: Canon EOS 650D
DNG Version: 1.3.0.0
ISO speed: 400
Shutter: 1/1.5 sec
Aperture: f/2.9
Focal length: 24.0 mm
Embedded ICC profile: no
Number of raw images: 1
Thumb size:   128 x 84
Full size:   5280 x 3477
Image size:  5208 x 3477
Output size: 5208 x 3477
Raw colors: 3
Filter pattern: RGGBRGGBRGGBRGGB
Daylight multipliers: 2.266767 0.938615 1.281072
Camera multipliers: 2.111331 1.000000 1.602564 0.000000


https://1drv.ms/f/s!AhnvH_WJbJIold58JjV61azIDvNl3g


dfort

Good test @esas -- you confirmed this:

Quote from: a1ex on October 18, 2017, 10:07:43 AM
Step 2: compare the raw data and check whether there are any differences (on 6D and 650D, there will be; on other models, hopefully not):

How's the octave installation working?

Are you able to compile? It would help if you are willing to play around with lossless.c:

Quote from: a1ex on October 18, 2017, 10:07:43 AM
Step 4: adjust the lossless decoder (either the one from dcraw, or lj92.c from mlv_dump) or the encoder configuration (lossless.c) until these differences disappear (how? I don't know, you need to experiment)

Step 5: repeat for 650D and all other models (I've ran this test on 5D3, got identical checksums at step 2)

In any case, the 650D seems to be in pretty good shape. Some of the video modes seem to be having problems but it is hard for me to see what is gong on.

@saulbass posted this shot in reply #1928:



esas

Quote from: dfort on October 27, 2017, 12:42:14 AM
How's the octave installation working?
It's installed and I've played around a bit. This is all new to me so everything takes a lot of time. It was octave that warned me about the different resolutions. It wouldn't let me do "imshow(a - b, [])" because of this.

Quote from: dfort on October 27, 2017, 12:42:14 AM
Are you able to compile? It would help if you are willing to play around with lossless.c:

I haven't tried it yet, but I plan to give it a try. Problem is playing around with lossless.c. I have no idea where to startt.

esas

Just a short update.

I'm able to compile now, and I've tried a few different builds on my camera successfully. I've been navigating around in the code, the wiki and the forum to get a grip on everything, but I find it hard.

To comment on my previous post I found that using "dcraw - 4- D" instead of "dcraw -4 -E" would give me images with the same resolution.

My FRSPs are a bit odd (download this DNG ). They seem to consist of two vertically split halfs (atleast the two halfs have differnt "faults" compared to the uncomressed DNG). I would expect them to be two horizontaly splits looking at this code from lossless.c:


    /* trick the encoder so it configures slice width = image width */
    /* we'll have two slices on top of each other; this will give
     * valid lossless DNG as well, if we prepend a header :)
     */
    TTL_Args.xRes = width;
    TTL_Args.yRes = height;
.
.
.
    /* need to read the image data in 2 slices
     * default configuration is 2 vertical slices;
     * however, using 2 horizontal slices makes it easy
     * to just slap a DNG header, resulting in valid output.
     *
     * => the input EDMAC will simply read the image as usual.
     */
    struct edmac_info RD1_info = {
        .xb     = width * 14/8,
        .yb     = height - 1,
        .off1b  = src_width * 14/8 - width * 14/8,


Could someone explain this part?

if (is_camera("5D3", "*"))
    {
        /* resolution is hardcoded in some places; patch them */
        EngDrvOut(0xC0F375B4, PACK32(width    - 1,  height/2  - 1));  /* 0xF6D0B8F */
        EngDrvOut(0xC0F13068, PACK32(width*2  - 1,  height/2  - 1));  /* 0xF6D171F */
        EngDrvOut(0xC0F12010,        width    - 1                 );  /* 0xB8F     */
        EngDrvOut(0xC0F12014, PACK32(width    - 1,  height/2  - 1));  /* 0xF6D0B8F */
        EngDrvOut(0xC0F1201C,        width/10 - 1                 );  /* 0x127     */
        EngDrvOut(0xC0F12020, PACK32(width/10 - 1,  height/20 - 1));  /* 0x18A0127 */
    }


What's going on here, and why don't we have to do this for any other cameras?


dfort

Quote from: esas on November 01, 2017, 01:32:36 PM
I'm able to compile now
...
What's going on here...

Don't worry, it gets even more confusing. Can't help you on the 5D3 code but maybe that is something that is needed on other cameras too.

Quote from: esas on November 01, 2017, 01:32:36 PM
My FRSPs are a bit odd (download this DNG ). They seem to consist of two vertically split halfs (atleast the two halfs have differnt "faults" compared to the uncomressed DNG). I would expect them to be two horizontaly splits...

Let's post the shot so we can see what you're talking about. I pushed the saturation, contrast, etc. so the "split" is easier to see.



Which build did you use? There's a test build for shooting a regular and a lossless DNG at the same time, is that what you used or is this the "normal" version that is in the crop_rec_4k branch? Obviously there shouldn't be any visible splits, horizontal or vertical.

(It would help if you could focus your test shots.)

esas

Quote from: dfort on November 02, 2017, 01:55:25 AM
Which build did you use? There's a test build for shooting a regular and a lossless DNG at the same time, is that what you used or is this the "normal" version that is in the crop_rec_4k branch? Obviously there shouldn't be any visible splits, horizontal or vertical.

I used the crop_rec_4k_FRSP_hack_a1ex_test from your download page.

dfort

Quote from: esas on November 02, 2017, 08:11:06 AM
I used the crop_rec_4k_FRSP_hack_a1ex_test from your download page.

That explains the problem. Use the crop_rec_4k_FRSP_hack build from my download page. The ones marked a1ex test are only for running a specific test.

BTW--I could use some help coming up with a better solution than my hack in order to get lossless compression working on FRSP with this camera.

dfort

Quote from: esas on November 01, 2017, 01:32:36 PM
Could someone explain this part?

if (is_camera("5D3", "*"))
    {
        /* resolution is hardcoded in some places; patch them */
        EngDrvOut(0xC0F375B4, PACK32(width    - 1,  height/2  - 1));  /* 0xF6D0B8F */
        EngDrvOut(0xC0F13068, PACK32(width*2  - 1,  height/2  - 1));  /* 0xF6D171F */
        EngDrvOut(0xC0F12010,        width    - 1                 );  /* 0xB8F     */
        EngDrvOut(0xC0F12014, PACK32(width    - 1,  height/2  - 1));  /* 0xF6D0B8F */
        EngDrvOut(0xC0F1201C,        width/10 - 1                 );  /* 0x127     */
        EngDrvOut(0xC0F12020, PACK32(width/10 - 1,  height/20 - 1));  /* 0x18A0127 */
    }


What's going on here, and why don't we have to do this for any other cameras?

I can't explain it but @Levas has been experimenting on the 6D.

The 6D screenshot he posted:


Looks a lot like the 650D screenshot @saulbass posted:


(Not the subject matter but the pattern of the stripes on the image.  :P )

So you might give this a try:

Quote from: Levas on November 08, 2017, 10:06:15 AM
...tried disabling lines in that piece of code, after many combinations, seems that 6d can do with only the first line, this will fix the striped pattern...

Dodas

Hallo,
may I ask why the TRAP FOCUS function is not introduced in 650d model? Are there any technical issues? Is it possible to expect it in near future?
Thanks


dfort

Don't want to double, or triple or...post so I'll just point to this post on the crop_rec on steroids topic:

https://www.magiclantern.fm/forum/index.php?topic=19300.msg196350#msg196350

We could use some 650D testers especially since the 650D is in the crop_rec_4k branch but we don't have experimental builds because of the issues a few posts back in this topic.

dfort

Got a response from a 650D user:

Quote from: saulbass on January 25, 2018, 01:24:18 PM
Hi,
Just tried your most recent build, https://bitbucket.org/daniel_fort/magic-lantern/downloads/ - crop_rec_4k.2018Jan24.650D104.zip on my 650D. transcoded using MLV.App.v0.13.alpha.OSX
without any of the RAW correction stuff switched on.
Amazing.



Quote from: saulbass on January 26, 2018, 12:03:27 AM
Yes I was using crop rec but I was kind of very rushed today so I need to carefully re-check my settings. FWIW I was amazed to get the results I got from the 650D especially as I wasn't using any of focus pixel repairs while transcoding.

Looks like it is working on the 650D though it would be good to get some reports on zoom mode and what the maximum image size possible is on this camera.

Also, the test build has lossless compression so maybe there are some changes in that? Better? Worse?

esas

I've been trying to build the dm-spy-experiments branch for the 650D but it fails. Any hints? Also I'm not really sure how to use it wen it finally builds. I've been searching the forum but haven't really found a thread explaining all its functions. (Also, any reason 70D is not included in this branch?)

a1ex


dfort

There's been lots of changes on the crop_rec_4k and crop_rec_4k_mlv_lite_snd branches.

The 650D is in these branches but there are no builds available on the Experiments downloads page because there are some issues with lossless compression that still need to be worked out. If you want a preview of coming attractions I put up a test build on my downloads page. Who knows, maybe we got lucky?

Walter Schulz

Thanks dfort for your builds!

- Issue with "Sticky HalfShutter" running experimental builds and dfort's.

Expected behaviour (from 7D):
Turn on menu item "Sticky HalfShutter".
Switch to LV and HalfShutter is not active.
Pressing Half Shutter gives a red rectangle with HS (in white) written inside. Write LED activated permanently.

Press Half Shutter again. Rectangle disappears and everything is fine.


650D with dfort's build "Nightly.2018Feb04.650D104" and experimental "build manual_lens_info.2018Feb02.650D:"
Turn on menu item "Sticky HalfShutter".
Switch to LV and HalfShutter is not active.
Pressing Half Shutter gives a red rectangle with HS (in white) written inside. Write LED activated permanently.

Press Half Shutter again: Rectangle will *not* disappear. Every other switch doesn't work. Excluding Mode dial to OFF. Switching to video doesn't change mode.

-> Turning cam off and on. Canon standard menu appears. Pressing Half Shutter: Rectangle appears again and LED is active. Blocked buttons again and I have to turn power off.


a1ex

Okay, so that must have been the reason for not enabling the sticky half-shutter back then. The behavior is puzzling - I hoped it's something that works in the same way on all models. Does it behave in the same way outside LiveView? [edit: yes] (that's where I'm able to diagnose it in QEMU).

If yes, just get a startup log and press the half-shutter a few times, with this feature enabled, outside LiveView. Even if the camera appears locked up, the operating system is not, so it will still be able to save the log.

Walter Schulz

Yes, works the very same way outside LV.
But Startup Log build does not have this feature therefore I'm unable to deliver a log with Sticky HalfShutter active.

a1ex

And there's another problem - 512K are not enough to log the complete startup. But since you are able to compile ML, it's easy to fix: compile from the dm-spy-experiments branch, use CONFIG_DEBUG_INTERCEPT=y in Makefile.user, and enable FEATURE_STICKY_HALFSHUTTER in features.h.

Then, select Debug -> DebugMsg Log to start logging, press half-shutter a few times, then select DebugMsg Log once again to save the log. That will cover only the actions performed between the two events, and should not run out of memory.

(I should find a way to allocate large buffers for these logs)