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 ... 347
Camera-specific discussion / Re: Canon 100D / SL1 (Beta-4b)
« on: Today at 08:56:39 AM »
If it fails for you, but works for others, one option for troubleshooting would be to install QEMU and run it directly from the SD card (so we can see why it doesn't boot). I can guide you for that - what operating system are you using?

The safest way (but requires some disk space) would be to create an image of your SD card (dd if=/dev/your-sd-card of=sd.img bs=1M) (on my system, it's /dev/mmcblk0) and run QEMU from the resulting sd.img. For a quick test, if you know what you are doing, replace "file=sd.img" with "file=/dev/your-sd-card", but be very careful not to give the emulated firmware access to your hard-disks! (risk of data loss).

Camera-specific discussion / Re: Canon 750D
« on: Yesterday at 10:16:21 PM »
Alright then - here's the FIR to enable the boot flag (on any firmware version):


This will modify your camera.

After enabling the boot flag in the camera, you may run:

- the portable display test (copy autoexec.bin and make your card bootable)
- the portable ROM dumper (you may have to format the card to a very small size, or dd this 256MB image - howto)
- anything compiled from the recovery branch (it runs from bootloader context); check Makefile.user.default for options
- the digic6-dumper branch (start by adapting the 80D boot code, and aim for launching a user task alongside Canon firmware)

Good luck!

Camera-specific discussion / Re: Canon 1000d / Rebel XS
« on: Yesterday at 09:44:31 PM »
The 1000D GUI can now be emulated in QEMU (same for the 450D ML):

What does this mean?

Porting ML on these VxWorks models just got easier by one (or maybe two) order(s) of magnitude - I hope it will be as easy as following the tutorial and/or the walkthrough. The development tools run on all major operating systems (including Windows and Mac).

Good luck!

Camera-specific discussion / Re: Porting ML to XSi (450D)
« on: Yesterday at 09:31:17 PM »
Managed to emulate the 450D GUI in QEMU, and also ran some tests on Ant's build:

Animation (click to zoom):

Emulation log

Canon menu screenshots (without ML loaded):

Besides the not-so-impressive feature set, I have a few questions:

- On the actual hardware, do the fonts look as bad as in the following screenshot?

- Do the colors in the menu customization mode really look as radioactive as these?

- Does the "ETTR ETTR ETTR ETTR" message show up on actual hardware as in the above screenshot?

Another surprise: if I compile ML from the vxworks branch (here), it doesn't boot correctly. When trying to compile from Ant's repository, changeset b05d7ea7f486 does not exist (did I misread the screenshot?) and his vxworks branch doesn't work either (emulation log - it gets stuck on initial screen). Compiling from latest changeset from Ant (c700f92) gives the same result (stuck on initial screen, with LED turned on).

Unfortunately, I did not have this commit when Ant posted his build - that would have embedded his local (uncommitted) changes in the executable file - so I'm unable to re-create his binaries from the current sources.

In any case, continuing the ML port on VxWorks models just got easier by an order of magnitude - or maybe two :)

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


- emulation is now used to run some automated tests on ML nightly builds (just scratching the surface, but already found a couple of bugs in ML)
- clean shutdown on most models (menu: Machine -> Power Down); 70D is the black sheep here (not sure what the issue is)
- 450D and 1000D GUIs (based on logs from Ant123). For other VxWorks models, you'll have to customize this and get a startup log with mpu_send/recv calls (can be debugged in QEMU).
- 400D GUI starts without any MPU emulation (!), but it's stuck (does not react to any key presses)

Still looking for some help with proof-reading the README, to merge it into mainline (EOSM2, 100D and 70D are waiting for it).

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)

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.

Camera-specific discussion / Re: Canon 1200D
« on: September 20, 2017, 07:55:58 PM »
Okay, that explains it - good to know. In other words, except for raw video, audio controls and some minor quirks, the port is in pretty good shape.

Are you able to compile ML?

@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

Camera-specific discussion / Re: Canon 1200D
« on: September 20, 2017, 02:11:36 PM »
The failed stub tests are related to autofocus outside LiveView. By pattern matching with other DIGIC 4 models, I'm unable to see what might be wrong with it.

However, you have reported Trap Focus working outside LiveView - these two features both depend on FOCUS_CONFIRMATION (from consts.h) to work correctly.

Best guess: AF was probably set on back button, and ML was unable to reconfigure it on half-shutter. But then, why did the test work in LiveView?!

Right, it's a good idea to update the message (maybe use a different one for experimental builds). However, before considering the builds as release, I'd like to:

1) fix the user guide problem;

2) make sure the builds are tested before posting; that was done manually years ago, when the feature set was small and I was working on 1 or 2 camera models; however, this approach no longer works (with hundreds of menu options - if not one thousand - and several modules, workflows, bleeding edge features and so on).

Made some progress for #2 - most of the nightly builds are now tested, to a limited extent, in QEMU.

General Development Discussion / Automated tests for nightly builds in QEMU
« on: September 19, 2017, 10:35:56 PM »
Another pipe dream came true :) - this time, a dream of mine.

Have you noticed a bunch of screenshots on the nightly builds page?

Were you wondering what's up with them?

These screenshots are created on the build server, by emulating the very builds available for download, unmodified, in QEMU.

In other words, most of the nightly builds are no longer 100% untested when they appear on the download page :)

This is not an overnight development - it's built upon all these years of fiddling with QEMU. A short while ago I couldn't give a good answer regarding the usefulness of the emulator - now you can see it live.

Right now there are only a few tests, with OCR-based menu navigation (using tesseract):

1) navigate to Debug -> Free Memory and take a screenshot from there
2) load the Lua module and run the Hello World script
3) load the file_man module and browse the filesystem
4) play the first 3 levels of the Sokoban game (lua_fix only; example for 1200D)

- add more tests (easy, but time-consuming)
- emulate more camera components (e.g. image playback to be able to test ML overlays)
- check code coverage
- diff the screenshots
- nicer reports

For now, have fun watching the testing script playing Sokoban in QEMU :)

Emulation log

If you are wondering what's the point of testing this game: it covers many backend items, such as menu navigation, module loading, script config files, making sure keys are not missed randomly during script execution, checking whether the camera has enough memory to run scripts - most of these are real bugs found on some camera models from the current nightly builds.

At least, these tests will catch the long-standing issue of some camera models running out of memory, thus not being able to boot. Not very funny for a build considered somewhat stable...

And the emulation is still pretty limited, so I'm just adding tests for what works :)

A while ago I've got the suggestion to use openQA, but I'm still wrapping my head around it. If you can show how it could save us from reinventing the wheel, I'm all ears.

To avoid visual differences from method changes, my suggestion would be to fix Dual ISO to 100/800 or 100/1600 during the entire timelapse (disable ETTR link to Dual ISO). It's probably a bit suboptimal for aliasing when the scene doesn't require dual ISO, and will have the shadows noisier than plain ISO 1600, but at least I'd expect the overall look to stay consistent.

(wish I had some examples to show - maybe later)

General Development Discussion / Re: Full-resolution silent pictures
« on: September 19, 2017, 10:01:16 PM »
I couldn't find details in this thread. Specifically, I need to know if there is a lag between the LED flash and the actual FRSP exposure.

You can turn on the LED whenever you need - even from a Lua script. However, turning it exactly in the middle of the exposure would require a background task (or polling) to check some low-level registers and figure out when the exposure started. Or, placing some hook in Canon's photo capture task. You may also have some luck with a fixed delay (trial and error).

The first post in this thread mentions that when FRSP is used with  intervalometer, the shortest possible time interval is ~10 seconds. Is it still the case, specifically for 6D?

You tell me.

The easiest way to reduce the file saving time is to port the lossless compression routines to 6D (easy coding task).

If you need even more speed and/or short exposure times without gradient, port the full-res LiveView (hint for 700D) and use mlv_lite (which is pipelined and optimized for fast writes).

Camera-specific discussion / Re: Canon 1200D
« on: September 19, 2017, 06:55:56 PM »
I had to comment out focusing test for following reason. Lens was Canon EF 85mm f/1.8.
Offending line is:
Code: [Select]

This worked in a previous test:

Code: [Select]
Testing lens focus functionality...
Autofocus outside LiveView...
Focus distance: 1400
Autofocus in LiveView...

Maybe the error message is a bit confusing - you should have pointed the camera to something to focus on :D

In both cases, it s the end of test, except the part where it states that is done (which should be included in the file if you ask me, like in LUA test).

Kept forgetting about this one... fixed now.

With adding any of the disabled modules, some errors appear.

You may have some modules from an older installation; these are not present in the zip from Jenkins...

Thanks for the tests. Posted a new build, mostly with updates on the Lua side - have fun watching the testing script playing Sokoban in QEMU :)

Camera-specific discussion / Re: Canon 7D Mark II
« on: September 19, 2017, 01:55:14 AM »
The BOOTU7D2.FIR was a dummy version; it did not actually enable the boot flag, but only printed what it's going to do. To enable it:


This will modify your camera.

After enabling the boot flag in the camera, you may run:

- the portable display test (copy autoexec.bin and make your card bootable)
- the portable ROM dumper (not working on 7D2, figure out why)
- anything compiled from the recovery branch (it runs from bootloader context); check Makefile.user.default for options
- the digic6-dumper branch (you will have to modify the code and experiment - it won't boot in its current state)

Have fun!

@JagoUK: I still need a copy of the 7D2 booloader (currently I have the blinked one from you, with errors); maybe you can try g3gg0's graphical dumper from the recovery branch?

Reverse Engineering / Re: MPU communication
« on: September 18, 2017, 10:33:45 PM »
06 05 01 00 MODE 00: change shooting mode (PROP_SHOOTING_MODE).

06 05 06 1c 01 00 / 06 05 06 1c 00 00: possibly Av press/unpress
- 500D: not forwarded to GuiMainTask, but followed by bindReceiveNewTFTOLC; see BGMT_AV in 1100D gui.h
- 100D: same MPU button code, but forwarded to GuiMainTask like all other buttons.

Camera-specific discussion / Re: Canon 1200D
« on: September 18, 2017, 06:14:01 PM »
BTW, camera.iso and camera.iso.value, what is the difference?

No difference; just two ways of setting the same thing (and the API test tries both methods).

To the overlays, can you please post how it should look?

If Canon overlays are enabled, ML should refuse to draw its overlays and should print a warning in menu. Will let you know how to diagnose it.

Looking at stubs test (selftest.c), Canon powersaving (auto power off) should be disabled temporarily by ML while running any of the tests from there. Lua doesn't have this trick (will fix). Do you mind repeating the stubs test, with auto power off enabled and set to 30 seconds?

Other places with powersave workarounds:
- ML installer (it waits for 60 seconds to disable the boot flag; if Auto power off is set to 30 seconds, ML should prevent the camera from turning off, even if you don't press any button during this interval).
- turning the focus ring on a lens that reports focus distance, in MF mode (issue 2431 - with Canon firmware, this action will not reset the powersave timer, but should do this with ML)
- file_man during very long file copy operations
- mlv_rec/mlv_lite/silent (not yet on 1200D)

BTW, some progress understanding how the Av button works:

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).

Camera-specific discussion / Re: Canon 1200D
« on: September 18, 2017, 04:30:21 PM »
The shutter, ISO and aperture tests are a little long; maybe you tried to start the test while another instance was already running? In any case, after "Setting ISO to random values..." there are a few more tests: "Setting aperture to random values..." and movie recording tests.

Minor: focus step sizes 1 and 2 appear to be identical; it may depend on the lens, and I expect to be the same in EOS utility.

I doubt Lua needs explicit flush on file I/O side, especially since the file is closed before the script ends. You can check by commenting out the tests in api_tests() and leaving just the log file creation and one printf, for example.

Your LiveView screenshot reveals another bug: ML overlays over Canon status bar. That shouldn't happen.

For a video session where I take several short MLVs, the 1st MLV is always coming out at 1920 x 1290  and subsequent MLVs are all 5784x3864

Take a look at the crop_rec indicator on the bottom left, on the info bar. If there's a warning sign right after enabling crop_rec, you may have to give it a few seconds to refresh the display. The video mode parameters can only be changed before entering LiveView; ML does that (exits and re-enters LiveView) shortly after you close ML menu. If you start recording right away, it will not be able to refresh the display and will record with the current settings (most likely 1080p).

Camera-specific discussion / Re: Canon 1200D
« on: September 18, 2017, 08:16:35 AM »
I have the screenshots, but they are not correct. As in what I see and what is in the file is not nearly identical.

With Zebras on, set overexposure at 99% and underexposure at 1%, it toggles between showing one ant the other. I am not sure if that is intentional.
The PPM has diagonal orange lines basically over the whole image except in spotmeter. I guess spotmeter, graphs, Q options etc are in the upper layers.

Zebras, in this configuration, are done in the display hardware (ML configures the threshold, the color to overwrite, the color to display, and whether to highlight values above or below that threshold). Screenshot code knows nothing about this, so it displays all the pixels that might turn into zebras, depending on the image contents.

Workaround: use software-based zebras (RGB or regular Luma) when taking a screenshot.

Did you stop the tests earlier, or the camera turned off by itself? (auto power off)

Camera-specific discussion / Re: Canon 7D Mark I
« on: September 18, 2017, 08:07:39 AM »
Currently it's only used in, and

You may try the tests from the, for example. For raw_twk, I'm not sure if it solves any bug; you could try before and after. On 700D, the stub tests (from could not run at all before the fix.

BTW, what's the reason for setting FPS override to a low value? Do you need long exposures?

If the camera frame rate is a few times higher than the projector frame rate, I don't expect any sync issues (there will be some jitter from the mismatched clocks, but as long as the projector is not advancing, it should be fine). Otherwise, if the two frame rates are close, but not identical, I expect trouble because the clocks will drift; the half-shutter trigger is not genlock (it does not affect LiveView frame timing - it simply saves whatever it finds in buffer).

A closer look at the footage shows the motion blur is, in many cases, at the top of the frame or on the entire frame, but never just at the bottom. The frame is captured from top to bottom, with rolling shutter - that suggests the defective frames were captured too early. The issue is clock drift, from what I can tell - try a higher frame rate setting for LiveView. The output frame rate will be driven by your external clock (so the data rate won't change), but the jitter will be a lot lower when LiveView is sampled at some high frame rate.

As a starting point, try running the projector at 1 FPS, LiveView at 30 FPS and give the sync signal in the middle of the interval where the film is not advancing. Once that is working fine, increase the speed and see how far you can push it, fine-tuning the settings and the timings. If you need more speed, try 1080p45 or 1920x800 60p.

For high speed scanning (with both projector and LiveView running at similar frame rates, doesn't matter if 1, 5, 10, 20, 30, 60 fps or whatever), you need genlock. Or mechanical shutter while the film is advancing.

Pages: [1] 2 3 ... 347