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 ... 361
Camera-specific discussion / Re: Canon 600D / T3i
« on: Yesterday at 12:15:31 PM »
I believe the lua_fix build should pass all these tests, but didn't run them yet. These tests are just scratching the surface though - only 5-6 features out of a few hundreds.

This build has some major changes in the backend, and I hope they are in the good direction, but I've barely tested a tiny percentage of them (mostly on 5D3 and 60D). From the feedback received so far, I'm currently unable to judge the status of this build, sorry.

BTW - to see what these tests do, go to QEMU-nightly-tests and watch the gif files (todo: I should link them in the main page). For the failed tests, look at some other model to see how they should look like. Feel free to repeat these tests on actual hardware and report any differences.

Ok--so now that you pointed out that DEFAULT_RAW_BUFFER is returned as a pointer and CONFIG_ALLOCATE_RAW_LV_BUFFER is not, I can see there is a significant difference between the two.

They are both pointers; the only difference is who allocates them (Canon code or our code).

As I recall the whole issue why the Digic IV LVState cameras weren't working properly was because nobody was able to find the DEFAULT_RAW_BUFFER on these cameras.

No, the whole issue was (and still is) proper sync to avoid corrupted frames (in all video modes).

The sync issue has two components. An important one was frame size in 10/12-bit modes (which affected EDMAC behavior - it went out of sync), which was solved by RAW_SLURP. From current reports, this was not sufficient to solve all camera models x video modes. The remaining issue is probably that RAW_SLURP does not always start transferring the raw data at the right moment (like Canon's lv_save_raw hopefully does). We need to find when to call raw_lv_vsync: once for every LiveView frame - we are already doing that - but when exactly? This time we have to sync with Canon's image capture process. The newer models (60D and newer) already do that (evfReadOutDoneInterrupt).

The buffer does not affect sync at all (it's just a place in memory where the data is going to be stored) and the EDMAC channel must not conflict with anything else, but that's common sense. These were required by RAW_SLURP. BTW - changing that 0x1000 is not going to make things any better or worse, as long as the allocation succeeds.

It is also possible to solve the frame size issue without RAW_SLURP (and therefore without a custom buffer and without changing the EDMAC channel), with cache patches. That will keep the other shortcomings of lv_save_raw (side effects in x5/x10 on most old models) and the backend for cache patching is still quite fragile in my opinion, so I'd prefer to avoid this route.

The keys for solving the sync issue are in that big LVState diagram, the debug logs from LiveView (dm-spy-experiments branch; for models other than 500D you will have to find some stubs) or EDMAC activity logs/graphs (currently captured for 50D, but incomplete). I hope to be able (but cannot promise) to solve the sync issues after analyzing all these logs.

All the logs have to be captured in 3 LiveView modes (see #1450) in order to have something to compare. Repeat for all video modes (1080p, 720p, 5x, whatever else your camera has). Repeat for all camera models (not just 50D). The two logging tasks are also for camera models already present on the Experiments page (for double-checking and for having something to compare against).

General Help Q&A / Re: DUAL ISO cr2hdr. Why output a DNG and not a CR2?
« on: December 11, 2017, 11:07:47 PM »
Somebody actually looked into it and managed to write a CR2.

Don't remember the source code being published anywhere.

Pictures: plain LiveView (1) vs LiveView with raw enabled using new method (2, 3):

Notice how channel #2 writes some data into RAM, but not for every single frame. It's transferring every now and then, either 32x15 or 32x225 or 32x240 bytes.

What exactly it's doing? To find out:
- capture a log using dm-spy-experiments branch, make sure to include EDMAC setup functions (SetEDmac, StartEDmac etc) and see what debug messages are nearby
- dump the data from that memory address and attempt to make some sense out of it

Already having such a log done for 500D (linked earlier), channel #2 is configured with same transfer size, so I'm looking there:
Code: [Select]
1E2F2> LiveViewMg:ff0da8e4:98:02: SetWbIntegRegisterForAe 0
1E31F> LiveViewMg:ff1fabf0:99:02: StartWbPass
1F3D5> LiveViewMg:000927a0:00:00: *** ConnectWriteEDmac(0x2, 0x2), from ff1fac44
1F46A> LiveViewMg:000927a0:00:00: *** RegisterEDmacCompleteCBR(0x2, 0xff1fa56c, 0x43ffa1e4), from ff1fac54
1F4D0> LiveViewMg:000927a0:00:00: *** SetEDmac(0x2, 0x43ff83e0, 0x15a200, 0x20000000), from ff1fac68
1F76E> LiveViewMg:000927a0:00:00: *** StartEDmac(0x2, 0x0), from ff1fac74

White balance.

That's why channel #2 is not safe to reuse on 50D, 5D2, 550D, 500D and 7D (links pointing to EDMAC screenshots).

Not sure what you need from this but I ran the EDMAC test until it finished and also enabled logging. Uploaded the log files here.

Looks fine.

Try logging at 50us (or 100us or more if it freezes the image or has other problems) a few scenarios in LiveView:
- without raw video and without photo raw overlays enabled (e.g. global draw off, no other modules loaded)
- with raw video enabled, old method (run it on top of regular nightly or raw_video_10bit_12bit)
- with raw video enabled, new method (on top of dfort's modified version)

Also, for my own curiosity: log a still photo, short exposure, outside LiveView, with 500us (or 1 ms if that doesn't cover the entire process). Look at the blue LED to see when it logs and when it stops.

Take a look at the EDMAC connections screen as well (Show EDMAC channels, scroll to the right).

Solved lock-ups in and polished it a bit - changes on the "edmac" branch. Merges cleanly into raw_video_10bit_12bit, if you prefer to try it there.

PR open.

Oops--but isn't that essentially what is going on in the allocate-raw-lv-buffer branch?

Nope -

RAW_LV_BUFFER_ALLOC_SIZE gets passed to fio_malloc; this returns a pointer to the allocated buffer, which is then stored in raw_allocated_lv_buffer (and used to save the LiveView frame there). The same happens in crop_rec_4k, with some additional bounds checking (which is only valid on 5D3 - the other models use dummy values just to compile).

DEFAULT_RAW_BUFFER is used as a pointer to some valid raw buffer (allocated by Canon code). On recent models (60D and newer), it is allocated when entering LiveView (evfActive), but that pointer is no longer valid when leaving LiveView (it's still there, but stale); on older models I believe it's allocated on request (by whatever code gets triggered by lv_save_raw) edit: it's also allocated when entering LiveView! edit2: false alarm, I forgot photo raw overlays enabled during the test!

5D3 1.2.3 (it appears to allocate 0x1cae000 bytes; MEM1 is the raw buffer we are looking for):
Code: [Select]
79152>        Evf:ff16b0dc:a9:03: [2] Flicker Address[0x4d318000][0x52518000]
791E9>        Evf:000aef04:00:00: *** lv_raw_buf(0x0, 0x0, 0x94897c, 0xc, 0x4d318000, 0x52518000, 0x1cae000), from ff1650d4
79200>        Evf:ff16b334:a9:03: Mem1 Address[0x4d31a000][0]

500D (full log):
Code: [Select]
1B512> LiveViewAn:ff1f6224:9a:07: [00000000:043A8818] lvaStart
1B944> LiveViewMg:00092b38:00:00: [00000000:043A8818] *** LVState: (1) --20--> (1)          ff0e5424 (x=869970 z=4099b360 t=1)
1B9B4> LiveViewMg:ff0e5470:98:03: [00000000:043A8818] HPCopyAsync pvParam:0x4099b360 -copy-> Lucky:0x43fd4420
1BA24> LiveViewMg:ff0de974:9b:03: [00000000:043A8818] GetResource 0x1000 (0xF07/0x1F07)
1BB16> LiveViewMg:ff1f8e28:99:02: [00869A28:00000000] SetFlickerPassParameter
(after a while; LiveView working normally without raw for a few seconds)
42F97>   run_test:00059408:00:00: [00869A28:00000000] *** call lv_save_raw ***
43011>   run_test:00093268:00:00: [00869A28:00000000] *** TryPostEvent(LiveViewMgr, 0x9, 0x1, 0x200), from ff032728
430BD> LiveViewMg:00092b38:00:00: [00869A28:00000000] *** LVState: (2) --9--> (2)          ff0e56ec (x=869970 z=1 t=200)
43126> LiveViewMg:ff0e5738:98:16: [00869A28:00000000] Set Debug Flag 0x000006A1(0x08200)
7FB00> LiveViewMg:ff1fb03c:99:02: [00869A28:00000000] StopQuarkPass
7FB5F> LiveViewMg:ff1f5a94:98:02: [00869A28:463390A4] GetEngineResource SUCCESS Res:4, Free:fffffffc

The numbers in brackets are (added this to my_DebugMsg to print the possible raw buffer address on every debug message):
Code: [Select]
    len += snprintf(buf+len, buf_size-len, "[%08X:%08X] ", MEM(0x15CB0), MEM(MEM(0x15CB0) + 0x328));

Addresses coming from:
Code: [Select]
DebugMsg(153, 4, "StartPass_x1 CrawAddr : %lx / KindOfCraw : %d", *(v15CB0 + 0x328), *(v15CB0 + 0x32C));
BC24B> LiveViewMg:ff1f7190:99:04: [00869A7C:463390A4] StartPass_x1 CrawAddr : 463390a4 / KindOfCraw : 0

so DEFAULT_RAW_BUFFER on 500D would be MEM(MEM(0x15CB0) + 0x328) = MEM(MEM(0x15CA4 + 0xC) + 0x328).
7D: MEM(MEM(0x17BBC+0xC) + 0x338), not tested.
(addresses are good, but they are only valid with lv_save_raw)

BTW - that "Debug Flag" from the 500D log is actually the LiveView RAW mode in Canon firmware (a feature they have used for debugging). That should explain why the x5/x10 modes in very old models are broken (pink previews, unusable x10 etc), or why the LV raw buffer on 1100D is reused for something else (as this camera has very little RAM).

Back to your question.

Pointers are memory locations; they are not interchangeable with buffer sizes (even if the C compiler may accept this). The reason it might happened to work (sort of) is the large value of SRM_BUFFER_SIZE - it points somewhere way above the DryOS core, so if it screws up things, it might do so in some non-obvious way (remember those obvious bugs from 5D3.134).

With shamem_read(0xC0F26008), this reads the address previously configured on EDMAC channel 0x10, by some existing code. Without CONFIG_EDMAC_RAW_SLURP, that's Canon code enabled by lv_save_raw; they have configured that channel with whatever buffer they have allocated for the LV raw image. The point of the new method is to bypass Canon code so we can have full control over it (such as, specify a different "raw type" or - in our case - a lower EDMAC transfer size for 10/12-bit), but since we are not going to call lv_save_raw, there will be no Canon code to allocate a raw buffer for us. So that won't work - you'll get some old value and the results are unpredictable.

Why do you want to change it? The only valid reason I can see would be to avoid the BUSY screen - in this case, just allocate as much as you need. Find the largest frame size you want to use (usually that's the raw resolution in 5x zoom) and allocate a buffer large enough for that (but not much larger). In this case, the memory backend will see no reason to use SRM buffers (which may print the BUSY message while they are allocated).

BTW, what's that -e doing there? That may indicate yet another bug in the Makefiles (a similar one was on Mac when generating module READMEs). This didn't help locating it:
Code: [Select]
grep -nr -- " -e" Mak* */Mak* */*/Mak*

P.S. 60D EvfState (compare to 7D's LVState):

Code: [Select]

Do not do this. Camera bricking risk is real.

Allocate it, use a pre-allocated one, or find some unused*) memory block. Don't try random pointers hoping they will work.

*) If you decide to use this one, double-check it's really unused (test it in any camera mode you may think of - photo, movie, zoom, various FPS, while recording, external monitors, and make sure it's not going to be reused by other Canon code while you are updating it). Tools you may use: CONFIG_MARK_UNUSED_MEMORY_AT_STARTUP, CONFIG_RSCMGR_UNUSED_SPACE_TEST, or write your own RAM analysis tools.

Modules Development / Re:
« on: December 10, 2017, 04:48:40 PM »
1) grep for autofocus in the lua_fix branch, selftest.c and lua_lens.c (not sure if it works well on 500D)
2) lens_info.focus_distance (on lenses that report it; usually very coarse)
    on focus-by-wire lenses, lens_info.focus_pos is also updated in MF (lua_fix branch)
3) try Trap Focus or silent pics in "Best Shots" mode; they use a focus indicator from Canon code
    Magic Zoom's focus confirmation uses the same indicator
    caveat: on models older than 60D, this indicator is not computed for every LV frame
    and unfortunately it won't work at all on 500D: - CONFIG_LV_FOCUS_INFO

Difficulty for a fully automatic AF in video mode, compared to fully automatic AE, on a camera without phase sensors (aka focus pixels or pink dots):

(not joking)

There was a feature called Movie AF in very old versions, that also did something similar to your follow focus idea, but I've discontinued it because it was too unreliable and hard to maintain. You may dig through archives and bring it back if you find it useful.

1 is likely safe on 50D, but not on 5D2.

5 is likely used only when entering LiveView or when changing video mode, so it might be OK to reuse. The yellow ones may also be worth trying. No idea why some channels, with apparently identical configurations, give different results.

For color coding, the advice from dfort dmilligan also applies.

Scripting Q&A / Re: Menu hidden query
« on: December 10, 2017, 03:20:04 PM »
Fixed and found a few other fields with the same defect.

The "seems to work" only looks at whether the tested channel is locked by some other code (usually Canon code) or not. One may assume Canon code would always lock the channels they use, and unlock them when they no longer need them, but take it with a grain of salt.

The green color on channel 2 (which you have reused for raw capture) means that channel is transferring data. I don't think it's a good idea to use it, even if it appears to work at first sight. To see the activity in nearly real-time, press and hold the up or down key in the EDMAC screen (which won't change the current selection, but will cause the menu to redraw faster). Whenever there's green on any of the channels, even for a very short time, that means "stay away from it".


I don't know much about coding or reverse engineering or playing the violin but one valuable lesson I learned from dmilligan is to look at the code.

This says channel 1 seems free (does it also come up as free if you scan for free channels?), but channel 2 is used (and a transfer was active in the moment you took the screenshot). Channel 0 is used to write the HD buffer (the input data to H.264, but it's also updated in standby) and channel 18 = 0x12 writes the LV buffer (the preview image - 720x480 on 3:2 screens, about 720 x 480*(4/3)/(3/2) = 720x426 on 4:3 screens, 2 bytes per pixel - UYVY aka YUV422 in Canon strings). This matches the definitions from consts.h - just giving some examples on how to interpret these numbers.

Channel 13 is reading from the HD buffer (maybe for resizing it or whatever it does), but its geometry is likely more complex, so the overview screen only prints its size. You may scroll to detailed view to get the full configuration. We don't need it for this experiment - I'm just showing how you can use it to explore things.

The camera freeze has to be debugged (not sure where to start). Does it work outside LiveView, if you use it to log a still image capture? Does it help if you increase LOG_INTERVAL?

Then, there are a bunch of logging tools in the dm-spy-experiments branch (such as logging EDMAC transfers, or state object transitions). Sample snippet from 500D, which I'm studying for QEMU emulation (found its debug messages a bit more verbose than usual).
Code: [Select]
dm-0007.log-15329-782D1> **INT-F9h*:000928bc:00:00: *** TryPostEvent(LiveViewMgr, 0x3, 0x0, 0x0), from ff0da628
dm-0007.log-15330-78327> **INT-F9h*:00000558:99:02: WriteEDmacFlickerCompleteCBR
dm-0007.log-15331-7834E> **INT-F9h*:0000057c:00:00: <<< INT-F9h done
dm-0007.log:15332:7838F> LiveViewMg:000920c0:00:00: *** LVState: (3) --3--> (4)          ff0e1288 (x=b18710 z=0 t=0)
dm-0007.log-15333-783E7> LiveViewMg:ff0e12b0:98:02: SetPsave 0xFFFFF0 RecRes:2 LvRes:2
dm-0007.log-15334-7844A> **INT-5Eh*:00092118:00:00: >>> INT-5Eh EDMAC#9 ff18f7d8(9)
dm-0007.log-15335-78488> **INT-5Eh*:00092198:00:00:     addr 734fd4, ptr 736474, size , flags 0
dm-0007.log-15336-784CB> **INT-5Eh*:0000057c:00:00: <<< INT-5Eh done
dm-0007.log-15337-784EF> **INT-5Dh*:00092118:00:00: >>> INT-5Dh EDMAC#8 ff18f7d8(8)

In these logs, messages tagged with *** are from our logging handlers (such as the LVState transition - state_transition_log), the >>> and <<< are showing interrupts, while plain messages (not tagged with anything) come from Canon code. The dm-spy-experiments code is pretty much a swiss army knife and requires fiddling - you may place logging hooks basically anywhere in Canon code (whenever you think they may provide useful info). Start by using predefined logging functions, then feel free to invent new ones. Caveat: some of them may conflict, depending on their ROM address, so you can't just enable them all at the same time. Refer to the dm-spy-experiments topic for details.

Example of messages I could only find on 500D (full log, without raw):
Code: [Select]
dm-0010.log:4326:E6762>    Startup:ff170334:9b:01: TG-InitializeLvTgDriver
dm-0010.log:4327:E6816>    Startup:ff17039c:9b:01: dwInitComm[0]=0x12800001
dm-0010.log:4328:E6863>    Startup:ff1703c8:9b:01: wInit[0]=0x00000000
dm-0010.log:4329:E6896>    Startup:ff1703f4:9b:01: dwInit[0]=0x00074046
dm-0010.log:4330:E68E7>    Startup:ff170424:9b:01: pAdjustAnalgVoltage[0][0]=0x00140000
dm-0010.log:18305:222F2> LiveViewMg:ff170580:9b:01: TG-PowerOnLiveViewDevice
dm-0010.log:18306:2231A> LiveViewMg:ff17059c:9b:01: PowerOnE3LAT
dm-0010.log:18360:2377F> LiveViewMg:ff1705d4:9b:01: PowerOnE31LAT
dm-0010.log:18395:25F5B> LiveViewMg:ff170624:9b:01: CancelADTG_RESET
dm-0010.log:18396:25F85> LiveViewMg:ff170644:9b:01: EnableSerialPort
dm-0010.log:20113:4419C> LiveViewMg:ff170680:9b:01: TG-ReadyLiveViewDevice
dm-0010.log:20114:441BF> LiveViewMg:ff1706a4:9b:01: 2-1.AFE_InitSetting 74046 2804c
dm-0010.log:20169:44ABA> LiveViewMg:ff1706d4:9b:01: 1-1.TG_InitSetting 12800001 11a42c01
dm-0010.log:20459:48A39> LiveViewMg:ff170764:9b:01: PowerOnE32LAT
dm-0010.log:20460:48A63> LiveViewMg:ff17077c:9b:01: 2-2.BaseVoltage_Setting
dm-0010.log:20471:48C33> LiveViewMg:ff1707a0:9b:01: 3-1.CMOS_InitSetting
dm-0010.log:20494:48F9D> LiveViewMg:ff1707bc:9b:01: 1-2.2Acc1SettingForLV
dm-0010.log:21327:5B493> LiveViewMg:ff170d8c:9b:01: TG-StartupLiveViewDevice 4
dm-0010.log:21328:5B4B8> LiveViewMg:ff170d30:9b:01: 1-4/1-12.ReadOut_Setting
dm-0010.log:21336:5B615> LiveViewMg:ff170dbc:9b:01: 1-6.Condition_Setting
dm-0010.log:21341:5B6DD> LiveViewMg:ff1709f4:9b:01: 2-7.AFE Timing3[0] 92b0b bab0b
dm-0010.log:21349:5B82C> LiveViewMg:ff170ab4:9b:01: 2-3.AFE_GainSetting
dm-0010.log:21360:5B9E8> LiveViewMg:ff170dec:9b:01: 2-4.Cal_Start
dm-0010.log:21365:5BAA6> LiveViewMg:ff170e10:9b:01: 1-8.Release_PSAVE
dm-0010.log:21370:5BB6D> LiveViewMg:ff170e38:9b:01: 1-10.AnimComm_Setting [4]
dm-0010.log:21751:5FB72> LiveViewMg:ff170be0:9b:01: 3-4.CMOS SR_Setting [0=0x0]
dm-0010.log:22124:B1B3F> LiveViewMg:ff1713b0:9b:01: 1-13.SR_2ndFrame_Setting
dm-0010.log:22270:B9C14> LiveViewMg:ff171090:9b:01: TG-SetPsave[2-6]Off 4 553648112
dm-0010.log:22390:BCA3D> LiveViewMg:ff171108:9b:01: TG-ResetPsave[2-6]On 4 553648112
dm-0010.log:22391:BCA6B> LiveViewMg:ff171728:9b:01: 2-6.AFE Standby
dm-0010.log:22396:BCB2D> LiveViewMg:ff170be0:9b:01: 3-4.CMOS SR_Setting [0=0x0]

what happened to ??

Good catch - they renamed it to Found this guide and renaming the old repository was enough to do the trick.


Also updated old forum links.

Reverse Engineering / Re: EekoAddRawPath
« on: December 09, 2017, 10:25:42 PM »
I have a feeling Omar (secondary DryOS core from DIGIC 6) might be the equivalent of Eeko on D5.


- they are initialized in a similar way, from the main core, on request - unlike 7D, where both cores start at power on and they wait for each other
- communication is done using "postman" routines (same name used for Eeko)
- startupPrepareCapture is waiting for it at startup, so it must have some important role in image capture and/or processing
- interrupts used 0xd, 0x2d, 0x4d, 0x6d, 0x1c, 0x3c, 0x5c, 0x7c, 0xcd, 0x9c, 0xbc, 0xdc, 0xfc (exact meaning unknown, but they follow a similar pattern).

Code: [Select]
[ROM-DMA0] at OmarI:FE1DA5EC:FE1DA6E9 [0xD6030000] -> 0x10000000: ???
[ROM-DMA1] at OmarI:FE1DA288:FE1DA273 [0xD6030040] <- 0x46FF    : count
[ROM-DMA1] at OmarI:FE1DA292:FE1DA273 [0xD6030044] <- 0xFE88871C: srcAddr
[ROM-DMA1] at OmarI:FE1DA29C:FE1DA273 [0xD6030048] <- 0xDFF00000: dstAddr
[ROM-DMA1] at OmarI:FE1DA2A6:FE1DA273 [0xD603004C] <- 0x30F00   : ???
[ROM-DMA1] at OmarI:FE1DA2B0:FE1DA273 [0xD6030050] <- 0x30F00   : ???
[ROM-DMA1] at OmarI:FE1DA2BA:FE1DA273 [0xD6030054] <- 0x2E8301  : ???
[ROM-DMA1] at OmarI:FE1DA2CC:FE1DA2C5 [0xD6030058] <- 0x11100003: Start DMA

More stuff coming soon.

What can I do to push it to break?

Different frame rates and different overlay configurations in ML (zebras, magic zoom etc). These are likely to affect the LiveView sync.

Some models and/or video modes might be luckier than others, or they might have a higher tolerance for timing errors. The 50D might be lucky because of the lower resolution.

I might be able to give a better answer after some hours of analyzing LiveView logs (to cross-check what happens on 60D and newer vs 550D and older models), but not right now. Want to check the timing relationships between the EDMAC transfers from connection #0, and the ReadOutDone event or HEAD interrupts, or whatever else might signal a completed image capture. The tools for doing that are and dm-spy-experiments. Some real-time plotting code that can be reused is in mlv_lite on crop_rec_4k (EDMAC plots).

From what I remember, the problem with 5D2 was similar to what it was reported (lack of good sync in LiveView), so I believe edmac_raw_slurp must be called from another place (somehow in sync with the LiveView capture process - probably the ReadOutDone event). I've started to look into that here, but didn't get too far. Still, the edmac module is compatible with DIGIC 4, so you are encouraged to try it and log the LiveView activity in various modes.

The last graph from that page is in the "edmac" branch, but not very interesting for the current issue; everything else is in mainline (edmac module). Didn't upload the drawing script yet, but you can upload some logs and I'll draw the graphs for you. If it won't require too much fiddling, I'll upload the script as well.

The 50D doesn't seem to be 100% clean either (the two video modes are likely identical in standby, so I assume the "rock solid" report was just pure luck). Just FYI - its firmware and video mode implementation is very close to 5D2 1.0.x (the older firmware without manual video controls).

My older attempt for 5D2 was pretty much the same as in the current PR, just less polished. Back then, I've used dmaFlags = 0x20000000, raw_write_chan = 5, PREFERRED_RAW_TYPE 5 and redirected_raw_buffer = malloc(2050*14/8*2000).

Camera-specific discussion / Re: Canon 500D / T1i
« on: December 08, 2017, 11:49:50 PM »
To get this value, I didn't even have to take a picture - just went to the Free Memory dialog, which does a test allocation.

Taking an emulated full-res capture with the vanilla silent module is doable, but requires a gdb script (or a custom build) to fake the LiveView status. One such test is ran on the nightly builds (see this screenshot and this animation, or this and this for 500D, although not all models can run it that well) and another one (with a minimal codebase) is ran with the QEMU test suite (qemu-frsp).

In the crop_rec_4k branch there is a printf commented out.

Scripting Q&A / Re: Script state at camera switch off
« on: December 08, 2017, 03:16:03 PM »
Well, that's a sign the documentation needs some improvement in this area.

Camera-specific discussion / Re: Canon 500D / T1i
« on: December 08, 2017, 08:15:10 AM »
Ran it in QEMU - it flashes too fast (you have replaced the printf with a bmp_printf, right?), but it's 1AE followed by some zeros. That should give around 27 MB, so it's 0x1ae0000.

NotifyBox will redraw the message in background, should it get erased, while bmp_printf just prints it once.

Scripting Q&A / Re: Script state at camera switch off
« on: December 07, 2017, 08:12:23 PM » (config.create_from_menu - if I understand it well, it should "just work" for complex scripts with simple menus) (sokoban - example for simple scripts) (example for menu with custom state)

BTW, event.config_save should be called whenever ML saves its own settings (that is, after closing ML menu - if you have clicked something - or at shutdown).

Would be nice to have arbitrary variables tagged as persistent somehow, so they will save their state at shutdown and auto-restore at startup. In modules and ML core, we declare them as CONFIG_INT and the backend does the rest.

So there is a missing section in the  README telling you to also compile the sf_dump Module and putting it on the ML Card and activate it and then Reboot the camera and use the module from the Debug Menu of ML. (only found it through full text search on the whole ML directory)

Solved. The serial flash dumper should also be included at startup, as part of the usual ROM backup (maybe also in the installer).

3. In the README under DEBUGGING you also write to use "make CONFIG_qemu=y" and the "make install_qemu" which wouldn't compile in the unified branch for the 700D. I found out that the qemu (or no dm_spy_experiments) branch is needed to use these options, maybe stress that out a bit more in the section.

Solved. Soon we'll have QEMU in mainline as well.

Still, I often test old changesets in QEMU (usually for troubleshooting, maybe "hg bisect"), so it's helpful to know how to backport this rule whenever you need it.

Also been fixing a couple of minor things.

Could you please tell me, which horizontal stretch factor is needed to have M06-1260 in the correct aspect ratio? In the actual revision I build a combobox where you can select 1.0x, 1.33x, 1.5x and 2.0x as factor. I am not sure if it is 1.5x, 2.0x or something between...

All MLV files from current and past ML builds*) have their pixel aspect ratio either 1:1 (square pixels) or 5:3 (requiring vertical stretch).

*) The only exception is if you have changed the line skipping register with adtg_gui or similar.

In fact if you switch over to another mode then back to mv1080, it stops working.

Does it help if you start the camera in that other mode, rather than switching to it?

If yes (very likely IMO), the SRM buffer may have to be freed and reallocated again when the video mode changes (because Canon's memory layout changes). Disabling raw video before switching to the new video mode, and re-enabling it afterwards, should do the trick. On crop_rec_4k, mlv_lite does something about this, but the raw backend doesn't.

For 5D2 - I also had trouble with it and could not figure out why.

Raw Video Postprocessing / Re: Informative shimmering in dual ISO?
« on: December 06, 2017, 08:32:12 PM »
Of course, just fill with zeros or (maybe better) with the boundary values from each Bayer channel. See e.g. padarray:

This is a very good guide if you want to get started:

(I might post a tutorial on this as well if others are interested)

Pages: [1] 2 3 ... 361