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.


Messages - a1ex

Pages: [1] 2 3 ... 349
1
Binning is simply blurring followed by downsampling (reducing the resolution by dropping pixels).

Example on how 5D3 does 3x3 binning to get 1080p Bayer raw from a full-res Bayer matrix:
Code: [Select]
function im = bin_pixels_3x3(im)

f = 1/9 * ...
[
    1 0 1 0 1;
    0 0 0 0 0;
    1 0 1 0 1;
    0 0 0 0 0;
    1 0 1 0 1;
];

imf = imfilter(im, f);
im = imf(1:3:end, 1:3:end);

First step is a 3x3 blur (averaging) on each Bayer channel, second step is keeping the central pixel from each 3x3 block (after filtering).

Also FYI, on Canon DSLRs, pixel binning is done by hardware (analog electronics), not firmware.

Reference: http://magiclantern.fm/forum/index.php?topic=16516.0

2
Not with current implementation, unfortunately.

You can lift the mirror and keep it lifted with a piece of tape; however, the mechanical shutter is actuated. This part happens on a different CPU that is not very well understood (the MPU). You can take pictures with shutter open (see FRSP), but has a gradient at short exposures. Additionally, file saving and image capturing must be pipelined to achieve 4 fps.

If resolution and rolling shutter are not an issue, you could look into half-shutter triggers for raw recording. However, its timing is given by the LiveView clock, not by the external trigger.

Delaying pictures in regular burst mode using an external signal might be easy to implement (didn't try, but I don't see why it wouldn't work). Not sure if half-shutter can be used as a sync signal though, as it must be pressed to keep the burst running.

3
Yeah, tried some more names, but since it's very similar to RAWI (adding some additional information about the raw buffer), that's what I've got.

4
General Help Q&A / Re: Focus peaking in Canon zoom mode
« on: Yesterday at 09:46:51 PM »
Yes, if you enable raw video (it enables all overlays in the 5x zoom mode, because it can actually record that).

However, you won't get good performance in this mode, because of the softer image. Try enabling DIGIC peaking and the options from LiveView zoom tweaks instead.

5
Camera-specific discussion / Re: Canon 600D / T3i
« on: Yesterday at 06:15:23 PM »
If you believe the same card behaves well on 5D3, but not on 600D, you'll have to do a controlled experiment.

Step 1: Find a way to reproduce. Even if it's something like this (just an example): record video clips until the card is full, download the clips on PC, format or delete, repeat 10 times, and at least one of those attempts is unsuccessful. The key is to find a sequence of actions that gives the error every time you try (even if that sequence requires recording many test videos or whatever).

Step 2: Run the test sequence on 5D3 (with SD only).

Step 3: If your test sequence does not include any ML-specific features (such as raw video), run it without ML as well.

Step 4: Trying on a different 600D, a different card reader, or a different USB cable or port may be helpful (to exclude hardware issues such as weak contacts in the SD slot).

The above steps should be helpful for any other issue hard to narrow down.

6
Camera-specific discussion / Re: Canon 1200D
« on: Yesterday at 04:48:32 PM »
Can you record a video of the installation process? The exact moment of crash should give additional clues.

7
Camera-specific discussion / Re: Canon 1200D
« on: Yesterday at 08:50:03 AM »
Was it a fresh install (no ML on the camera before), or you already had it installed with the older installer (the one with smiley face)?

If you format the card from the camera, is ML restored successfully?

(just trying to narrow down the step where it got stuck)

8
Camera-specific discussion / Re: Canon 1200D
« on: March 21, 2017, 09:57:00 PM »
This one (and most other interesting stuff) will work as soon as somebody enables changing Canon properties (discussed on this page).

Reminder: I'm still waiting for feedback on this build. For example, nobody reported whether the installer works or not (the previous report appears to be for an older version). Also, a menu walkthrough would be nice; I'm pretty sure that build contains more than the Overlay menu and API tests, already covered.

Please remember this is a blind port (none of the active developers has a 1200D), so we really don't know how it looks or behaves if you don't provide feedback.

9
Camera-specific discussion / Re: Canon 70D (Beta-4a / 26th Oct)
« on: March 21, 2017, 05:03:42 PM »
Then you may want to provide some screenshots with your bug report. If you take them in photo mode, make sure you include a raw histogram.

10
Camera-specific discussion / Re: Canon 70D (Beta-4a / 26th Oct)
« on: March 21, 2017, 04:43:30 PM »
Static scene + screenshots.

11
Camera-specific discussion / Re: Canon 70D (Beta-4a / 26th Oct)
« on: March 21, 2017, 04:29:50 PM »
That's correct. The easiest way to check for this bug is in movie mode, with some raw recording module enabled (but the same bug can affect raw overlays in photo mode LiveView as well; it's just harder to diagnose there).

This was (hopefully) fixed in all models recently (until then, some models worked, others not, and it wasn't exactly the kind of bug that gets reported often).

12
Camera-specific discussion / Re: Canon 70D (Beta-4a / 26th Oct)
« on: March 21, 2017, 04:09:26 PM »
@pmus2017: does the raw histogram change in movie mode between ISO 160, 200 and 250?

It should stay unchanged at these 3 values. If it changes, that's a bug (and its most obvious side effect would be missing clipping indicators at ISO 160 multiples).

13
A proposal for recording pixel binning / line skipping parameters and other related information:

http://www.magiclantern.fm/forum/index.php?topic=17021.msg181639#msg181639

14
Proposal for making crop info available to other modules (please review):
[...]

Done, please review. Experimental builds + updated mlv_dump available.

Relevant commits: structure, mlv.h entry, mlv_dump info display.

Metadata examples:
Code: [Select]
Block: RAWC
  Offset: 0x000000e8
    Size: 32
    Time: 0.769000 ms
    raw_capture_info:
      sensor res      5760x3840
      sensor crop     1.00
      sampling        5x3 (bin 5 lines, bin 3 columns)
Code: [Select]
      sampling        1x1 (read every line, read every column)
      sampling        1x3 (read every line, bin 3 columns)
      sampling        3x3 (bin 3 lines, bin 3 columns)
      sampling        5x3 (bin 5 lines, bin 3 columns)
      sampling        3x3 (read 1 line, skip 2, bin 3 columns)
      sampling        5x3 (read 1 line, skip 4, bin 3 columns)

Why I'm recording detailed info about binning/skipping modes? Maybe, at some point, somebody may come up with a custom debayering or super-resolution or whatever algorithm fine-tuned for Canon's pixel binning patterns. Knowing the exact binning pattern would definitely help in this case.

This info is recorded even if you don't use the crop_rec module (so it should probably be ported to regular nightlies as well).

15
Nope, but the list (from menu.h) is open. Or, you can use a MENU_WARN_NOT_WORKING.

16
Reverse Engineering / Re: ProcessTwoInTwoOutLosslessPath
« on: March 20, 2017, 05:44:26 PM »
After fiddling a bit with these routines, I have both good and bad news:

- good: 700D has routines very similar to 5D3 (named TwoInTwoOutJpegPath; not tested)
- good: 5D3 has two sets of routines for lossless compression (TwoInTwoOutLosslessPath and TwoInTwoOutJpegPath); both are working (second one requires some fiddling)
- bad: the routines are a bit different on 60D (not very LiveView-friendly)
- ugly: I wasn't able to decode the compressed images from 60D (just corrupted images), but didn't try too hard

- good: output bit depth (0xC0E00084) can be overriden from 14 to 15 bits
- info: a file with 15 bits is just 3 bytes (!) higher than a 14-bits one (headers show 15 bits and contents is totally different for same input image)
- bad: other bit depths (8, 10, 12) did not work at all
- bad: bit depth overriding did not work on 5D3 at all (maybe I'm missing something)

- good: the routines can accept raw image streams of arbitrary bit depths (10/12/14/16, configured with 0xC0F371FC)
- bad: the above doesn't appear to improve compression ratio at all
- ugly: compressing a zeroed out image gives a ratio of... 35.7%! (very large encoder overhead?)

What happens:
- output levels do not depend on input bit depth
- instead, 10-bit streams are padded with zero LSBs; the end result is the same as zeroing the lower bits.

From the 14/15-bit experiment, dividing the input data by some constant value (e.g. dividing by 16 for 14->10 bit conversion) probably has the same impact on file size as if we were able to reconfigure the encoder for a lower bit depth (which we can't). That's my current understanding, but I have no hard proof on that (as I don't even know how the encoder works).

Some numbers:


Note: the identical checksum confirms that compressing a 10-bit raw image gives the same result as converting a 14-bit image with 4 LSBs zeroed out (therefore, the unpacker module probably normalizes the values internally by adding LSBs).

Bottom line: pushing the lossless compression ratio below 50% (relative to 14-bit uncompressed raw size) is hard. Of course, it depends on noise levels and scene contents, unlike uncompressed raw, but the variations appear to be small.



(M)JPEG is, indeed, done with the same routines. The main difference is the type of data accepted as input (8-bit debayered, probably hardcoded to YUV422).

18
General Help Q&A / Re: Auto ETTR match camera settings?
« on: March 20, 2017, 09:53:06 AM »
Looks like ETTR picks a shutter speed rounded to 1/2 EV, but your selection in Canon menu is 1/3 EV. Canon firmware accepts both sets of values, regardless of their menu setting, but looks like it's taking it into account when writing the EXIF.

If you print camera.shutter.raw with a Lua script (see api_test.lua), that value should be a bit more useful for deflicker purposes.

The Tv value from ML menu can also be useful, but it's rounded to one decimal place.

19
Camera-specific discussion / Re: Canon 1200D
« on: March 20, 2017, 09:44:45 AM »
I'm talking about this installer, not the one from youtube...

20
All my dropbox links were replaced; if you find any broken link or image, please let me know (here).

Other links can be found by searching (with the forum search box, starting from forum home page) for:

Code: [Select]
34113196 - the number from your public links, unique to your user ID
dropboxusercontent.com/u/ - new-style links
dropbox.com/u/ - old-style links (can be both http and https)

If you have made forum contributions (in particular, but not limited to, images linked from a Dropbox public forum), and editing your own messages with updated links is not practical (for any reason), please send me an archive of those files you have linked here, keeping the directory structure, and I'll re-host them on the server.

21
General Help Q&A / Re: Auto ETTR match camera settings?
« on: March 19, 2017, 09:42:44 AM »
The internal representation of exposure values in Canon firmware is in 1/8 EV increments.

Some shutter speed measurements from movie mode: https://www.magiclantern.fm/forum/index.php?topic=16814.msg164062#msg164062

However, timings in photo mode are very likely to be different.

On most models, setting shutter speed in 1/8 EV increments from software should give either exact value or a difference of +/- 1/8 EV (api_test.lua checks for that). However, this is only what Canon firmware reports back.

How this translates to mechanical shutter timings is unknown. This table contains some sensor timings, but sensor exposure is a little longer than mechanical shutter opening.

If you have a light source that does not flicker and does not change in intensity, you can try to take pictures of a blank wall at various shutter settings, and record the median (not average) value (e.g. with deflick.mo) so we can cross-check the table referenced above.

BTW, ISO is likely to change (slightly) the sensor response (both gain and linearity). Changing aperture does not always give an ideal change in brightness (lens-dependent) and will also affect the vignetting (also lens-dependent and affected by focus distance). All these are going to affect an EXIF-based deflicker algorithm.

22
Modules Development / Re: Writing modules tutorial #1: Hello, World!
« on: March 17, 2017, 07:05:29 PM »
The above config declaration expands to (see config.h)

Code: [Select]
static int hello_count = 0;
[...]

That means, a variable local to the module (not exported to other modules), but usable in all functions from your module. It's not possible to declare config variables local to functions.

The parts are: name (as it appears in the config file), C variable name, default value.

Only config variables have to be registered with MODULE_CONFIG. Other special things also have to be registered with MODULE macros; will cover them in another tutorial.

As for why the were declared in this way - historical reasons. Pretty sure one can find a way to simplify the definitions (e.g. figure out the entry name from variable name, or register them automatically without requiring a MODULE_CONFIG), but so far there wasn't a pressing need to do so.

The "static" keyword from all other functions has the same meaning. If you don't write it, functions or top-level variables are exported to other modules (or to ML core, in some cases). That's nothing specific to ML; it's how the C language behaves when your program has more than one source file.

More about the static keyword in C here and here.

Note: ML build system shows the exported symbols, as (per C standard) you have to tag those functions/variables that you don't have to export (and do nothing for those that you do).

23
Camera-specific discussion / Re: Canon 1200D
« on: March 17, 2017, 11:10:19 AM »
That means, the installer didn't work?

24
Modules Development / Writing modules tutorial #1: Hello, World!
« on: March 16, 2017, 10:24:14 PM »
So far, if you wanted to write your own module, the best sources of documentation were (and probably still are) reading the source code, the forum, the old wiki, and experimenting. As a template for new modules, you probably took one of the existing modules and removed the extra code.

This is one tiny step to improve upon that: I'd like to write a series of guides on how to write your own modules and how to use various APIs provided by Magic Lantern (some of them tightly related to APIs reverse engineered from Canon firmware, such as properties or file I/O, others less so, such as ML menu).

Will start with the simplest possible module:

Hello, World!




Let's start from scratch:
Code: [Select]
hg clone -u unified https://bitbucket.org/hudson/magic-lantern
cd magic-lantern/modules/
mkdir hello
cd hello
touch hello.c

Now edit hello.c in your favorite text editor:
Code: [Select]
/* A very simple module
 * (example for module authors)
 */
#include <dryos.h>
#include <module.h>
#include <menu.h>
#include <config.h>
#include <console.h>

/* Config variables. They are used for persistent variables (usually settings).
 *
 * In modules, these variables also have to be declared as MODULE_CONFIG.
 */
static CONFIG_INT("hello.counter", hello_counter, 0);


/* This function runs as a new DryOS task, in parallel with everything else.
 *
 * Tasks started in this way have priority 0x1A (see run_in_separate_task in menu.c).
 * They can be interrupted by other tasks with higher priorities (lower values)
 * at any time, or by tasks with equal or lower priorities while this task is waiting
 * (msleep, take_semaphore, msg_queue_receive etc).
 *
 * Tasks with equal priorities will never interrupt each other outside the
 * "waiting" calls (cooperative multitasking).
 *
 * Additionally, for tasks started in this way, ML menu will be closed
 * and Canon's powersave will be disabled while this task is running.
 * Both are done for convenience.
 */
static void hello_task()
{
    /* Open the console. */
    /* Also wait for background tasks to settle after closing ML menu */
    msleep(2000);
    console_clear();
    console_show();

    /* Plain printf goes to console. */
    /* There's very limited stdio support available. */
    printf("Hello, World!\n");
    printf("You have run this demo %d times.\n", ++hello_counter);
    printf("Press the shutter halfway to exit.\n");

    /* note: half-shutter is one of the few keys that can be checked from a regular task */
    /* to hook other keys, you need to use a keypress hook - see hello2 */
    while (!get_halfshutter_pressed())
    {
        /* while waiting for something, we must be nice to other tasks as well and allow them to run */
        /* (this type of waiting is not very power-efficient nor time-accurate, but is simple and works well enough in many cases */
        msleep(100);
    }

    /* Finished. */
    console_hide();
}

static struct menu_entry hello_menu[] =
{
    {
        .name       = "Hello, World!",
        .select     = run_in_separate_task,
        .priv       = hello_task,
        .help       = "Prints 'Hello, World!' on the console.",
    },
};

/* This function is called when the module loads. */
/* All the module init functions are called sequentially,
 * in alphabetical order. */
static unsigned int hello_init()
{
    menu_add("Debug", hello_menu, COUNT(hello_menu));
    return 0;
}

/* Note: module unloading is not yet supported;
 * this function is provided for future use.
 */
static unsigned int hello_deinit()
{
    return 0;
}

/* All modules have some metadata, specifying init/deinit functions,
 * config variables, event hooks, property handlers etc.
 */
MODULE_INFO_START()
    MODULE_INIT(hello_init)
    MODULE_DEINIT(hello_deinit)
MODULE_INFO_END()

MODULE_CONFIGS_START()
    MODULE_CONFIG(hello_counter)
MODULE_CONFIGS_END()

We still need a Makefile; let's copy it from another module:
Code: [Select]
cp ../ettr/Makefile .
sed -i "s/ettr/hello/" Makefile

Let's compile it:
Code: [Select]
make

The build process created a file named README.rst. Update it and recompile.

Code: [Select]
make clean; make

Now you are ready to try your module in your camera. Just copy the .mo file to ML/MODULES on your card.

If your card is already configured for the build system, all you have to do is:
Code: [Select]
make install

Otherwise, try:
Code: [Select]
make install CF_CARD=/path/to/your/card

or, if you have such device:
Code: [Select]
make install WIFI_SD=y

That's it for today.



To decide what to cover in future episodes, I'm looking for feedback from anyone who tried (or wanted to) write a ML module, even if you were successful or not.

Some ideas:
- printing on the screen (bmp_printf, NotifyBox)
- keypress handlers
- more complex menus
- properties (Canon settings)
- file I/O
- status indicators (lvinfo)
- animations (e.g. games)
- capturing images
- GUI modes (menu, play, LiveView, various dialogs)
- semaphores, message queues
- DryOS internals (memory allocation, task creation etc)
- custom hooks in Canon code
- your ideas?

Of course, the advanced topics are not for second or third tutorial.

25
General Help Q&A / Re: error message?
« on: March 16, 2017, 06:46:40 PM »
Can you upload a picture that triggers this message?

(I smell a hot pixel in the optical black area, probably similar to this issue)

Pages: [1] 2 3 ... 349
courtesy