-
Firmware dump: http://chdk.setepontos.com/index.php?topic=288.msg121543#msg121543 (http://chdk.setepontos.com/index.php?topic=288.msg121543#msg121543)
Hello,
I tried to start porting for a r55 camera but am facing some issues...
I figured out how people found the values for the power-on trick in code_gen, but in my case, there are no obvious LDR instructions...
I guess it should be something like
*(int*)(0x2A04 + 4) = (*(int*)0xXXXXXXXX)&1 ? 0x400000 : 0x200000;but I don't know how to find the 0xCXXXXXXX value (see pictures).
https://imgur.com/MOf19cp,K9GZh92 (https://imgur.com/MOf19cp,K9GZh92)
Thanks for the help!
Edit: new keysys and dancingbits:
0x216EA8C8 and { 6,5,3,7,0,2,4,1 }.
-
I figured out how people found the values for the power-on trick in code_gen, but in my case, there are no obvious LDR instructions...
I guess it should be something like
*(int*)(0x2A04 + 4) = (*(int*)0xXXXXXXXX)&1 ? 0x400000 : 0x200000;but I don't know how to find the 0xCXXXXXXX value (see pictures).
https://imgur.com/MOf19cp,K9GZh92 (https://imgur.com/MOf19cp,K9GZh92)
You need to find the equivalent of sub_ff86b2e8 in a "reference" firmware and track back its input parameters. Then, do the same on yours and try replicating the hack that was done in the reference port. You probably want to look at one of the most recent ported cameras (DryOS r52).
I've not seen the disassembly for this cam yet, it could be that GPIOs are read indirectly. Newer firmwares appear to often use tables of MMIO addresses via getter/setter functions.
-
Thanks! I'll try to do that :)
-
My guess, based on the sx280.
I think you can just remove the call to sub_FF82D94C, continue at loc_FF8285FC to avoid the infinite loop. You of course need to set the right bit(s?) on (0x2A04 + 4).loc_ff86b8c4: ; 4 refs
ff86b8c4: b loc_ff8693a4
loc_ff8693a4: ; 8 refs
ff8693a4: ldr r1, =0xffbc0738 ; 'GPIO + bit' table
ff8693a8: ldr r2, [r1, r0, lsl #3]
ff8693ac: ldr r2, [r2] ; read GPIO
ff8693b0: add r0, r1, r0, lsl #3
ff8693b4: ldr r0, [r0, #4] ; read bitmask
ff8693b8: ands r0, r0, r2 ; return bit's state
ff8693bc: movne r0, #1
ff8693c0: bx lr
loc_ff838500: ; 3 refs
ff838500: mov r0, #0x80000000
ff838504: ldr r0, [r0, #0xffc] ; read last word of data TCM
ff838508: ldr r1, =0x12345678
ff83850c: cmp r0, r1 ; is it 0x12345678?, return the result
ff838510: movne r0, #0
ff838514: moveq r0, #1
ff838518: bx lr
ff82d94c: push {r2, r3, r4, r5, r6, r7, r8, lr}
ff82d950: mov r7, r0
ff82d954: mov r5, #0
ff82d958: bl loc_ff86b2e0 ; nullsub
ff82d95c: mov r0, #5 ; read GPIO bit (5), ON/OFF button?
ff82d960: bl loc_ff86b8c4
ff82d964: mov r4, #1
ff82d968: bic r6, r4, r0
ff82d96c: mov r0, #6 ; read GPIO bit (6)
ff82d970: bl loc_ff86b8c4
ff82d974: cmp r7, #0
ff82d978: bic r4, r4, r0
ff82d97c: beq loc_ff82d988
ff82d980: orrs r0, r6, r4 ; one of the above 2 buttons has to be pressed, otherwise shutdown
ff82d984: beq loc_ff82d9b0
loc_ff82d988:
ff82d988: bl loc_ff838500 ; data TCM check
ff82d98c: mov r2, r0
ff82d990: mov r3, r5 ; unused argument
ff82d994: mov r1, r4 ; GPIO bit (6) (PLAYBACK button?)
ff82d998: mov r0, r6 ; ON/OFF button?
ff82d99c: str r5, [sp] ; unused argument
ff82d9a0: str r5, [sp, #4] ; unused argument
ff82d9a4: bl loc_ff86b2e8 ; set startup bits
ff82d9a8: bl loc_ff86b2e4 ; nullsub
ff82d9ac: mov r0, #1
loc_ff82d9b0:
ff82d9b0: pop {r2, r3, r4, r5, r6, r7, r8, pc}
ff86b2e8: ldr r3, =0x2a04
ff86b2ec: cmp r2, #0
ff86b2f0: mov ip, #0
ff86b2f4: movne r2, #0x800000 ; depends on data TCM check
ff86b2f8: str ip, [r3, #4]
ff86b2fc: strne r2, [r3, #4]
ff86b300: cmp r0, #0
ff86b304: ldrne r0, [r3, #4]
ff86b308: orrne r0, r0, #0x200000 ; set this bit if ON/OFF pressed
ff86b30c: strne r0, [r3, #4]
ff86b310: cmp r1, #0
ff86b314: ldrne r0, [r3, #4]
ff86b318: orrne r0, r0, #0x400000 ; set this bit if PLAYBACK? pressed
ff86b31c: strne r0, [r3, #4]
ff86b320: bx lr
'GPIO + bit' table
ffbc0738: c022f484 (0)
ffbc073c: 00001000
ffbc0740: c022f484 (1)
ffbc0744: 00002000
ffbc0748: c022f484 (2)
ffbc074c: 00004000
ffbc0750: c022f484 (3)
ffbc0754: 00008000
ffbc0758: c022f484 (4)
ffbc075c: 00010000
ffbc0760: c022f484 (5)
ffbc0764: 00020000
ffbc0768: c022f484 (6)
ffbc076c: 00040000
-
Thanks for the detailed explanation! I made until the GPIO table, could not figure the which bits were read, my ARM isn't that good :)
My understanding is that you can only power-on the camera using playback/power, and it knows which button is pressed using that code, booting the camera in the correct mode.
We want to be able to override this by directly replacing the bit value, effectively tricking the camera into thinking it was booted using either power or playback even if it wasn't the case.
Thus, we have no need to know the GPIO table and instead just check the button value ? (in that case, 0xc0220020)
Only the 0x2A04 + 4 and 0x20000/0x40000 are key, the 0xc0220020 can be found in the stubs entries?
-
We want to be able to override this by directly replacing the bit value, effectively tricking the camera into thinking it was booted using either power or playback even if it wasn't the case.
Yes.
Thus, we have no need to know the GPIO table and instead just check the button value ? (in that case, 0xc0220020)
Only the 0x2A04 + 4 and 0x20000/0x40000 are key, the 0xc0220020 can be found in the stubs entries?
Where does 0xc0220020 come from? If it's an alternative address of the button's GPIO, that might be OK, otherwise you can just take the address and the bit from the GPIO table and check that directly.
edit:
You can also check the bits in the source of physw_status, 0xc0220200 (you may have meant this address), use KEY_POWER's bit (it's in stubs_entry.S).
-
It comes from the stubs generated by finsig, and I assumed the MMIO table is usually at 0xc022XXXX
// { 0, KEY_POWER ,0x00000020 }, // Found @0xffbc0b10, levent 0x100
It's just that I read more times 0xc022 than the ones from the gpio table :)
---
I guessed some values about the focus min/max values, but I really have no way to guess aperture values (unless they're string and I didn't see them), could someone who has the camera check:
- max aperture at min focal length
- max aperture at max focal length
By looking at the firmware, I guessed that min/max focal are 5.0 and 25, please correct me if I'm wrong.
I was looking at the a2500 firmware for 30 mins -_-
-
I really have no way to guess aperture values (unless they're string and I didn't see them), could someone who has the camera check:
- max aperture at min focal length
- max aperture at max focal length
It's written on the camera's lens.
One more thing:
The guy trying to port the ixus145 reported that the sigfinder's guesses are wrong for several buttons.
-
One more thing:
The guy trying to port the ixus145 reported that the sigfinder's guesses are wrong for several buttons.
Okay, I'll use the GPIO then, thanks :)
-
Can someone with the camera try this firmware ?
thanks :)
-
Hey adongy!
Thank you for the work, and once again sorry about the late reply.
I looked at both firmware versions, but I am not sure how/what to test.
In any case, I still see the same debugging parameters in four quadrants of the screen, and I tried to switch to record mode without any luck. Most other stuff (rmem, ls, upload, ...) in play mode seems to work.
Please let me know if there is anything I can do to help you further.
Mark
-
Thanks for testing Mark!
I will try to build some more firmwares to see if I can fix the viewport buffers, but if anyone has ideas on how to do it I'm eager to hear your input!
-
I will try to build some more firmwares to see if I can fix the viewport buffers, but if anyone has ideas on how to do it I'm eager to hear your input!
Try reading the related posts of the ixus145 porting thread (page 4 (http://chdk.setepontos.com/index.php?topic=12144.30)). It probably won't help much though because the bitmap buffer issue hasn't been resolved and porting halted eventually.
I would still recommend dumping a bit of RAM and verifying the buffer dimensions from it.
Since your posts seem to indicate that you're doing this without the camera, make a debug build that dumps the first 8MB RAM automatically after a few seconds delay and ask a tester to upload the dump.
edit:
There is a RAM dumper facility in the CHDK core. Place the following code right before the main while loop in core/main.c (at the end of core_spytask()):
memdmp_delay = 5; // 5 sec delay before dumping
conf.memdmp_size = 8*1024*1024; // 8MB
conf.memdmp_start = 0;
schedule_memdump();
-
Thanks for telling me! I found a lua script, and got it dumped. (Fwrite_Fut)
-
Who can help adongy and me with a strange display issue with the ixus 160?
http://glasno.st/MVI_5653.AVI (http://glasno.st/MVI_5653.AVI)
The chdk stuff jumps between the correct place on the screen and half off the bottom of the screen. It seems to get triggered by different things:
* Canon firmware "auto mode" (permanent autofocus?) on makes it jump really fast between the two positions.
* the left rotary dial button, apart from doing what it is supposed to do, currently also triggers the jumping (see video).
Any ideas what could cause this, and how to avoid it? Feel free to ask for further information if the above was not clear!
(I'm trying to help adongy as best as I can with the port, using my *nix experience and camera. The ixus 160 currently boots, CHDK has correct screen resolution, and at least rotary dial and play keys are bound correctly. And we have basic chdkptp access to it. That's how I dumped the RAM.)
-
Who can help adongy and me with a strange display issue with the ixus 160?
There are two ways:
1) CAM_BITMAP_HEIGHT needs to be redefined in platform_camera.h (see other recent ports, it's usually 270, but I can't say for sure)
2) define DRAW_ON_ACTIVE_BITMAP_BUFFER_ONLY and implement the underlying routines in the platform lib.c (this one is preferred on the long run as it gets rid of writing both bitmap buffers)
The chdk stuff jumps between the correct place on the screen and half off the bottom of the screen. It seems to get triggered by different things:
* Canon firmware "auto mode" (permanent autofocus?) on makes it jump really fast between the two positions.
* the left rotary dial button, apart from doing what it is supposed to do, currently also triggers the jumping (see video).
You see the jumping CHDK display because:
The Canon bitmap overlay uses two buffers. One of them is visible on the screen. Certain actions which redraw the Canon overlay swap the active buffer (to avoid tearing/snow). CHDK doesn't currently use the correct bitmap buffer height, so whenever the second buffer is on screen, a mispositioned CHDK overlay is shown.
Any ideas what could cause this, and how to avoid it? Feel free to ask for further information if the above was not clear!
(I'm trying to help adongy as best as I can with the port, using my *nix experience and camera. The ixus 160 currently boots, CHDK has correct screen resolution, and at least rotary dial and play keys are bound correctly. And we have basic chdkptp access to it. That's how I dumped the RAM.)
Can you upload an above mentioned RAM dump? For best results, keep a few JPEGs on the card and enable some Canon overlay prior to dumping.
-
Can you upload an above mentioned RAM dump? For best results, keep a few JPEGs on the card and enable some Canon overlay prior to dumping.
http://glasno.st/LIVE_8MB.BIN (http://glasno.st/LIVE_8MB.BIN)
Note that this was (I think) without any JPEGs on the card or Canon overlay prior to dumping.
-
Can you upload an above mentioned RAM dump? For best results, keep a few JPEGs on the card and enable some Canon overlay prior to dumping.
http://glasno.st/LIVE_8MB.BIN (http://glasno.st/LIVE_8MB.BIN)
Thanks.
Note that this was (I think) without any JPEGs on the card or Canon overlay prior to dumping.
Confirmed, no Canon overlay is visible.
The following goes in platform_camera.h
#undef CAM_USES_ASPECT_CORRECTION
#define CAM_USES_ASPECT_CORRECTION 1
#undef CAM_BITMAP_WIDTH
#undef CAM_BITMAP_HEIGHT
#define CAM_BITMAP_WIDTH 720 // Actual width of bitmap screen in bytes
#define CAM_BITMAP_HEIGHT 360 // Actual height of bitmap screen in rows... and it looks like akira's numbers (http://chdk.setepontos.com/index.php?topic=12144.msg119746#msg119746) were correct.
-
Thanks for this!
Can I ask you how did you find it ?
-
Can I ask you how did you find it ?
I'm using a program named Hexplorer (http://chdk.setepontos.com/index.php?topic=12144.msg119748#msg119748) and its 'Pixel view' window (usage: set the width you expect - 720 in this case, 8 bit mode, use the main window for navigation (either go directly to the address you're suspecting or browse through the file until you find something that looks like a framebuffer). You can jump around by using the 'View' -> 'Go to address' window. Note that framebuffer addresses always appear with the 'uncached' bit set, so go to 0x711000 to find the 2 consecutive bitmap buffers. The buffers are often surrounded by uninitialized RAM content.
Hexplorer is a Win32 executable, works well under Wine. Its user interface is not very user friendly, but it's usable.
-
Haaaa that's what it meant by columns :) I had it set to the default 250, that's why i couldn't find any image.
Edit:
Does that help in finding the viewport_buffers and/or different get_viewport_fb_d/live_d ... functions ?
-
Does that help in finding the viewport_buffers and/or different get_viewport_fb_d/live_d ... functions ?
These are buffers (http://chdk.wikia.com/wiki/Frame_buffers) with the Y411 variant of YUV, their width is likely 720, height is 240 or 480. It could be however that Canon has changed things in DIGIC 4+ and introduced a different YUV variant for live buffers.
If you're not sure about the viewport addresses, you can try to hunt them down visually.
Once you have collected buffer addresses, you can search for them in ROM and RAM. Note that the live buffers are usually quad-buffered (in known new cameras), that's 4 consecutive equal size buffers. Also note that new cameras have other framebuffers in various sizes, which are not used by CHDK.
fb_d is the playback mode buffer, the others are obviously only active in record mode (you'll need to request new RAM dumps from the whole RAM - unless you're only suspecting a smaller area). The RAW buffers may overwrite these buffers' content after a shot is taken.
edit:
Wait a second... If chdkptp is working, it's enough to confirm that the "viewfinder" (live tab) shows what's on the LCD - no need for those huge dumps.
-
Another dump, this time with the menu enabled and a photo saved on the card.
http://glasno.st/LIVE.BIN.201504271143 (http://glasno.st/LIVE.BIN.201504271143)
-
Github repo for the code:
https://github.com/adongy/ixus160_elph160/ (https://github.com/adongy/ixus160_elph160/)
-
It could be however that Canon has changed things in DIGIC 4+ and introduced a different YUV variant for live buffers.
Fortunately, they did not. A framebuffer is visible at the end of the new dump, it has the usual Y411 (6byte/4pixel) format.
-
Test build to see if PTP live view works, mainly taken from the N.
-
Hello,
I am in the process to create a mutlicamera rig. IXUS 160 is still in the market, so it looks that i can find 60 cameras in stock.
I have already ordered 2 cameras, so i can test shooting over PTP and download the images to PC.
Can you please advice which test build should i download in order to test? Any advice on the matter will be much appreciated.
Thanks
Anastasios
-
I am in the process to create a mutlicamera rig. IXUS 160 is still in the market, so it looks that i can find 60 cameras in stock. I have already ordered 2 cameras, so i can test shooting over PTP and download the images to PC. Can you please advice which test build should i download in order to test? Any advice on the matter will be much appreciated.
Good luck with your project! Let's be sure to discuss how you are going to interconnect all these cameras - although not in this thread.
-
I am in the process to create a mutlicamera rig. IXUS 160 is still in the market, so it looks that i can find 60 cameras in stock.
This port is still work in progress and the developer (AFAIK) doesn't have the camera. Try getting in touch with adong, perhaps you could help making the development a bit easier for him...
-
I am in the process to create a mutlicamera rig. IXUS 160 is still in the market, so it looks that i can find 60 cameras in stock. I have already ordered 2 cameras, so i can test shooting over PTP and download the images to PC. Can you please advice which test build should i download in order to test? Any advice on the matter will be much appreciated.
Good luck with your project! Let's be sure to discuss how you are going to interconnect all these cameras - although not in this thread.
Thank you. Will open a new thread to discuss the interconnection of the cameras, as i will need all the help i can get :-)
-
I am in the process to create a mutlicamera rig. IXUS 160 is still in the market, so it looks that i can find 60 cameras in stock.
This port is still work in progress and the developer (AFAIK) doesn't have the camera. Try getting in touch with adong, perhaps you could help making the development a bit easier for him...
Thanks for the reply. Will get in contact with adong and send him a camera in order to speed up development.
-
https://drive.google.com/uc?id=0B8jwFYgxPF-JRFZwYkhHR1pacTA
Test build to see if PTP live view works, mainly taken from the N.
I loaded the test build in my IXUS160 with the bootable SD card method successfully. Ptpcamgui actually worked with my camera :D. As a first ever attempt with CHDK, i will keep testing ptpcamgui and let you know with my feedback. FYI, your camera is travelling to you so you can test the build by yourself.
-
https://drive.google.com/uc?id=0B8jwFYgxPF-JRFZwYkhHR1pacTA
Test build to see if PTP live view works, mainly taken from the N.
I loaded the test build in my IXUS160 with the bootable SD card method successfully. Ptpcamgui actually worked with my camera :D. As a first ever attempt with CHDK, i will keep testing ptpcamgui and let you know with my feedback. FYI, your camera is travelling to you so you can test the build by yourself.
Tested the build with chdkptp and live view didn't work with my system. Furthermore when the camera is in play mode i cannot get it back to shooting mode.
-
Hello guys
thanks for trying to por the IXUS160.
@adong
i have upload the last app from this post in my camera firmware 100A.
something seem to work , it says test version expire,on start via the play icon , it shows the chdk logo and some numbers moving also th overlay of this sort of blinking.
is this a good or bad sign ?
anything you propose i could try , i could be your alpha beta tester if you need some more testers.
let me know , cheers and thank you ;D
-
Hi
i upload the last zip i found in this post , and it seemed to load properly , i tested only the remote feature in CA-1 mode and it works , ill keep testing , thanks
-
Thanks to amavroidis, I now have the camera, which means faster testing :-)
I will now post zips when something gets updated.
This build should fix palette, picture modes (auto, P, ...)
There is still no remote shoot, and shoot takes 2 shots (go figure out why...)
-
shoot takes 2 shots
'shoot' will retry shooting once if it thinks the shot was unsuccessful. I'm not sure what could be causing it, but here's a few ideas:
- check whether PROPCASE_SHOOTING does what it's supposed to (you may have a new propset)
- one or more capt_seq hooks don't work
Please check the asm parts in capt_seq.c (and perhaps elsewhere), you have .ltorg directives in very inappropriate places (place them where they can't be executed, e.g. after asm functions, see other ports).
-
shoot takes 2 shots
'shoot' will retry shooting once if it thinks the shot was unsuccessful. I'm not sure what could be causing it, but here's a few ideas:
- check whether PROPCASE_SHOOTING does what it's supposed to (you may have a new propset)
- one or more capt_seq hooks don't work
Please check the asm parts in capt_seq.c (and perhaps elsewhere), you have .ltorg directives in very inappropriate places (place them where they can't be executed, e.g. after asm functions, see other ports).
Ah yes I misread .ltorg's use, I thought it would add the b call to skip over it automatically, which is not the case.
I will retry something this week.
-
I would like to add that this lua script only shoots once:
press("shoot_half")
repeat
sleep(50)
until get_shooting() == true
click("shoot_full")
Same with the SHOOT.lua (delayed shooting) packed with CHDK.
click("shoot_full") also shoots only one time.
shoot() with always take two shots.
(This is after .ltorg relocation)
-
I would like to add that this lua script only shoots once:
(...)
Same with the SHOOT.lua (delayed shooting) packed with CHDK.
That is expected, because only the shoot() script command is able to retry shooting (simple keypress commands don't do that).
If I interpret the related code in core/action_stack.c right:
In action_stack_AS_WAIT_SHOOTING_DONE(), (camera_info.state.state_shooting_progress == SHOOTING_PROGRESS_NONE) evaluates as 'true' and another shot will be scheduled.
The only place state_shooting_progress can become SHOOTING_PROGRESS_NONE is in action_push_shoot() (core/action_stack.c). It seems like camera_info.state.state_shooting_progress doesn't get updated for some reason (search for state_shooting_progress in the source to see the routines involved).
Do photo overrides / dark frame control / raw saving work (these are the hooks in capt_seq)?
-
After testing PROPCASE_SHOOTING, I think its value is correct: 0 when not shooting, 1 when half press / shooting / saving to sd card.
None of the hooks seem to work so I think my code_gen code is not complete yet.
It was made by comparing with ixus140 and a2500 but there are small differences which could lead to the generated code not to work.
-
After testing PROPCASE_SHOOTING, I think its value is correct: 0 when not shooting, 1 when half press / shooting / saving to sd card.
It's probably OK then.
None of the hooks seem to work so I think my code_gen code is not complete yet.
I see it now. CreateTask is located in ROM (and therefore can't be patched with conventional methods). Its lower level function (sub_6B15A4) will need to be patched instead which is still in RAM. I'll get back to this later.
edit:
candidate patch attached
-
Sadly it crashes after taking a shot. Attached the romlog.
Tested shooting over PTP and physically: both crash at the same time, which is as soon as the shot ends and it shows "busy" for writing the data.
It does go further as the RAW folder gets created.
Maybe the raw address hook is wrong, I will test again without it.
Edit:
RAW hook is wrong, that's why it crashed.
Now it still takes two shots, but overrides works (I tried 10 sec tv and it worked)
-
The hook(s) might be fine.
The crash happens inside GetImageFolder(). Note that GetImageFolder() only has 3 arguments in this firmware, so please remove the fourth one when you call it in get_target_dir_name().
time()'s correct address is 0xffa1b39c (it's referenced in the SetDate_FW function). Since GetImageFolder() has apparently changed somewhat, its arguments / return value may not be what's expected.
_log10 can be found with help of the CalcLog10 firmware function (and you guessed its address right). The temperature functions are found correctly by the sigfinder.
-
Back with more testing:
With only 3 parameters it still crashed.
Looking at the asm and comparing to the ixus140, while the beginning of the function looks the same, the codepath to the sprintf is quite different.
For now I replaced the _GetImageFolder with some C code to test if it worked.
RAW + DNG:
The DNG gets written, size about 24MB, but I can't seem to open it in my image viewer (I think it can open dng files fine, may have to test that). I quickly downloaded Able RAWer and i gave me floating point division by zero error or something like that.
First few bytes as I don't know if there's a magic header for dng:
49492A00080000002200FE0004
At the beginning there is also a string:
02215252CanonCanon IXUS 160CHDK ver. 1.3.0-3002015:05:24 12:54:43Canon IXUS 160-e@B2015:05:24 12:54:43
Apart from this, when I enable RAW saving, the jpg image has weird colors in some places (purple shade)
RAW (without DNG):
Saves JPG correctly (no color issue), didn't try to open it as i don't have converter software.
No RAW:
shoot works correctly (1 time), as well as remote shoot.
-
Back with more testing:
With only 3 parameters it still crashed.
Looking at the asm and comparing to the ixus140, while the beginning of the function looks the same, the codepath to the sprintf is quite different.
Problem is, (the function we call) GetImageFolder is unreferenced in the firmware, so guessing its arguments is not so easy.
The DNG gets written, size about 24MB, but I can't seem to open it in my image viewer (I think it can open dng files fine, may have to test that). I quickly downloaded Able RAWer and i gave me floating point division by zero error or something like that.
Did you fix time()? If yes, perhaps one or more stubs could be wrong (i.e. incorrectly found by the sigfinder).
Apart from this, when I enable RAW saving, the jpg image has weird colors in some places (purple shade)
The raw hook is placed too 'late', the firmware has already started image processing prior that point. It could also be that hooking raw in capt_seq is no longer possible (like on the sx170).
RAW (without DNG):
Saves JPG correctly (no color issue), didn't try to open it as i don't have converter software.
You can experiment with http://chdk.wikia.com/wiki/DNG4PS-2 (http://chdk.wikia.com/wiki/DNG4PS-2) or upload a sample.
-
Is there any way to create a buffer in chdkptp ? My understanding is that the first argument is a char* that the function fills, the others are enough information to make the directory unique (per month).
I could try different values and try to call it using call_func_ptr instead of recompiling firmwares everytime.
I did fix time() to the address you gave me.
I will try to put the hook earlier.
Edit: multiple tries to put it earlier, it either does not work anymore (2 shots) or it doesn't save at all, the way it is now is the earliest i can put it (unless there is another way I haven't explored)
-
Is there any way to create a buffer in chdkptp ? My understanding is that the first argument is a char* that the function fills, the others are enough information to make the directory unique (per month).
I could try different values and try to call it using call_func_ptr instead of recompiling firmwares everytime.
You can call fw functions (such as malloc) with call_func_ptr() (http://chdk.wikia.com/wiki/Lua/Lua_Reference/Native_Function_Calls#call_func_ptr.28fptr.2C....29).
You can also use 0x1000 bytes starting at 0x40000000 without allocation (this can cause trouble if the function you're calling ignores the caching bit of the address). If you're not using 'ARAM', you can also use this area without allocating it:
// ARAM_HEAP_START = 0x60e000 // Found @ 0xff9a53d0
// ARAM_HEAP_SIZE = 0x22000 // Found @ 0xff9a5390
I did fix time() to the address you gave me.
That means the cause of DNG header corruption is yet to be found...
edit:
Edit: multiple tries to put it earlier, it either does not work anymore (2 shots) or it doesn't save at all, the way it is now is the earliest i can put it (unless there is another way I haven't explored)
You may have to take a look at the sx170 code and hook DvlpSeqTask instead.
-
Tried different ways to call GetImageFolder, always crashes the camera. I kept the C way for now.
Looked at the sx170 code, tried to port it, but camera does not even boot, romlog gives a crash at expdrv task.
-
Looked at the sx170 code, tried to port it, but camera does not even boot, romlog gives a crash at expdrv task.
You only need the dvlpseq related part from that, along with a boot.c modification to replace the original dvlpseq task. The only hook that needs to be relocated is the raw hook.
-
I know, that's what I did, still gave a crash at that point. Will test more tomorrow.
-
I know, that's what I did, still gave a crash at that point.
Try moving the raw hook right after
BL sub_FF99C6C0but before the label.
Can you upload one of those bad DNGs? The first 100kB or so is probably sufficient.
-
That's what I first tried and it didn't work (skips raw saving altogether), I will retry since I saw I made a typo in my code.
Here is a DNG header that I got without the Dvlp hook.
Made with head -c100k CRW_...DNG
Edit: putting it before the label doesn't crash the camera, but it doesn't save it whether I select RAW or DNG.
-
That's what I first tried and it didn't work (skips raw saving altogether), I will retry since I saw I made a typo in my code.
(...)
Edit: putting it before the label doesn't crash the camera, but it doesn't save it whether I select RAW or DNG.
That's very odd because that seems to be (almost) equivalent to the spot used in the sx170 port (which is known to work).
You could try some debugging (below snippet is just a suggestion):
"loc_FF99BD38:\n"
" LDR R0, [R1, #8] \n"
" MOV R1, #1 \n"
" BL sub_FF99C6C0 \n"
"BL debug_func_1\n"
"loc_FF99BD44:\n"
(...)
long debug_func_1(long x) {
*(int *)(0x40000000) += 1;
return x;
}Print *(int *)(0x40000000) somewhere on the screen and see whether it's increasing as you shoot.
edit:
your DNG header snippet has suffered an LF -> CRLF conversion (a 0x0d byte is added before every 0x0a byte) :blink:
-
nope, doesn't increment at all. Will investigate more this weekend.
As for the crlf issue, cygwin is to blame I think :(
Trusty ol' dd to the rescue!
Sorry for the zip, forums doesn't want me to upload files with weird names
-
nope, doesn't increment at all.
In this case you'll have to discover what happens when you shoot, in the following tasks:
- capt_seq
- dvlpseq
That usually means logging of the so-called messages received by those tasks. My debug patches made for the sx170 may give some ideas (if not, please ask). See this year's attachments in the sx170 porting thread (http://chdk.setepontos.com/index.php?topic=11164.msg119683#msg119683).
edit:
dng_validate (from the Adobe DNG SDK) shows the following for your DNG head:
*** Error: CFAPattern does not contain all the colors in the CFAPlaneColor tag (SubIFD 1) ***
-
About the DNG: I just read the DNG2PS documentation, I will calibrate the camera this week and try again.
I will read about the debug patches, I think I understood the big idea :-)
Thanks for the help as always!
Edit: With the current raw hook (not in dvlptask), using dng4ps's calibrate crashes the program.
-
Back with the debug patchs:
Unfortunately the camera logs show it's not quite the same as sx170, as the dvlp task does not get hit with the correct args.
Excerpt from IXUS160 logs:
00271510: UI:_ContiCount->0(5632)
00271510: UI:_ManagePTMProperty
00271510: SS:ModChg
00271510: SS: Evf=1
00271510: SS: 8241->8000
00271510: SS: Asp 0000->0000
00271520: SS:ModChg*
00271520: UI:_DecideCaptureMode
00271520: UI:_StillToStill
00271520: UI:_StartStill
00271520: UI:_ContiCount->0(5632)
00271520: UI:DSIC:42,2
00271530: UI:DSIC:d3,0
00271560: UI:Display_CaptInfo
00271570: UI:VTMUnLock
00271570: UI:TerminateDeliverToZoomController
00271570: UI:OPTICAL_ZOOM_POS
00271570: UI:UnpressZoomLever
00271570: UI:DispSwCon_TurnOnDisplayDevice
00271570: UI:LogicalEvent:0x0000313e:adr:0,Para:0
00271590: UI:DSIC:d5,0
00271590: UI:VTMLock
00271600: UI:VTMUnLock
00271600: UI:_DecideModeDial
00271610: UI:LogiEvnt_NotPowerType:0x000009a4:adr:0,Para:0
00271610: UI:LogiEvnt_NotPowerType:0x000009a2:adr:0,Para:0
00271610: UI:DSIC:6a,0
00272400: UI:Button:0x000009A1:PressSwOne
00272400: SS:PreBuf
00272400: SS:BitR
00272400: UI:ShtCon_ResetShootingNumber
00272400: UI:ShootState:0x1
00272400: UI:ShtCon_Activate
00272400: UI:DispSw: Lock
00272400: UI:ShtCon_ShutDownRecModeMenu
00272400: UI:DSIC:61,0
00272400: UI:VTMLock
00272400: UI:VTMUnLock
00272410: UI:VTMLock
00272410: UI:VTMReduuce
00272410: UI:LogicalEvent:0x00003136:adr:0,Para:0
00272410: UI:ShtCon_PrepareCapture
00272410: SS:PreCapt
00272410: UI:ShootState:0x2
00272410: UI:ClearEventComp
00272420: UI:VTM SW
00272420: UI:VTMUnLock
00272720: UI:ShootSeqToUI:0x0000203b:adr:0,Para:0
00272730: UI:ShtCon_SetAFBeep
00272730: UI:DSIC:69,0
00272870: UI:ShootSeqToUI:0x00002006:adr:0x1d5c,Para:7516
00272870: 000c83a3:capt 0
00272870: UI:ShtCon_SetPreCapt
00272870: UI:DSIC:62,1
00272870: UI:VTMLock
00272870: UI:DSIC:d5,0
00272890: UI:Button:0x000009A3:PressSwTwo
00272900: UI:VTMUnLock
00272900: UI:_ResetShootingMode
00272900: UI:_EntryPrepareShoot
00272900: UI:ShootState:0x6
00272910: UI:ShootState:0x7
00272910: UI:ShootState:0x18
00272910: UI:DSIC:12,0
00272910: UI:_MuteOn
00272910: UI:DSIC:43,0
00272910: UI:DispSwCon_MuteOnPhysicalScreen
00272910: UI:Window MuteOn
00272910: UI:MuteOnPhysicalScreen
00272910: SS:StartShoot
00272910: SS:SCtrl:Shoot(1/0x1)
00272920: UI:Button:0x000009A4:UnpressSwTwo
00272920: UI:Button:0x000009A2:UnpressSwOne
00272930: 000d6589:capt 4
00272930: UI:ShootSeqToUI:0x0000203f:adr:0xff99a090,Para:-6709104
00272930: UI:_CaptureCount->1
00272930: UI:DSIC:63,0
00272930: UI:VTMLock
00272940: UI:VTMUnLock
00272940: UI:VTMLock
00272950: UI:VTMReduuce
00272950: UI:VTMLock
00272950: UI:VTMReduuce
00272950: UI:DSIC:6a,0
00272950: UI:VTM SW
00272950: UI:VTMUnLock
00272950: UI:_MuteOff
00272950: UI:DSIC:44,0
00272950: UI:DispSwCon_MuteOffPhysicalScreen
00272950: UI:Window MuteOff
00272950: UI:MuteOffPhysicalScreen
00272980: UI:ShootSeqToUI:0x00002040:adr:0x581a38,Para:5773880
00272980: UI:DSIC:64,0
00273810: 000ad421:capt 2
00273810: 000aeb60:dvlp q1 0 1 1cab0, 0
00273810: UI:DSIC:45,0
00274300: SS:SCtrl:RecReview
00274300: SS:SCtrl:StartReview
00274300: UI:ShootSeqToUI:0x00002041:adr:0x1c974,Para:117108
00274460: UI:ShootSeqToUI:0x0000203e:adr:0,Para:0
00274460: UI:ShootSeqToUI:0x00002001:adr:0x582e68,Para:5779048
00274460: UI:Sht_CancelStrobeChargeTimer
00274460: UI:DSIC:4c,0
00274460: UI:VTMLock
00274460: UI:VTMUnLock
00274460: SS:SCtrl:NextShot(1)
00274460: UI:DSIC:46,0
00274460: UI:_CaptureStanbyForReview
00274460: SS:SCtrl:CompShootPic(0)
00274460: UI:ShootSeqToUI:0x00002029:adr:0x1c980,Para:117120
00274460: UI:_NormalCompleteShootPictureAction
00274460: UI:_CheckNextShotAvailable
00274470: UI:_CaptureCount->0
00274470: UI:ShtCon_ResetShootingNumber
00274470: UI:ShootState:0x8
00274470: UI:ShtCon_StartReview
00274470: UI:_EntryActionReview
00274470: UI:LogicalEvent:0x0000311f:adr:0,Para:0
00274470: UI:_EnableReviewHold:IsPressSwTwo:0
00274470: UI:_EnableReviewHold:IsAvailableShots:1
00274470: UI:RecReviewCon_SetMode:0x0003
00274470: UI:DSIC:4c,0
00274470: UI:VTMLock
00274470: UI:VTMReduuce
00274470: SS:StopRev
00274470: UI:VTMLock
00274470: UI:PB.StartDecodeRecReview_S
00274480: UI:PB.RefPB
00274490: UI:IPS.DrawI
00274490: SS:NextAvail(11),ReviewAvail(9)
00274510: UI:PB.StartDecodeRecReview_E
00274510: UI:StartRecReviewTimer
00274510: UI:ShootState:0x9
00274510: UI:ShtCon_ResetShootingNumber
00274510: SS:ExitShoot
00274710: UI:IPS.DComp:0
00274710: UI:LogicalEvent:0x00003204:adr:0,Para:0
00277330: UI:DSIC:47,0
00278450: UI:DSIC:48,0
00278470: 0001ee65:capt 3
00278470: UI:LogicalEvent:0x0000311e:adr:0,Para:0
00278470: UI:PB.RfrsI
00278480: UI:DispSwCon_MuteOffPhysicalScreen
00278480: UI:Window Reduce MuteOff
00278480: UI:VTMUnLock
00278480: UI:Window Re MuteOff
00278480: UI:Window MuteOff
00278480: UI:MuteOffPhysicalScreen
00278480: UI:_EntryPrepareRecreviewOff
00278480: UI:ShootState:0xB
00278480: UI:ShtCon_StopReview
00278480: UI:StopRecReviewController
00278480: UI:PB.StopDecodeRecReview_S
00278480: UI:PB.StopR
00278480: UI:VTMLock
00278490: UI:VTMReduuce
00278490: UI:LogicalEvent:0x00003120:adr:0,Para:0
00278490: UI:PB.StopDecodeRecReview_E
00278490: UI:ShtCon_ResetShootingNumber
00278490: UI:_ExitSequence
00278490: UI:Sht_CancelStrobeChargeTimer
00278490: UI:DSIC:4c,0
00278490: UI:VTMLock
00278490: UI:VTMReduuce
00278490: UI:_ExitActionReview
00278490: SS:CancelPre
00278720: UI:VTMLock
00278720: UI:VTMUnLock
00278860: UI:DispSwCon_MuteOffPhysicalScreen
00278860: UI:Window MuteOff
00278860: UI:MuteOffPhysicalScreen
00278860: UI:ShootState:0x0
00278860: UI:ShtCon_Deactivate
00278860: UI:DSIC:12,0
00278870: UI:DSIC:60,0
00278870: UI:DispSwCon_TurnOnDisplayDevice
00278870: UI:VTMLock
00278870: UI:DSIC:d5,0
00278900: UI:VTMUnLock
00278900: UI:DispSw: Unlock
00278900: UI:DispSwCon:Unlock
00278900: UI:_ChangeDisplayOut
00278900: UI:TerminateDeliverToZoomController
00278900: UI:OPTICAL_ZOOM_POS
00278900: UI:UnpressZoomLever
00278900: UI:VTMLock
00278900: UI:VTMReduuce
00278900: UI:VTMLock
00278900: UI:VTMReduuce
00278900: UI:_EntryIdleShoot
00278910: UI:ShootState:0x0
00278910: UI:VTM SW
00278910: UI:VTMReduuce
00278910: UI:VTM SW
00278910: UI:VTMReduuce
00278910: UI:VTM SW
00278910: UI:VTMUnLock
00278960: UI:VTMLock
00278960: UI:VTMUnLock
00278960: SS:ChargeComplete
00281630: UI:VTMLock
00281630: UI:VTMUnLock
00282330: UI:VTMLock
00282340: System.Create
00282340: StartRedirectUART
00282340: UI:VTMUnLock
00282350: Printf
00282350: ShowCameraLog
uartr.lua: start UART redirection
(capt indexes are a little bit different, in ixus160 what is called capt 4 is capt 3 in sx170 and capt3 was not in sx170, sorry about that)
So looking at dvlp lines, there is no "dvlp q1 3 x x, x" so the "" BEQ loc_FF99BD38 \n" // 1st msg after shoot" never gets hit.
Successfully tested with putting the debug func at "loc_FF99BD44:\n", I can increment the value.
There is also no SS Raw event, but I don't know if it's just the camera.
(didn't implement the fwt log hooks)
We can also see that the capt 2 call is actually earlier than the dvlp call, so no point if I understood right to put it in dvlpseqtask.
-
Edit: With the current raw hook (not in dvlptask), using dng4ps's calibrate crashes the program.
Wwait... Isn't this using a simple RAW file? Did you create a camera profile for your camera? (If you did create one that lets you convert RAWs to usable DNGs, it might be that your 20MP pictures exceed some internal limit and cause the program to crash.)
-
0.2.3 branch does not have calibration features, only the 0.2.2 has (unless there is another build than the google code one)
It does use a RAW file (not DNG), but if I understood right, from the JPG and RAW file (and a picture of a calibration pattern) I can generate a camera profile.
-
0.2.3 branch does not have calibration features, only the 0.2.2 has
I've never checked whether this feature was actually removed or just disabled. The 0.2.2 Windows release offers no camera customisation features (it only knows some cameras in the 5 .. 10 Mpixel range), so you are out of luck unless you hack on the source...
BTW, the reason for my reply was that the location of the raw hook will have no impact on the raw data size, only on its content.
May I ask what kind of raw do you get when using either the capt_seq or the dvlpseq raw hook (is it clean or corrupted)? Can you upload a sample?
Unfortunately the camera logs show it's not quite the same as sx170, as the dvlp task does not get hit with the correct args.
Yeah, they seem to have changed how things work...
(capt indexes are a little bit different, in ixus160 what is called capt 4 is capt 3 in sx170 and capt3 was not in sx170, sorry about that)
Can you show the patched source (for clarity, I have several versions of those patches laying around)?
We can also see that the capt 2 call is actually earlier than the dvlp call, so no point if I understood right to put it in dvlpseqtask.
When the hook is placed in dvlpseq, it might be possible to catch raw in cases when the original capt_seq location is not usable (example: auto mode, low light mode - though the latter is not supported by the current source).
You could check this one day, but it isn't priority at the moment.
-
Updated the github repo.
Here is a raw + jpg taken with the latest changes.
https://www.dropbox.com/s/wlcttaq1so9q3z6/ixus160_raw_test.rar?dl=0 (https://www.dropbox.com/s/wlcttaq1so9q3z6/ixus160_raw_test.rar?dl=0)
Edit: you may notice there is something completely inconsistent with the logs I posted (getmachinetime is totally missing).
At first I didn't correctly use the biglog.lua script, so there was nothing, so I removed the first arg, but forgot to run make clean before rebuilding, making this wierd soup of new defines but old style logging (I didn't have much time to test this week). I believe it did not take the new version of the logging functions at all, so don't pay too much attention to the format.
-
Updated the github repo.
Here is a raw + jpg taken with the latest changes.
https://www.dropbox.com/s/wlcttaq1so9q3z6/ixus160_raw_test.rar?dl=0 (https://www.dropbox.com/s/wlcttaq1so9q3z6/ixus160_raw_test.rar?dl=0)
Thanks. I did not yet make a dng4ps-2 profile for the raw, so I don't know how it looks. I did notice however that the file size is not what's expected. Reason: the default bitdepth for RAW is 10bits, your 'from scratch' platform_camera.h doesn't redefine CAM_SENSOR_BITS_PER_PIXEL.
Things might be easier if you start with another port's platform_camera.h (the closest the better), and comment/uncomment/change its entries, keeping its format. I suspect that some RAW/DNG related define is also missing, causing the previously discussed DNG problem.
If the logging functions' location corresponds to the source, that's good enough.
If you plan on using this logging method note, that some buffer can't hold the desired number of entries and you may experience 'datalost' messages if there's too many entries in the log. ('Some buffer' means either the Canon log buffer or the UART redirector's buffer (if any) or something else...)
-
Ok will try to do that next week.
By any chance, do you have a raw img tester? I have both win and nix so either is fine. That way I'll know when my raw is correct.
-
By any chance, do you have a raw img tester?
Not sure I understand. If you'd like to convert RAWs to DNG (which can be opened by many applications), set up a camera profile in DNG4PS-2:
Settings -> Camera options -> (choose a camera from the list) -> "Copy..." -> "Yes" -> adjust the fields below -> close the window with "OK"
and then
Settings -> Camera types -> 5248x3920 (may not be visible in the official version(?)) -> IXUS 160 -> "OK"
If these are done and the RAW file size is correct, RAWs will show up in the main window if you browse to a folder with your RAW files.
You only need to use DNG4PS-2 until you figure out all parameters for a correct in-camera DNG.
edit:
Attached a screenshot, mosaic type may not be correct, you need to work out the rest (color matrix). The program will expect files with 5248*3920*(12/8) bytes size.
edit2:
if 5248*3920 is not showing up on the "Camera types" page, try my hacked (http://chdk.setepontos.com/index.php?topic=7929.0) version (or perhaps try compiling the latest official (https://github.com/crass/dng4ps2) source, maybe they fixed this UI limitation).
edit3:
... and yes, the RAW data is corrupted, see attachment
-
Can't seem to make it work, the UI isn't translated (like buttonOption etc) and it doesn't detectg raw files.
-
Can't seem to make it work, the UI isn't translated (like buttonOption etc) and it doesn't detectg raw files.
If you're using 0.2.3:
Settings: second button from left at the bottom of main window
UI language: first dropdown box from the bottom of the settings window
You also need the language file(s), for example English: langs/en/dng4ps-2.mo in the program's directory
The raw files must have the exact size (width*height*bitdepth/8) to be detected, and you also need to do this:
Settings -> Camera types -> 5248x3920 (may not be visible in the official version(?)) -> IXUS 160 -> "OK"
-
Got it, thanks. Will retry a build with 12 bit depth later this week.
Edit:
Got it to semi-work with 10bit pic (can't calibrate, gives too big percentages, don't know how you got these matrices :p)
12 bit is no go, says no camera profile even if the CRW + JPG are listed and camera prof is selected in options.
However in the calibrate window (now that I know where it is), I can see the raw is still corrupted, verified for the dvlptask hook AND old hook (before
" B loc_FF99AA50 \n"
and just after
"loc_FF99AA50:\n" )
-
12 bit is no go, says no camera profile even if the CRW + JPG are listed and camera prof is selected in options.
Did you fix the platform_camera.h values and re-shot a bunch of CRWs, or you're just using some old files? I got it to work by appending the appropriate number of zero bytes to the end of your short CRW.
However in the calibrate window (now that I know where it is), I can see the raw is still corrupted, verified for the dvlptask hook AND old hook (before
" B loc_FF99AA50 \n"
and just after
"loc_FF99AA50:\n" )
This is a problem then that needs some research... I'll try to do a comparison with an older firmware.
You could also help by inserting debug calls backwards from your current capt_seq raw hook and gather debug data by doing long (1 sec) exposures. This could help locating parts of the fw code which are pre- and post-exposure.
BTW, you may want to make separate posts for your progress, updating a one-liner after several days will hardly attract audience.
-
I've done a bit of exploration. It appears that parts of the capt_seq fw code have been rewritten (
asserts indicate a different source file edit: I was looking at the wrong place). I think that JPEG compression is now set up in capt_seq rather than in dvlpseq.
I'd like to know whether one of the following locations ("HERE") is reliably entered after a shot:
"loc_FF99AA14:\n"
" LDR R0, [R7, #0xAC] \n"
" CMP R0, #0 \n"
" MOV R0, R5 \n"
" BEQ loc_FF99AA2C \n"
" BL sub_FFAD80B0 \n"
/* HERE */
" B loc_FF99AA50 \n"
"loc_FF99AA2C:\n"
" BL sub_FFAD7C94_my \n" // --> Patched. Old value = 0xFFAD7C94.
/* HERE */
" B loc_FF99AA50 \n"If yes, the appropriate place for the raw hook(s) will be in sub_FFAD80B0 and/or sub_FFAD7C94 somewhere. Or, on a yet deeper level...
-
first here:
" BL sub_FFAD80B0 \n"
/* HERE */
does not work at all.
second one:
" BL sub_FFAD7C94_my \n" // --> Patched. Old value = 0xFFAD7C94.
/* HERE */
sometimes get triggered, sometimes not.
-
first here:
" BL sub_FFAD80B0 \n"
/* HERE */
does not work at all.
So much dead code...
second one:
" BL sub_FFAD7C94_my \n" // --> Patched. Old value = 0xFFAD7C94.
/* HERE */
sometimes get triggered, sometimes not.
My guess is that this depends on whether you wait for focus confirmation (before fully pressing the shutter) or not.
Does sub_FFAD7C94_my always get hit?
In this case, the rest of sub_FFAD7C94 will need to be researched for an appropriate location. At least that's my current guess.
I have to admit I don't like the direction this is going. We may easily end up needing half dozen raw hooks if certain settings/modes happen to use other code paths...
-
You're right, if I wait for focus it's always triggered, a direct full press bypasses it.
sub_FFAD7C94 always gets hit, and way earlier than the other locations. I will research some hooks later.
Just so that it's faster for me, the big lsowdown when enabling raw happens after shutter sound yes ?
-
Just so that it's faster for me, the big lsowdown when enabling raw happens after shutter sound yes ?
The shutter sound starts right before the shot.
edit:
I suggest you to start researching sub_FFAD7C94 from its end backwards.
-
Ran out of time for today. Putting the hook right before the last statement gives the same raw corruption (that is, at the top, bottom is okay). Will test further maybe sunday
-
Try one of the following locations (and check how reliably they are reached):
"loc_FFAD7E4C:\n"
" BL sub_FF99A620 \n"
" LDR R8, =0xFFAD7C10 \n"
" TST R5, #1 \n"
" BNE loc_FFAD7ECC \n"
/* first one */
" LDR R0, [R7, #0x100] \n"
" CMP R0, #0 \n"
" BNE loc_FFAD7E84 \n"
/* second one */
" MOV R0, R4 \n"
" BL sub_FF99C0E4 \n"
" TST R0, #1 \n"
" LDRNE R2, =0x1FD \n"
" LDRNE R1, =0xFFAD7F40 \n"
" MOVNE R0, #0 \n"
" BLNE sub_FF824DDC \n"
sub_FF99C0E4 is a function in SsCreateJpeg.c, I suspect it might be related to JPEG compression. sub_FF99A620 (aka sub_FF87F7B4) frees up a semaphore which might be called "CaptAndFileSem" from the source file it is related to.
The sx170 firmware sends a message to dvlpseqtask at the point where this fw calls sub_FF99C0E4.
-
Good news! The second place works correctly. I will post some raw files to generate a camera profile (can't get lower than ~30% on dng4ps2, don't know if I'm doing it properly)
Here are a pair of RAW+JPG: https://www.dropbox.com/s/znxmqb6tn51zsf5/raw.rar?dl=0 (https://www.dropbox.com/s/znxmqb6tn51zsf5/raw.rar?dl=0)
-
Good news! The second place works correctly.
Glad to hear that :)
I will post some raw files to generate a camera profile (can't get lower than ~30% on dng4ps2, don't know if I'm doing it properly)
You need to use a defocused photo. The monitor's pixels are visible on your photo, this will spoil the results. (Note that I'm not an expert, I've never done this kind of cam-profile-generation. Also, I don't think there's many CHDK cameras ports with calibrated color matrix, most are just copies.)
-
Unfocused one: https://www.dropbox.com/s/znxmqb6tn51zsf5/raw.rar?dl=0 (https://www.dropbox.com/s/znxmqb6tn51zsf5/raw.rar?dl=0)
Yeah I'll copy another camera's matrix for now. I now have to fix the filename numbering issue. Will debug more this week.
-
Hi adong.
I tried to use dng4ps2 from https://github.com/crass/dng4ps2, but it doesn't know anything about Ixus 160. Is there any changed version of dng4ps2 for Ixus 160 ?
-
You have to create the camera profile yourself using the calibration picture, as detailed in the wiki.
-
(can't get lower than ~30% on dng4ps2, don't know if I'm doing it properly)
You've made me curious: which version of dng4ps-2 is this? I think that calibration was removed from the UI before the source got released in 2008. Support for 12bit bit-depth was only added after that, so I'm not sure if it would even work. And, as you noted earlier, the 0.2.2 release simply crashes when fed with one of your RAW files.
-
(can't get lower than ~30% on dng4ps2, don't know if I'm doing it properly)
You've made me curious: which version of dng4ps-2 is this? I think that calibration was removed from the UI before the source got released in 2008. Support for 12bit bit-depth was only added after that, so I'm not sure if it would even work. And, as you noted earlier, the 0.2.2 release simply crashes when fed with one of your RAW files.
The calibration UI exists in 0.2.3 Beta build 286, but I was unable to get it to complete successfully on elph130
-
0.2.3 beta 26 (latest on google code) has the ui, it's just that it was renamed and moved. you can find it when you define a camera's parameters, under 'create color matrix' or something like that. I'll post a screenshot when I get home
-
The calibration UI exists in 0.2.3 Beta build 286
0.2.3 beta 26 (latest on google code) has the ui, it's just that it was renamed and moved.
:-[ Now I remember...
As for the failure: it could be that those sensors (1/2.3", 16...20MP) simply can't deliver noise-free images even at base ISO.
-
As for the failure: it could be that those sensors (1/2.3", 16...20MP) simply can't deliver noise-free images even at base ISO.
The other thing that occurred to me is that the distortion and vignette correction could have an impact. In this case, there might be some zoom settings that give better results.
-
Hi adong.
You have to create the camera profile yourself using the calibration picture, as detailed in the wiki.
I tried to do it in the dng4ps-2, but looks like I need to know some parameters for that:
Sensor size
Active zone x1,y1
Active zone x2,y2
Black-white levels
Mosaic type
-
As for the failure: it could be that those sensors (1/2.3", 16...20MP) simply can't deliver noise-free images even at base ISO.
The other thing that occurred to me is that the distortion and vignette correction could have an impact. In this case, there might be some zoom settings that give better results.
I did try to reduce distortion by zooming halfway, when fully zoomed out distortion is pretty heavy.
alex, the settings were posted by srsa a few posts ago.
-
alex, the settings were posted by srsa a few posts ago.
Oh, yes, sorry. I missed this message.
Patch for dcraw from author by photos from http://chdk.setepontos.com/index.php?topic=12321.msg122801#msg122801: (http://chdk.setepontos.com/index.php?topic=12321.msg122801#msg122801:)
--- dcraw.c 2015/05/25 02:29:14 1.476
+++ dcraw.c 2015/06/11 05:53:40
@@ -8228,6 +8228,7 @@
{ 19131120,4168,3060,92,16, 4, 1,40,0x94,0,2,"Canon","PowerShot SX220 HS" },
{ 21936096,4464,3276,25,10,73,12,40,0x16,0,2,"Canon","PowerShot SX30 IS" },
{ 24724224,4704,3504, 8,16,56, 8,40,0x94,0,2,"Canon","PowerShot A3300 IS" },
+ { 30858240,5248,3920, 8,16,56,16,40,0x94,0,2,"Canon","IXUS 160" },
{ 1976352,1632,1211, 0, 2, 0, 1, 0,0x94,0,1,"Casio","QV-2000UX" },
{ 3217760,2080,1547, 0, 0,10, 1, 0,0x94,0,1,"Casio","QV-3*00EX" },
{ 6218368,2585,1924, 0, 0, 9, 0, 0,0x94,0,1,"Casio","QV-5700" },
Dcraw homepage: https://www.cybercom.net/~dcoffin/dcraw/ (https://www.cybercom.net/~dcoffin/dcraw/)
Sources: https://www.cybercom.net/~dcoffin/dcraw/dcraw.c (https://www.cybercom.net/~dcoffin/dcraw/dcraw.c)
Command for build: gcc -o dcraw -O4 dcraw.c -lm -DNODEPS
-
Patch for dcraw
Before you attempt to submit this patch to the dcraw author note that the color matrix data shown on the screenshot is just an unadjusted copy from another random camera. It just happened to look not completely wrong... Hmmm, that patch doesn't even include most of that data :) Anyway, I leave this here.
-
Hmmm, that patch doesn't even include most of that data :)
Do you mean color profile or some other data ?
This patch just adds support of RAW files from Ixus 160 to dcraw. dcraw can calculate white balance and can produce not so bad results. There is instruction how to create color profile: see "Why does dcraw output have a green tint and weak color?" on the https://www.cybercom.net/~dcoffin/dcraw/. (https://www.cybercom.net/~dcoffin/dcraw/.)
I used dcraw many years. It looks better than dng4ps-2 since author support dcraw and it's very simple command line tool that can be statically linked.
-
Back to this issue.
With only 3 parameters it still crashed.
Looking at the asm and comparing to the ixus140, while the beginning of the function looks the same, the codepath to the sprintf is quite different.
For now I replaced the _GetImageFolder with some C code to test if it worked.
You get the assert because the function does not like what it gets as second argument.
You'll need CAM_FILE_COUNTER_IS_VAR in platform_camera.h and you'll need to find file_counter_var. See the ixus140 port porting thread (http://chdk.setepontos.com/index.php?topic=10617.msg104869#msg104869) for hints.
Do you mean color profile or some other data ?
I meant the color profile, I just wanted to emphasize that it's randomly chosen and very likely incorrect.
edit:
The address of file_counter_var is 0x6b4c. Can be found in routines above "FileBackupProperty.c".
-
Yeah found it too, just didn't have the time to build a firmware until today.
Filename is offset by one, I remember reyalp once had this issue but I can't remember which camera it was... I'll dig deeper into this, I do remember you fixed the issue by putting the hook later. Thing is, the next call is the CreateJpeg.c, don't know how to go further down.
Edit: forgot to say that PAUSE_FOR_FILE_COUNTER did not help
-
Filename is offset by one, I remember reyalp once had this issue but I can't remember which camera it was... I'll dig deeper into this, I do remember you fixed the issue by putting the hook later.
There's a fair chance that the JPEG filename/path is determined in the same routine (later) where you have the raw hook now. That would explain why waiting doesn't help.
However, if the offset is consistent (is it -1?), you can compensate for the offset in the port's shooting.c. Modify get_file_next_counter() and get_target_file_num(). get_file_next_counter() is only used locally, get_target_file_num() will be used for the raw file name.
-
updated github repo.
Yes the offset is always -1, I modified the two functions, although I don't know if I need to keep get_file_next_counter since get_target_file_num is using core/shooting.c's functions.
-
Hi All.
I bought Ixus 160 cameras. Be ready to more questions. ;)
First one is where should I get latest CHDK binaries for Ixus 160 ? I found ixus160_elph160-100a-1.4.0-0-full.zip at the http://chdk.setepontos.com/index.php?topic=12321.msg122817#msg122817, (http://chdk.setepontos.com/index.php?topic=12321.msg122817#msg122817,) but it doesn't contain PS.FI2. This file exist only in http://chdk.setepontos.com/index.php?topic=12321.msg122348#msg122348, (http://chdk.setepontos.com/index.php?topic=12321.msg122348#msg122348,) but this is 1.3 CHDK version and says "Update file error".
2adong: what about publishing binaries at the https://github.com/adongy/ixus160_elph160/releases (https://github.com/adongy/ixus160_elph160/releases) ?
-
Did not enable fi2 generation in the 1.4 branch, since I've never used it (diskboot.bin is waaay easier) so I didn't bother to reenable it.
please use stick to install chdk, less headaches that way (stick also has a page for builds that are not on the autobuild)
or you could wait for the port to make it into trunk, since it's not complete yet.
gh releases are a pain to do since I don't usually browse their website.
-
Did not enable fi2 generation in the 1.4 branch, since I've never used it (diskboot.bin is waaay easier) so I didn't bother to reenable it.
please use stick to install chdk, less headaches that way (stick also has a page for builds that are not on the autobuild)
Thank you, it works great.
I tried RAW, live preview, ptp extension, remote shoot.
gh releases are a pain to do since I don't usually browse their website.
Well, I created from your binaries: https://github.com/alex73/ixus160_elph160/releases
BTW, I rebased your changes on the chdk sources. You can see https://github.com/alex73/ixus160_elph160/tree/ixus160_elph160. Update to the latest chdk will be simple: git rebase trunk
Notes about my git:
1. I started from e7a3703961ba04e0588a0a459ac81d5ccf286675(Update to chdk 1.4) but not from "Initial commit" since previous commits were rebased on to /trunk
2. EOL chars converted to DOS in the some files, unix permission changed for some files
3. I leave doc/readme.txt but seems to it should be removed since all these info about Ixus 160 exist in the platform/ixus160_elph160/notes.txt
4. tools/*.bin removed since they are not exist in the origin CHDK code and have zero length
-
Yes the offset is always -1, I modified the two functions, although I don't know if I need to keep get_file_next_counter since get_target_file_num is using core/shooting.c's functions.
Note that counter reset or wraparound may break the -1 one assumption.
-
Note that counter reset or wraparound may break the -1 one assumption.
That's possible.
One could either research how the prediction works in those corner cases, or, one could try to move the raw hook further (I don't currently have a suggestion for a new location). The latter won't work if compression is started before the file counter is increased.
edit:
3rd possibility: reversing the firmware's "camera object" routines :P
-
4th possibility: deal with it. :D
I may fiddle with it some more, but for now I'm fixing zebra + edge overlay.
-
I may fiddle with it some more, but for now I'm fixing zebra + edge overlay.
Okay, no hurry.
I'd like to correct my earlier statement: sub_FF99C0E4 seems to assemble the new JPEG file name and schedule the file for writing. I'm fairly certain that the file counter is updated inside. ... somewhere ...
You may try to move the raw hook behind that call (right before loc_FFAD7E84), or, if that's too late, perhaps somewhere inside sub_FF99C0E4.
-
Okay thanks, I'll try that once I get back home.
-
Ixus 160 works good with CHDK, but there is one thing that I forget: 20MP camera requires about 4 seconds for write RAW to memory card.
I'm using Transcend 300x card(TS8GSDU1) that should support ~25MB/s write speed, but Benchmark reports 10958 Kb/s only for Write(RAW). Is there any sense to find 600x card, or Ixus hardware limits write speed to 10MB/s ? Are there any other ways how to make RAW shoot faster ? Probably, disable to create jpeg ? I found only one good way yet - to use remoteshoot for transfer RAW directly to computer.
-
Moving the raw hook right before loc_FFAD7E84 works.
-
Moving the raw hook right before loc_FFAD7E84 works.
Yah!
Ixus 160 works good with CHDK, but there is one thing that I forget: 20MP camera requires about 4 seconds for write RAW to memory card.
That sounds consistent with what I have experienced - roughly 2 seconds per 10Mb RAW image size (or 4 seconds for 20MB)
Are there any other ways how to make RAW shoot faster ?
The shooting is not the problem - it's the writing to the SD card that is "slow".
Probably, disable to create jpeg ?
We don't know how to do that.
I found only one good way yet - to use remoteshoot for transfer RAW directly to computer.
That does not save the 20MB of data to the SD card so of course it's faster.
-
Probably, disable to create jpeg ?
We don't know how to do that.
I found only one good way yet - to use remoteshoot for transfer RAW directly to computer.
That does not save the 20MB of data to the SD card so of course it's faster.
I wouldn't particularly expect the camera USB interface to be faster than the SD.
Remote shoot does indeed disable jpeg, and this could conceivably made an option outside of remoteshoot. However, this only skips saving the file, not all the processing. Since camera jpegs are typically only a few MB, this is unlikely to be a big win, and would remove the ability to preview. You could always switch to 640x480 jpegs to get negligrable write time.
-
I wouldn't particularly expect the camera USB interface to be faster than the SD.
Yet that's what alex73 reported.
Remote shoot does indeed disable jpeg, and this could conceivably made an option outside of remoteshoot. However, this only skips saving the file, not all the processing. Since camera jpegs are typically only a few MB, this is unlikely to be a big win, and would remove the ability to preview. You could always switch to 640x480 jpegs to get negligrable write time.
I suppose it would then be easy to add a Save JPG [ * ] menu item to the RAW menu?
-
I suppose it would then be easy to add a Save JPG [ * ] menu item to the RAW menu?
It shouldn't be super hard, but I'd want to see some measurable benefit first. The write time for a minimum size and/or quality jpeg should be minimal, and using that you get a review image and avoid other various weirdness with the filewrite hook.
If we could stop the camera from doing the jpeg processing at all, that might provide more gain, but it would involve new platform specific code and reverse engineering.
-
Hi reyalp.
If we could stop the camera from doing the jpeg processing at all, that might provide more gain, but it would involve new platform specific code and reverse engineering.
I agree that there is no sense to disable jpeg processing for shooting because transfer time is enough small for 640x480. And looks like remote shooting will be good solution for me. 640x480(or 2048x1536) is good for preview. Remote shooting is faster because USB speed is 20MB/s instead 10MB/s for card writing.
But just for understand process better: usually(without RAW saving) Ixus 160 able to shoot 0.8 photos per second(by Canon specification). But "shoot" process is very fast - 1/60 of seconds. What is happen for 1 second after that ? As far as I understand, it's conversion to JPEG. In this case, if we use JPEG+RAW, time for full process is just a sum from JPEG process and RAW saving. If JPEG+RAW requires 4 seconds for save, will this time be 3 seconds in case to disable JPEG ?
-
Remote shooting is faster because USB speed is 20MB/s instead 10MB/s for card writing.
10MB/s seems a bit slow for a modern cam. On elph140 using a class 10 wintec card, the first benchmark run after boot seems to be ~10MB/s but after that it's 14-20. We have previously noticed that the first shot after startup tends to be slow too.
But just for understand process better: usually(without RAW saving) Ixus 160 able to shoot 0.8 photos per second(by Canon specification). But "shoot" process is very fast - 1/60 of seconds. What is happen for 1 second after that ? As far as I understand, it's conversion to JPEG.
I would guess so, although it's more than just converting to JPEG, there's a lot of other image processing applied for noise reduction, lens distortion etc.
Just reading out the full sensor data may also take a noticeable amount of time. On D10, it looks like the time between usb remote hook (which should be shortly before the shutter actually opens) and the raw hook (which should be before most jpeg processing starts) is ~500 ms, excluding the exposure time.
-
Moving the raw hook right before loc_FFAD7E84 works.
Does that mean the counter is updated at that point _and_ the DNG is not getting corrupted?
Just reading out the full sensor data may also take a noticeable amount of time. On D10, it looks like the time between usb remote hook (which should be shortly before the shutter actually opens) and the raw hook (which should be before most jpeg processing starts) is ~500 ms, excluding the exposure time.
That means, in theory, we could start the RAW/DNG creation process a bit earlier (although it could turn out to be very problematic - dark frame, RAW data post-manipulation, etc. And, of course, CMOS cameras have much faster readout).
-
Moving the raw hook right before loc_FFAD7E84 works.
Does that mean the counter is updated at that point _and_ the DNG is not getting corrupted?
yes
-
There's yet another thing I'm curious about: can you benchmark the camera?
Use this (https://www.assembla.com/code/chdk-s1/subversion-11/nodes/15/trunk/modules/gui_bench.c) version of modules/gui_bench.c as it can do more than the current one.
Start the benchmark (misc. stuff -> tools -> benchmark) in playback mode. Use the left/right key to enable/disable logging. Use the SET button to start the complete benchmark, you can also start the measurement with a half-shoot which jumps over the card benchmarks. This version of the module runs the measurement routines in the context of spytask, that means the results vary more due to this task's lower priority.
Needless to say, you don't need to do this right away.
-
Does that mean the counter is updated at that point _and_ the DNG is not getting corrupted?
yes
It's a good idea to check if the counter updated consistently if you use continuous mode or a "hold half shoot, click full shoot" script like http://chdk.wikia.com/wiki/HDR_Fast_Shooter (http://chdk.wikia.com/wiki/HDR_Fast_Shooter)
-
There's yet another thing I'm curious about: can you benchmark the camera?
Use this (https://www.assembla.com/code/chdk-s1/subversion-11/nodes/15/trunk/modules/gui_bench.c) version of modules/gui_bench.c as it can do more than the current one.
Start the benchmark (misc. stuff -> tools -> benchmark) in playback mode. Use the left/right key to enable/disable logging. Use the SET button to start the complete benchmark, you can also start the measurement with a half-shoot which jumps over the card benchmarks. This version of the module runs the measurement routines in the context of spytask, that means the results vary more due to this task's lower priority.
Needless to say, you don't need to do this right away.
attached the bench results.
3 first times are done back to back (to see if there's some warm up)
last one is right after boot
Does that mean the counter is updated at that point _and_ the DNG is not getting corrupted?
yes
It's a good idea to check if the counter updated consistently if you use continuous mode or a "hold half shoot, click full shoot" script like http://chdk.wikia.com/wiki/HDR_Fast_Shooter (http://chdk.wikia.com/wiki/HDR_Fast_Shooter)
did continuous mode for 5 shots, seemed okay, the script worked too. (5 shots too)
did not try for long runs, if you want me to do so please ask.
-
did continuous mode for 5 shots, seemed okay, the script worked too. (5 shots too)
Did you have raw / dng enabled? If there is a problem with the counter, you will get less raws than jpegs (because some will have the same number and overwrite the previous one)
You can do the same test in continuous mode without a script, just hold enable raw, shoot a burst and make sure there's a matching raw for each jpeg.
Both cases should be tested, since they are likely different code paths in the canon firmware.
-
I did enable raw, and there was a corresponding .crw for each .jpg in both cases.
-
attached the bench results.
3 first times are done back to back (to see if there's some warm up)
last one is right after boot
Thanks. The ARM core is running at 84MHz (same as my fastest DIGIC4 cam). For some reason, reading of bytes from uncached memory ("Viewport read") is way faster than on any of my cameras (I know that the benchmark routines are not ideal, but it's still interesting).
You can compare text drawing speed once you implement DRAW_ON_ACTIVE_BITMAP_BUFFER_ONLY.
-
I will have less time to work on this in the coming weeks, so if anyone wants to dev on it, go ahead. I'll /try/ to put the updated sources on github, but the latest change is just moving the raw hook further down (use << label in codegen to put before the label).
-
Implemented DRAW ON ACTIVE BUFFER ONLY, here are the benchs (3 first back to back, last one after boot)
Edit: pushed to github.
With this, most of the issues should be fixed, unless I missed something, and the port is imho ready.
-
Hi.
I found my own bug for Ixus 160 ;)
"set_zoom()" doesn't work: libusb reports I/O error or "disconnected"(on the same place - just different execution of the same code). Camera switched off without lens closing. So, it looks like CHDK build issue. Behavior is 100% the same in the chdkptp(command line) and my code. I tried to call "set_zoom_speed" - the same issue.
I checked the same code in my A495 - it works good.
You can see wireshark usb logs for Ixus 160 in attachment.
-
Hi.
I found my own bug for Ixus 160 ;)
"set_zoom()" doesn't work: libusb reports I/O error or "disconnected"(on the same place - just different execution of the same code). Camera switched off without lens closing.
This means the camera crashed. Try to get a ROMLOG: http://chdk.wikia.com/wiki/Debugging#Camera_crash_logs_.28romlog.29 (http://chdk.wikia.com/wiki/Debugging#Camera_crash_logs_.28romlog.29)
I tried to call "set_zoom_speed" - the same issue.
AFAIK set_zoom_speed isn't expected to do anything except on a few old cameras.
-
Added missing defines, should be fixed.
-
I think it would be beneficial for this port to receive some independent evaluation and testing (in order to find possible bugs).
A list of tests is available here: http://chdk.wikia.com/wiki/Testing (http://chdk.wikia.com/wiki/Testing)
Additionally, could someone check whether JPEGs look OK after zooming from wide angle to tele with set_zoom()?
-
Added missing defines, should be fixed.
Thank you, it works good. Jpeg also looks good after zooming.
WIll make tests by http://chdk.wikia.com/wiki/Testing (http://chdk.wikia.com/wiki/Testing) today later.
-
Jpeg also looks good after zooming.
I should have explained this a bit better, look for inappropriate distortion correction (see this (http://chdk.setepontos.com/index.php?topic=10626.msg115862#msg115862) post for an example).
-
Hi.
I should have explained this a bit better, look for inappropriate distortion correction (see this (http://chdk.setepontos.com/index.php?topic=10626.msg115862#msg115862) post for an example).
There is no such issue. See attached jpegs for different zoom levels. I just converted they by ImageMagick for less jpeg quality for decrease size.
-
I made all tests by http://chdk.wikia.com/wiki/Testing (http://chdk.wikia.com/wiki/Testing) and runned some other test scripts from camera. Almost all tests passed good, except some issues described below. Probably they are not real issue.
1. drawTest - some figures looks not so good
2. drtest - shoots without stop
3. isobase - reports "set CAM_MARKET_ISO_BASE 200"
4. mftest - reports error at mftest.lua:150 - attempt to compare nil with number
5. tstcallf - failed
-
Hi.
I'm trying to call "return call_event_proc("PTM_GetCurrentItem",ID)" scripts for ID=0x8000..8200, but it returns always -1
When I tried to call "return call_func_ptr(0xff8a1464,ID)" it returns some values, but camera crashed on the ID=0x80c6.
Is it possible to get/set UI properties(http://chdk.setepontos.com/index.php?topic=10624.0 (http://chdk.setepontos.com/index.php?topic=10624.0)) for Ixus 160 ?
-
I'm trying to call "return call_event_proc("PTM_GetCurrentItem",ID)" scripts for ID=0x8000..8200, but it returns always -1
When an eventproc returns -1, it usually means that it is not registered. Execute UI.CreatePublic prior to calling the PTM event procedures.
When I tried to call "return call_func_ptr(0xff8a1464,ID)" it returns some values, but camera crashed on the ID=0x80c6.
The number of these UI properties is detected by the sigfinder, see stubs_entry.S:
DEF_CONST(uiprop_count ,0x000000c6) // Found @0xff9aeac4Requests for nonexistent properties are usually rewarded with an assert.
I can't give an answer to all those test failures at the moment, but here's a few3. isobase - reports "set CAM_MARKET_ISO_BASE 200"
CAM_MARKET_ISO_BASE needs to be redefined in platform_camera.h
4. mftest - reports error at mftest.lua:150 - attempt to compare nil with number
This might have to do with the version control (svn is expected)?
edit:
How much free memory does CHDK report (miscellaneous stuff -> show memory info)?
-
Execute UI.CreatePublic prior to calling the PTM event procedures.
Thank you, works good.
Why not to create standard Lua functions for UI properties, like http://chdk.wikia.com/wiki/CHDK_Scripting_Cross_Reference_Page (http://chdk.wikia.com/wiki/CHDK_Scripting_Cross_Reference_Page) ?
4. mftest - reports error at mftest.lua:150 - attempt to compare nil with number
This might have to do with the version control (svn is expected)?
Probably. I'm using build from adong, and he builds from own git.
How much free memory does CHDK report (miscellaneous stuff -> show memory info)?
Just after switch on: 3121736, CHDK size: 141408 bytes, loaded at: 0x185CB0
After some shoots: 2990320
After next shoots: still 2990320
-
UI properties for Ixus 160: http://chdk.setepontos.com/index.php?topic=10624.msg123226#msg123226 (http://chdk.setepontos.com/index.php?topic=10624.msg123226#msg123226)
-
Hi guys,
I'm looking for a camera to work with CHDK for aerial mapping. I wanted to know if this model (IXUS 160) would work with the porting you are discussing here.
Juan
-
I'm looking for a camera to work with CHDK for aerial mapping. I wanted to know if this model (IXUS 160) would work with the porting you are discussing here.
In my opinion: if you need faster shoot rate, this cam is not for you. The official spec is 0.8 shot/sec for continuous shooting, the practical rate will be even slower.
-
Hy guys,
This is a major milestone for drone aerial photography, as IXUS160/ELPH160 is the first 20MP light weight camera (127g) with CHDK. There are quite a lot of people waiting for this CHDK.
Congrats to you who make these developments work! :)
-
Hi all, awesome work for CHDK! I just bought 2 of the ixus160 and I would like to help. I can test, but can also help with coding or scripting. It is my first project for a camera, but have some experience in other fields.
So how far is this port at this time? Where can I start?
-
Hi.
So how far is this port at this time? Where can I start?
See attachment in the http://chdk.setepontos.com/index.php?topic=12321.msg123174#msg123174 (http://chdk.setepontos.com/index.php?topic=12321.msg123174#msg123174) message, and use http://zenoshrdlu.com/stick/stick.html (http://zenoshrdlu.com/stick/stick.html) for write firmware to SD card.
-
Thanks to diybookscanner group, now I have access to this camera :)
Based on adong port, I'm testing and preparing the patch to trunk. When I try to compile it. I got this error:
stubs_entry.S:57: Error: bad instruction `def_const(uiprop_count ,0x000000c6)'
If uiprop is defined in stubs_min.S, the port compiles. Any ideas?
I found the same problem trying to port ixus145. Thanks.
-
Thanks to diybookscanner group, now I have access to this camera :)
Based on adong port, I'm testing and preparing the patch to trunk. When I try to compile it. I got this error:
stubs_entry.S:57: Error: bad instruction `def_const(uiprop_count ,0x000000c6)'
If uiprop is defined in stubs_min.S, the port compiles. Any ideas?
I found the same problem trying to port ixus145. Thanks.
If it's defined as 'def_const' (lowercase) in stubs_entry.S it will fail - the macro name is 'DEF_CONST' (uppercase).
Phil.
-
Hmm I'm pretty sure it's in caps in the source, so maybe you didn't download it properly ?
Anyway, I'll try to find some time this weekend to enable the video button and I'll call it a day for this port :)
-
Hi all!
I have an IXUS 170, and I was wondering if any of your fine work would be adaptable for that camera? I've opened a new thread for this effort (http://chdk.setepontos.com/index.php?topic=12471), and welcome any pointers on how to get started.
-
Hmm I'm pretty sure it's in caps in the source, so maybe you didn't download it properly ?
Yes, your source was right. I found a bug in my working copy. Now it compiles without problem.
-
Hi all,
I am new to CHDK so I might be doing something wrong.
I got CHDK running, but had to use 2 partions as the IXUS does not want to boot from fat32. However, it doesn't recognize the two partitions. I am testing this on the ixus160 under Linux with a 16GB SDcard (lexar class 10).
Here are the steps so far:
0. Stick did not work on my system (did not properly recognize the SDcard), so I had to resort to licks.
1. I first tried a single fat32 partition. The camera did not want to boot from a fat32 partition, so I had to create 2 partitions, one fat16 and one fat32.
2. Licks made a 16MB fat16 partition, with DISKBOOT.bin on it and it put the CHDK dir on the large fat32 partition
3. After booting the camera, it complained of a missing module.
4. After I copied the CHDK dir to the first partition it works,
Errors so far:
5. When I browse the CHDK menu, it is constantly drawn over by the image the camera is currently aimed at.
6. When I just boot up the camera, and start shooting, it puts the images on the small boot partition and not on the bigger data partition.
Any help?
-
Cameras that do not need to use dual partitions (i.e newer ones) typically do not have support for them. You need to figure out why you are not able to boot from a FAT32 partition
http://chdk.wikia.com/wiki/EOScard might help?
The screen overwrite problem you see is normal for most CHDK ports. It tends to be less of a problem in playback mode. Turning off focus or face tracking also helps.
-
Because of the dual partition the disk became full quite quickly. When that happened the camera flashed a message and crashed. The crash caused the lens to extend to far and it developed the infamous canon lens error... I was lucky in fixing that, but a second attempt to boot chdk bricked it completely...
So there is possibly an error in the code when there is no space left on the card...
-
Because of the dual partition the disk became full quite quickly.
As waterwingz mentioned, new ports no longer support dual partitions.
You mentioned Licks, so I assume you're on Linux. If all utilities fail, you can make a card bootable manually, see the Linux section(s) here: http://chdk.wikia.com/wiki/Prepare_your_SD_card (http://chdk.wikia.com/wiki/Prepare_your_SD_card)
So there is possibly an error in the code when there is no space left on the card...
I think I have encountered issues when the card is almost full and CHDK RAW is enabled: in this case, the Canon firmware may encounter an unexpected out-of-space situation which triggers a Canon error. That may have been the crash you were experiencing.
I assume that the crash itself did not cause the lens to move.
When you tried re-starting the cam afterwards, the camera tried to retract the lens, but it failed.
I was lucky in fixing that, but a second attempt to boot chdk bricked it completely...
Can you detail what happened at that second attempt and what does the "completely" bricked camera do since then?
-
@adong or anybody else with the camera
I have a few requests and suggestions.
- Can somebody test the camera in playback mode with chdkptp? Do you get the same image as the one on the LCD?
- Please run the hooktest (https://subversion.assembla.com/svn/chdk/trunk/CHDK/SCRIPTS/TEST/hooktest.lua) script in P mode and in "Digital IS" mode. The script's description is here (http://chdk.wikia.com/wiki/Testing#hooktest.lua).
If you get bad display in the chdkptp test, try replacing
// guessed from sub_FF84E884
DEF(viewport_fb_d, 0x00003314)
with
// 0xff883c54 (0x32d4), 0xff883c90 (0x54); see ixus140 0xff0a7858, 0xff0a7890
DEF(viewport_fb_d, 0x00003328)in stubs_min.S .
I think 0x3314 is an eventflag (0x32d4 + 0x40, see the code right before 0xff883074).
-
Your suggestion fixed playback mode with chdkptp. Thanks.
hooktest script fails. Log files in attachments.
Additionally, there is a bug with power up mode detection, camera always start up on REC mode.
EDIT: Source code committed to SVN to facilitate further development (trunk r4197 (https://www.assembla.com/spaces/chdk/subversion/commits/4197)) but it is not included in autobuild.
-
hooktest script fails. Log files in attachments.
P mode looks OK, exp counter started at 3, reset to 1 at first shot. All other tests passed.
Digital IS looks like raw hook is not being called. shoot() shoots twice, raw hook always times out. remote hook is also not called.
-
Additionally, there is a bug with power up mode detection, camera always start up on REC mode.
See this (http://chdk.setepontos.com/index.php?topic=12321.msg121619#msg121619). So, maybe the following could work?
*(int*)(0x2A04 + 4) = (*(int*)0xC022F484)&0x20000 ? 0x400000 : 0x200000;
Digital IS looks like raw hook is not being called. shoot() shoots twice, raw hook always times out. remote hook is also not called.
That's what I was expecting. I think the digital IS code path is in the firmware's SsGISCaptureSeq.c routines, likely in sub_FFAD80B0 (http://chdk.setepontos.com/index.php?topic=12321.msg122695#msg122695).
On the other hand, digital IS mode operates the sensor in quarter resolution (probably binned) mode, so RAW would not work with current CHDK. The mode also shoots continuously while the shutter is held down and outputs a single averaged JPEG at the end.
For now, it's probably better to leave it as it is.
-
On the other hand, digital IS mode operates the sensor in quarter resolution (probably binned) mode, so RAW would not work with current CHDK. The mode also shoots continuously while the shutter is held down and outputs a single averaged JPEG at the end.
For now, it's probably better to leave it as it is.
Note that it's not just raw and shoot hooks that break if the hook isn't called the, the shoot() function is also broken because it doesn't detect that the shot was taken.
There should probably be a CAM_DISABLE_RAW_IN_DIGITAL_IS if usable raw data is not available. It wouldn't hurt to set this if the hook isn't called at all, although it doesn't fix the problem.
Someone should also check whether valid raw is captured in auto and low light modes, and define the appropriate CAM_DISABLE_RAW_IN_* defines if not.
-
@adong or anybody else with the camera
I have a few requests and suggestions.
- Can somebody test the camera in playback mode with chdkptp? Do you get the same image as the one on the LCD?
- Please run the hooktest (https://subversion.assembla.com/svn/chdk/trunk/CHDK/SCRIPTS/TEST/hooktest.lua) script in P mode and in "Digital IS" mode. The script's description is here (http://chdk.wikia.com/wiki/Testing#hooktest.lua).
If you get bad display in the chdkptp test, try replacing
// guessed from sub_FF84E884
DEF(viewport_fb_d, 0x00003314)
with
// 0xff883c54 (0x32d4), 0xff883c90 (0x54); see ixus140 0xff0a7858, 0xff0a7890
DEF(viewport_fb_d, 0x00003328)in stubs_min.S .
I think 0x3314 is an eventflag (0x32d4 + 0x40, see the code right before 0xff883074).
You beat me to it, noticed this morning when trying to port ixus170 that it was not working haha
I also tested the power on fix and it works, sorry for not understanding the first time :(
@nafraf: thanks for including it in trunk!
-
Because of the dual partition the disk became full quite quickly.
As waterwingz mentioned, new ports no longer support dual partitions.
Yes, the crash happened after I posted the first question, but before waterwingz answered...
You mentioned Licks, so I assume you're on Linux. If all utilities fail, you can make a card bootable manually, see the Linux section(s) here: http://chdk.wikia.com/wiki/Prepare_your_SD_card (http://chdk.wikia.com/wiki/Prepare_your_SD_card)
Thx, that will help.
So there is possibly an error in the code when there is no space left on the card...
I think I have encountered issues when the card is almost full and CHDK RAW is enabled: in this case, the Canon firmware may encounter an unexpected out-of-space situation which triggers a Canon error. That may have been the crash you were experiencing.
It was trying to write raw indeed. But the error message was flashed in chdk.
I assume that the crash itself did not cause the lens to move.
When you tried re-starting the cam afterwards, the camera tried to retract the lens, but it failed.
Actually in the crash itself, the camera extended the lens to far to a point it couldn't retract. I tried rebooting normally a couple of times, but it kept giving the lens error and not retracting. I left it on its back overnight. Next morning I retried and it retracted normally! As my washing machine was on and it vibrates the floor a lot, it might have shaken the lens motor back or such. Or I just got lucky...
I was lucky in fixing that, but a second attempt to boot chdk bricked it completely...
can you detail what happened at that second attempt and what does the "completely" bricked camera do since then?
I recreated the sd card with again the two partitions (did not know yet it couldn't work), and tried my second camera. That again crashed in raw mode, same thing, but now the camera went dead, as in permanently shut off.
When the disk became full, the crash might have overwritten the system firmware in memory. It should not happen, but I can't explain otherwise why both cameras broke in such a way. (I did return the dead one and Canon sent me another). The other seems fine so far, going to try to create fat32 image now.
-
Where can i find the latest chdk for ixus160? I previously used the built in the post (in the http://chdk.setepontos.com/index.php?topic=12321.msg123174#msg123174 (http://chdk.setepontos.com/index.php?topic=12321.msg123174#msg123174) message), but is there a newer better built available?
And will chdkptp work out of the box with this build?
-
Actually in the crash itself, the camera extended the lens to far to a point it couldn't retract.
That's rather nasty and I can't really explain it... Something may have corrupted the RAM. Which would also "explain" that:
I recreated the sd card with again the two partitions (did not know yet it couldn't work), and tried my second camera. That again crashed in raw mode, same thing, but now the camera went dead, as in permanently shut off.
the crash might have overwritten the system firmware in memory.
CHDK doesn't have routines that write the flash, but the Canon firmware does write into the flash when shutting down. If the RAM was badly corrupted then it might be possible that unintended parts of the flash memory were overwritten.
Anyway, 2 bricks out of two seems more than just coincidence.
I tried the scenario on one of my cameras (enabled DNG on a card with 2 MB free space). CHDK used up all space on the card, and the camera could not save the JPEG. It did not shut down, it displayed "memory card error" instead.
You also mentioned a CHDK error message: we don't have much of those and I don't think you'd be seeing one of them in a scenario like this.
@adong
Can you please remove the test release binaries?
General note:
I think we should disable RAW/DNG when there's not enough space on card...
-
I actually had about 22 MB left on the card and the problem occured when writing the Dng after it wrote the/a jpg. I am actually not sure about the message being from chdk, so it could be that canon reported the card full, but chdk tried to continue writing.
I have tried the same built successfully now on a fat32, thx for the link, I just used fdisk and echo to create the bootable disk. Now it seems to work ok.
As I started this in the hope of doing a bookscanner: where can I find the most current built and will it work with chdkptp?
-
I actually had about 22 MB left on the card and the problem occured when writing the Dng after it wrote the/a jpg. I am actually not sure about the message being from chdk, so it could be that canon reported the card full, but chdk tried to continue writing.
I have tried the same built successfully now on a fat32, thx for the link, I just used fdisk and echo to create the bootable disk. Now it seems to work ok.
Added this to http://chdk.wikia.com/wiki/Camera_failures_suspected_to_be_caused_by_CHDK (http://chdk.wikia.com/wiki/Camera_failures_suspected_to_be_caused_by_CHDK)
When you say
I recreated the sd card with again the two partitions (did not know yet it couldn't work), and tried my second camera. That again crashed in raw mode, same thing, but now the camera went dead, as in permanently shut off.
Do you mean the camera shows the same symptoms as the first one (lens error?) Or does it simply not power on at all? In the latter case, I assume you've tried removing the battery and/or external power supply.
Another question, do you have any idea what shooting mode the cameras were in? (Auto, P, some scene mode...?)
As I started this in the hope of doing a bookscanner: where can I find the most current built and will it work with chdkptp?
Given the apparent destruction of two cameras, publicly distributing builds may not be a good idea. However, since you don't seem afraid I'll pm you a link for trunk r4201. I don't know how much this differs from the previously posted builds. No ixus160 specific code has been changed since nafrafs original checkin.
My impression is that chdkptp functionality should be generally working.
-
I removed all links to my builds.
-
I removed all links to my builds.
Thanks. We'll need to figure out whether this issue is a porting problem, or it's caused by something like a stack overflow. To be honest, the code_gen'd code looks okay to me, so I'd rather think that
- one of the fw addresses we use is wrong and/or
- Canon has changed one of the fw functions we're relying on and/or
- we're overusing stack somewhere
...
@nafraf
If you have time, can you check the power-up fix (http://chdk.setepontos.com/index.php?topic=12321.msg123724#msg123724), and if it's working, commit it?
-
To be honest, the code_gen'd code looks okay to me, so I'd rather think that
- one of the fw addresses we use is wrong and/or
- Canon has changed one of the fw functions we're relying on and/or
- we're overusing stack somewhere
...
The reason I asked about shooting mode above:
If you shoot DNG when you don't have a valid raw buffer (e.g. auto mode on new cams), a huge chunk of memory gets reversed. We know the same address range use for raw gets used for other stuff (like live view) when it's not used for raw.
-
@nafraf
If you have time, can you check the power-up fix (http://chdk.setepontos.com/index.php?topic=12321.msg123724#msg123724), and if it's working, commit it?
Committed to trunk r4202 (https://www.assembla.com/spaces/chdk/subversion/commits/4202). Thanks
-
Someone should also check whether valid raw is captured in auto and low light modes, and define the appropriate CAM_DISABLE_RAW_IN_* defines if not.
Tested and included in r4205 (https://www.assembla.com/spaces/chdk/subversion/commits/4205).
RAW works in AUTO but there are problems in low light mode.
-
HI，have the 160 port been added in the latest CHDK trunk？
-
HI，have the 160 port been added in the latest CHDK trunk？
CHDK source code is maintained on an svn site and is organized into a "development" and a "stable" branch.
More details on that can be found here : CHDK Wiki : Release Strategy (http://chdk.wikia.com/wiki/Release_Strategy)
The current code for the ixus160_elph160 is available in the "development" branch. As you seem to be struggling with building your own version, I've built the most recent code and attached it here.
HTH
EDIT : See the comment below from reyalp : "Should be noted that the previous builds were removed due the apparent destruction of two cameras (http://chdk.setepontos.com/index.php?topic=12321.msg123736#msg123736). As always, any use of CHDK is at your own risk." It was actually only one camera that ended up dead but it could easily have been two based on what was reported. So I've deleted the attachment from this post If anyone wants to try this despite the warning, please feel free to PM me.
-
HI，have the 160 port been added in the latest CHDK trunk？
CHDK source code is maintained on an svn site and is organized into a "development" and a "stable" branch.
More details on that can be found here : CHDK Wiki : Release Strategy (http://chdk.wikia.com/wiki/Release_Strategy)
The current code for the ixus160_elph160 is available in the "development" branch. As you seem to be struggling with building your own version, I've built the most recent code and attached it here.
HTH
@waterwingz
Thank you so much! I just need the latest CHDK build for IUXS160, because I couldnt find it in the newest trunk using CHDK SHELL. Sorry for bothring!
-
can any one tell me , when chdk software will be ready for public use?
-
Does this work on the IXUS 165 ?
-
Does this work on the IXUS 165 ?
The Ixus 160 does not have optical IS, the 165 does. From my experience, that means their firmware is different, therefore the Ixus 165 needs a separate port.
Read the following FAQ entry: My camera isn't ported yet (http://chdk.wikia.com/wiki/FAQ#Q._My_camera_isn.27t_ported_yet._Is_a_port_planned.C2.A0.3F_When_will_it_be_ready.C2.A0.3F_How_can_I_help.C2.A0.3F).
-
@waterwingz
Thank you so much! I just need the latest CHDK build for IUXS160, because I couldnt find it in the newest trunk using CHDK SHELL. Sorry for bothring!
Should be noted that the previous builds were removed due the apparent destruction of two cameras (http://chdk.setepontos.com/index.php?topic=12321.msg123736#msg123736).
As always, any use of CHDK is at your own risk.
It's not clear if this is actually resolved. If it was due to the issues with the small partition getting filled, it is, but it's very hard to be sure without destroying more cameras.
-
Hi. I own an ELPH160 camera that I am willing to risk for the cause. What steps would I take using the latest build to check to reproduce the problem, possibly brick my camera, and see whether or not the bug is indeed fixed?
-
Hi. I own an ELPH160 camera that I am willing to risk for the cause. What steps would I take using the latest build to check to reproduce the problem, possibly brick my camera, and see whether or not the bug is indeed fixed?
I'll PM you a build, but unfortunately, there isn't a simple answer.
The problem happened when Scannerall tried to shoot using an SD card that had been partitioned so with very little free space (old cameras required partitioning to boot on a large card, but this is not needed for this cam): http://chdk.setepontos.com/index.php?topic=12321.150 (http://chdk.setepontos.com/index.php?topic=12321.150)
So one theory is that the problem was somehow triggered by the SD card filling up between when the shot started and when the camera tried to save the jpeg. This isn't totally impossible, but it seems strange. A full disk would not normally be expected to affect lens hardware.
The current CHDK trunk (including the build I sent you) will prevent saving raw if there isn't enough space, so if that was the problem, it's solved. However, shooting with a full card and not bricking the camera doesn't really tell us if the problem was solved, because we don't know if that was the real cause.
A more reliable way to test this theory would be to make a build without the low space protection, verify that it works on a card with plenty of space, and then see if it bricks the camera when using a tiny partition. If it does, that would pretty much be case closed. If it doesn't, the result would be inconclusive, because even if the low space caused the problem, it's not safe to assume it would trigger it every time.
At this point, the best we can do may be have those willing to take the risk keep using it, and see if the problem happens again.
-
Can somebody with the camera try
- ND filter override
- subject distance override
?
For SD override, you'll need
#define CAM_SD_OVER_IN_AF 1
#define CAM_SD_OVER_IN_AFL 1
#define CAM_SD_OVER_IN_MF 1in platform_camera.h
For the ND, you need
#undef CAM_HAS_IRIS_DIAPHRAGM
#define CAM_HAS_ND_FILTER 1Expected outcome: crash, so be careful. I'm considering a new thread to discuss the root cause...
Here (http://chdk.setepontos.com/index.php?topic=12516.msg124116#msg124116)'s information about the cause.
-
Yes, camera crashes. If it helps, ROMLOG in attachment.
-
Yes, camera crashes. If it helps, ROMLOG in attachment.
Thanks for confirming.
I have written a howto, but it will quickly become obsolete because this workaround is not ideal (http://chdk.setepontos.com/index.php?topic=12516.msg124133#msg124133). If you choose to commit it, please put notes in that this is a temporary measure.
It's possible that other CHDK operations are also affected by the change detailed in the linked thread.
Trace back the parameter passed to ClearEventFlag in the following event procedures (note I'm using names provided by sigfinder):
MoveFocusLensToDistance_FW
PutInNdFilter_FW
Then find the two functions that initialize them, they are called from InitializeAdjustmentFunction (you have to look in the function called from InitializeAdjustmentFunction, actually).
Trace back the parameter passed to TakeSemaphore in the following event procedure:
TurnOnNdFilter_FW
Then find the function that initializes it, it is called from Mecha.Create .
Note that the sigfinder will use TurnOnNdFilter if both TurnOnNdFilter and PutInNdFilter are available. If this is the case, the ND filter eventflag doesn't need to be initialized.
For ixus160 100a:
sub_ffad6344: ND semaphore init (also registers some event procedures)
sub_ffaa8558: ND eventflag init (not needed, because the other ND funtions are used)
sub_ffb7ebfc: focus eventflag init
You can call the above 2 required functions right after taskcreatePhySw_my in boot.c (that's just a suggestion).
This will fix:
- ND override
- subject distance override
- set_zoom (this one is only affected because CHDK attempts re-focusing after adjusting zoom)
-
Using the functions you found, I modified platform/generic/wrappers.c, patch in attachment.
set_focus() and set_nd_filter() were tested using chdkptp and they are working.
-
Using the functions you found, I modified platform/generic/wrappers.c, patch in attachment.
set_focus() and set_nd_filter() were tested using chdkptp and they are working.
Couldn't get your patch to apply cleanly. Updated version that I think is correct attached.
-
Thanks for fixing the patch. I'm not sure if that's the right choice, It is only for documentation purposes, it depends on changes on platform/ixus160_elph160 changes which has not been included.
EDIT: fix typo :)
-
Thanks for fixing the path. I'm not sure if that's the right choice, It is only for documentation purposes, it depends on changes on platform/ixus160_elph160 changes which has not been included.
It wasn't the path. There was an extra patch segment at the end of your file that made no sense. So I removed it.
Edit : oh .. wait. You meant "Thanks for fixing the patch"? Never mind then ..
-
Hi Guys,
first of all thanks to waterwingz for compiling and giving me the last version of the firmware for IXUS_160.
I'm trying to solve problem with focus.
How do you try the last patch for focus?
I'm not able to understand if I'm wrong.
I use chdkptp to comunicate to the camera.
If I type:
set_aflock(1)
set_focus(10000)
get_focus()
it returns a random value (not 10000)
if I try with
set_mf(1)
set_focus(10000)
get_focus()
it returns another random value and if I change set_focus value, it returns other random value without a logic.
Same procedure works perfectly for zoom.
set_zoom(20)
get_zoom()
returns 20.
Other issue with last firmware update 4229 (not present in a release of beginning of August) is this error
ERROR: I/O error
attempted to close non-present device XXX:XXX
when I type two focus command together
set_aflock(1)
set_aflock(0)
return error
set_mf(1)
set_mf(0)
return error
Let me know if I can help you with more details
Luca
-
it returns another random value and if I change set_focus value, it returns other random value without a logic.
The official source doesn't support overriding the subject distance (aka focus).
ERROR: I/O error
attempted to close non-present device XXX:XXX
I suspect the camera also crashes (powers off with extended lens) when this happens. If so, please get a romlog (http://chdk.wikia.com/wiki/Debugging#Camera_crash_logs_.28romlog.29).
when I type two focus command together
set_aflock(1)
set_aflock(0)
return error
set_mf(1)
set_mf(0)
return error
Does that mean the camera crashes if you execute set_aflock(1) followed by set_aflock(0) ?
@nafraf, WW
About the patch: if the new functions ( _xxxxinit() ) are the ones I listed earlier (by address), calling them like this is not the right way: they are not protected against multiple execution and would create new kernel objects each time they're called.
I'm considering replacing MoveFocusLensToDistance and all other affected event procedures with their copies on r54+ cameras, as I think those (lower level) functions would be easier to find with the sigfinder.
-
@srsa_4c
Yes, I used the addresses you posted before. I did not commit the patch because I was not sure if that was the right solution.
Can I do something to fix the port or Should I wait for your patch? Thanks.
-
The official source doesn't support overriding the subject distance (aka focus).
This means that set_focus(XXXXX) works properly but not overrides subject distance on the camera? I've not tried to shot after setting the focus, this evening I'll try.
I suspect the camera also crashes (powers off with extended lens) when this happens. If so, please get a romlog (http://chdk.wikia.com/wiki/Debugging#Camera_crash_logs_.28romlog.29).
Exactly, it crashes with extended lens. Sometimes It crashed also during lens opening, never happened with firmware of the beginning of August (release 4206).
Does that mean the camera crashes if you execute set_aflock(1) followed by set_aflock(0) ?
Yes, I'll report romlog.
-
This means that set_focus(XXXXX) works properly but not overrides subject distance on the camera?
set_focus() will not report any errors, it just won't have any effect.
Sometimes It crashed also during lens opening
Can you describe how this happened step-by-step?
Yes, I'll report romlog.
If the camera crashes, it usually records a crash log in the flash ROM (not on the card). You can then retrieve this log anytime by using the CHDK menu: Miscellaneous stuff -> Debug parameters -> Save ROM crash log. This will create a file on the card (romlog.log in the card root).
@WW
Can you tell me which source was used for this build?
-
@srsa_4c
Yes, I used the addresses you posted before. I did not commit the patch because I was not sure if that was the right solution.
Can I do something to fix the port or Should I wait for your patch? Thanks.
I have already made my recommendation (http://chdk.setepontos.com/index.php?topic=12321.msg124134#msg124134), but here's some more details:
1) new file "platform/camera/sub/boot_extras.c":
/*
*** TEMPORARY workaround ***
Init stuff to avoid asserts on cameras running DryOS r54+
Execute this only once
*/
void init_required_fw_features(void) {
extern void _init_focus_eventflag();
extern void _init_nd_eventflag();
extern void _init_nd_semaphore();
//extern void _init_zoom_semaphore(); // for MoveZoomLensWithPoint
_init_focus_eventflag();
_init_nd_eventflag();
_init_nd_semaphore();
}Added lines to stubs_entry_2.S:
// temporary measure
NHSTUB(init_focus_eventflag, 0xffb7ebfc)
NHSTUB(init_nd_eventflag, 0xffaa8558)
NHSTUB(init_nd_semaphore, 0xffad6344)Insert
>>>
" BL init_required_fw_features\n" // added
<<<after the
PATCHSUB ref=0 name=taskcreatePhySw_myline in code_gen.txt
Insert
>>> file=../boot_extras.cbefore ENDFILE in the boot.c section of code_gen.txt
This method only executes the init functions once, and it is working on my ixus150.
Once all this is done, add the lines mentioned here (http://chdk.setepontos.com/index.php?topic=12321.msg124113#msg124113) to platform_camera.h and test SD override (mftest.lua), ND override and set_zoom().
Did you, by any chance, experience any weird crashes like the ones Steva85 mentioned?
-
Hi to all,
I have two romlog of the tests done yesteday evening.
First one "romlog_after_aflock_mf" was downloaded after crash when I type this command from chdkptp.sh terminal
> luar set_aflock(1)
> luar set_mf(1)
the second one romlog_after_mftest was downloaded after crash during the execution of mftest.lua from camera. Before crash (at some not identificated point) the script returns fail.
To set focus to infinity seems to work this sequence of commands
./chdkptp.sh -c -e'luar set_capture_mode_canon(32773)' (set to P mode)
./chdkptp.sh -c -e'luar press("shoot_half") sleep(1500) set_aflock(1) release("shoot_half")' (simulate half shoot and lock focus)
after that get_focus() returns -1 and stay -1 after every shot (shots are ok!)
if I type only
./chdkptp.sh -c -e'luar set_aflock(1)'
the camera tries to point out the right focus and lock it. (but this not work every time)
after that get_focus() returns random value.
-
First one "romlog_after_aflock_mf" was downloaded after crash when I type this command from chdkptp.sh terminal
> luar set_aflock(1)
> luar set_mf(1)
The log shows that you have executed these several times but that does not make much difference.
Problem is, the crash happened in a task that is not influenced directly by CHDK. As such, it doesn't really help.
the second one romlog_after_mftest was downloaded after crash during the execution of mftest.lua from camera.
The camera has not recorded a romlog for this crash (the 2 romlogs you uploaded are the same).
I sent you a PM with a build that has the fixes I mentioned in the last two pages of this thread. Note that this port is apparently "hot potato" due to the 2 bricked cameras reported earlier. Use the build on your own risk.
This build enables subject distance override and control over the ND filter. Try running mftest.lua to help us figure out which method is usable for setting the focus.
-
Hey everyone, I understand that development takes a lot of hard work, testing, and most importantly time, but do you have any idea of when a stable release of this firmware might be available?
Thanks, Devon
-
Hey everyone, I understand that development takes a lot of hard work, testing, and most importantly time, but do you have any idea of when a stable release of this firmware might be available?
CHDK is an all volunteer effort and has no schedule or master project plan driving it. Things get done when people have the time and interest to work on them. So giving you any idea of a stable release date is pretty much impossible. Sorry.
More info about the whole process is here : link> CHDK FAQ : My camera isn't ported yet (http://bit.ly/1eDoCEp)
If you want my guess (and what do I know anyway?) then I would not expect to see the IXUS160 port get past all the DIGIC4+ issues for many months at best.
-
First one "romlog_after_aflock_mf" was downloaded after crash when I type this command from chdkptp.sh terminal
> luar set_aflock(1)
> luar set_mf(1)
The log shows that you have executed these several times but that does not make much difference.
Problem is, the crash happened in a task that is not influenced directly by CHDK. As such, it doesn't really help.
the second one romlog_after_mftest was downloaded after crash during the execution of mftest.lua from camera.
The camera has not recorded a romlog for this crash (the 2 romlogs you uploaded are the same).
I sent you a PM with a build that has the fixes I mentioned in the last two pages of this thread. Note that this port is apparently "hot potato" due to the 2 bricked cameras reported earlier. Use the build on your own risk.
This build enables subject distance override and control over the ND filter. Try running mftest.lua to help us figure out which method is usable for setting the focus.
Thanks srsa_4c for latest build. Every problem with focus was solved. The release seems very stable, no crash until now. I'll let you know.
-
I sent you a PM with a build that has the fixes I mentioned in the last two pages of this thread. Note that this port is apparently "hot potato" due to the 2 bricked cameras reported earlier. Use the build on your own risk.
srsa_4c : did you update the assembla 1.4.0 source with these changes?
-
srsa_4c : did you update the assembla 1.4.0 source with these changes?
I just did (https://www.assembla.com/spaces/chdk/subversion/commits/4262). I was actually waiting for somebody else to do this (after some testing and #define fine-tuning) as I don't have the camera.
-
srsa_4c : did you update the assembla 1.4.0 source with these changes?
I just did (https://www.assembla.com/spaces/chdk/subversion/commits/4262). I was actually waiting for somebody else to do this (after some testing and #define fine-tuning) as I don't have the camera.
Thanks.
I have someone asking for a test build - and he has read this thread and the wiki warning about possible bricked cameras. Steva85's most recent post seems to indicate the fixes are working. Are there additional things I should ask to be tested?
-
I have someone asking for a test build - and he has read this thread and the wiki warning about possible bricked cameras. Steva85's most recent post seems to indicate the fixes are working.
The reason behind those accidents is still not known (and this isn't likely to change). We believe that they were caused by free space running out while the camera was busy making a JPEG file. Current trunk no longer allows saving RAW/DNG when free space is low, so if that was the cause, it should no longer occur.
I'm not aware of missing tests other than mftest (that does not mean everything is tested and working though ;)).
-
Steva85's most recent post seems to indicate the fixes are working.
The reason behind those accidents is still not known (and this isn't likely to change).
Yea - I know. Was not implying that the most recent fixes were related to the (possible) bricking issue.
-
I have someone asking for a test build
That's probably me.
I've tried installing CHDK on my whole new Ixus160, without success for the moment.
With Stick, I've followed the steps to install a unsupported build, particularly renamed the build to test100a.zip and put it in Stick's folder, restart Stick, but Stick doesn't see/find it.
I've also tried the manual update method (whick I'm quite familiar with, as I also have a G12 and a G15), but I can't locate a "Firm update" item in the Canon menu.
Where am I wrong?
-
I've tried installing CHDK on my whole new Ixus160, without success for the moment.
With Stick, I've followed the steps to install a unsupported build, particularly renamed the build to test100a.zip and put it in Stick's folder, restart Stick, but Stick doesn't see/find it.
I assume zeno ( Dave ) will come along at some point and figure out your STICK issue.
In the meantime, if you have a picture from your G15, use STICK to format an SD card for that. Then simply unzip the ixus160 file I sent you (preserving the folder structure) over top of the G15 files. It should boot after that.
I've also tried the manual update method (whick I'm quite familiar with, as I also have a G12 and a G15), but I can't locate a "Firm update" item in the Canon menu.
I don't have the encryption keys needed to build the ps.fi2 file required for "firmware update" loading on the ixus160 so I did not include it. Most people give up on the "firmware update" method the minute they get SD card lock booting to work anyway. Also, from reading this thread, it's not clear that anybody has actually been able to get "firmware update" loading working with this camera.
-
In the meantime, if you have a picture from your G15, use STICK to format an SD card for that. Then simply unzip the ixus160 file I sent you (preserving the folder structure) over top of the G15 files. It should boot after that.
Great! It worked! Thanks waterwingz!
-
I've tried installing CHDK on my whole new Ixus160, without success for the moment.
With Stick, I've followed the steps to install a unsupported build, particularly renamed the build to test100a.zip and put it in Stick's folder, restart Stick, but Stick doesn't see/find it.
I assume zeno ( Dave ) will come along at some point and figure out your STICK issue.
In the meantime, if you have a picture from your G15, use STICK to format an SD card for that. Then simply unzip the ixus160 file I sent you (preserving the folder structure) over top of the G15 files. It should boot after that.
If useful, when I did this procedure, I've noticed that a folder was created on my desktop under stick\Trunk CHDK\g12-100c, when Stick is unzipped under C:\Users\Pierre\Documents\Outils photo\stick.
-
Hi Piere, glad you got things working. I can't explain why STICK didn't find the zip file (I assume the photo you dropped was for the right camera).
When STICK downloads a build, it unzips it in a folder with the name of the camera and firmware version. If you ever want to install the build on another card, STICK will tell you there's an already downloaded build, so (unless there's an update) you can tell it to use it and avoid another download.
-
Hi Piere, glad you got things working. I can't explain why STICK didn't find the zip file (I assume the photo you dropped was for the right camera).
zeno : is there an issue with STICK not liking folder paths with spaces in them?
-
Hey all ,
Someone sent me an ixus160 , to check if chdk works good enough so he can set up a multi camera thing with these cameras.
I managed to find a chdk file from this thread (tried hard since all links are deleted because some cameras had issues etc etc) and "worked" the camera with chdkptp.
So my questions are :
1. Do i have the latest "version" of the firmware for this camera?Can i have a link or something to test it out?
2. Are there any bugs i should know of ?Can i try to reproduce anything to help the progress here?
3. Where i tell my findings with chdkptp ?Here or to reyalp on some other thread?
4. How good is the progress overall ?What can i tell to the guy that sent me the camera? Is it a viable option or not ?
Thanks.
-
I managed to find a chdk file from this thread (tried hard since all links are deleted because some cameras had issues etc etc) and "worked" the camera with chdkptp.
Links were deleted because a user experienced hw failure on 2 cameras while trying a test build.
To a mod: we can't control that external site, but the link to it should perhaps be removed as it hosts a potentially dangerous early release: http://chdk.setepontos.com/index.php?topic=12321.msg122945#msg122945 (http://chdk.setepontos.com/index.php?topic=12321.msg122945#msg122945)
1. Do i have the latest "version" of the firmware for this camera?
No, what you found is an old release, as described above. Don't use it.
2. Are there any bugs i should know of ?Can i try to reproduce anything to help the progress here?
The specific condition (running out of card space while saving DNG) that seemed to have induced camera failure is no longer allowed to happen in recent CHDK. We don't know whether this is enough to prevent camera failure. No-one else reported failure since then (but there may not be many users as we stopped providing public links to builds).
3. Where i tell my findings with chdkptp ?Here or to reyalp on some other thread?
Camera specific failures (things that work on your cams but not on the ixus160) should be reported here.
4. How good is the progress overall ?What can i tell to the guy that sent me the camera? Is it a viable option or not ?
I don't have this camera, but I have the impression that the port is usable. Bugs are still possible due to lack of widespread testing.
This camera is probably the only option if you need to buy a larger number of identical cameras.
Note that it might be possible that recently manufactured ixus160's have a firmware other than 100a.
-
@srsa_4c
thanks for the link. installed it and everything works fine.
Some things i had issues with the previous version, now seems to work.
Btw i use a multi cam rig on my own, and i use chdkptp to manage the whole thing.So the things i "test" on ixus160 is chdkptp commands , since it is supposed that this camera will be used for the same job.
So every command (connect , disconnect , shutdown , sync , preshoot , shoot , rec mode , preview mode , download images , delete images , set focus , set zoom , etc etc) seems to work flawlessly.
The whole test was with one camera , but i dont see any reason that it wont work with more than one.
If there is some big bug or anything that needs testing or reproducing just let me know.
-
If there is some big bug or anything that needs testing or reproducing just let me know.
There is one potential issue you may want to check before someone starts buying dozens of cameras. It was reported to happen on the ixus145: http://chdk.setepontos.com/index.php?topic=12097.0 (http://chdk.setepontos.com/index.php?topic=12097.0)
Use a battery dummy and an external power supply to power the camera and check whether you can shoot (by hand and over PTP). Perhaps try different SD cards too.
-
Gonna test it when i will be at studio (the next days) where the rig is.
I see that ixus160 uses the same battery with A2500 i am using , so the dummies/external power must suit to ixus160 too.
I will post results when i will test it.
-
I tried to brick my camera to verify that the capture-DNG-with-no-space-bricking bug was fixed. Alas, the experiment was inconclusive. My camera is still healthy.
There are no obvious malfunctions when trying to reproduce on a build which post-dates the fix.
But there are also no obvious malfunctions when reproducing on a build which I think pre-dates the fix.
So I'm not sure what else can be done for now to show that there is no longer a risk of camera bricking. If any of you have ideas, let me know. I'm still willing to use my camera as a sacrificial lamb if necessary.
-D
-
But there are also no obvious malfunctions when reproducing on a build which I think pre-dates the fix.
Yes - disproving this conclusively will be tough.
Did you actually run your SD card down to "empty" prior to trying the test ?
Edit : I've always been very amazed / thankful that I never bricked any of the cameras I ported from scratch. Although no doubt I came close many times.
-
For my test, I created a bootable SD card with CHDK on it. I filled up most of the card with other files, leaving about 300 MB free. Then I put the card into the camera, enabled DNG/RAW photographs, and started taking pictures. When there wasn't enough space left for the DNG file, the camera reverted to taking JPEGs only. And when there wasn't enough space for even a JPEG, the camera started beeping at me plaintively whenever I pressed the shutter button.
I'm happy to change my procedure in some way and try again if it will increase the odds of tracking this bug down.
In the mean time, I think I will move forward in the assumption that (a) it is likely fixed and (b) the things I am doing with the camera will be unlikely to trigger this bug in any case. But my peace of mind would be greatly enhanced if I was sure it was fixed.
-D
-
For my test, I created a bootable SD card with CHDK on it. I filled up most of the card with other files, leaving about 300 MB free. Then I put the card into the camera, enabled DNG/RAW photographs, and started taking pictures. When there wasn't enough space left for the DNG file, the camera reverted to taking JPEGs only. And when there wasn't enough space for even a JPEG, the camera started beeping at me plaintively whenever I pressed the shutter button.
Current CHDK source no longer attempts to save RAW/DNG when free space is low. This was not the case at the time the incidents happened. Aside from this change, no other source change attempted to address the "bug" in question.
my peace of mind would be greatly enhanced if I was sure it was fixed.
I could say the same. However, this isn't likely to happen (unless someone from the Canon engineering team gives us hints where to look :P).
Similar incidents also happened with other models: http://chdk.wikia.com/wiki/Camera_failures_suspected_to_be_caused_by_CHDK (http://chdk.wikia.com/wiki/Camera_failures_suspected_to_be_caused_by_CHDK) .
Here are Scannerall's posts (http://chdk.setepontos.com/index.php?action=profile;area=showposts;u=28521), that's all we know.
And here (http://chdk.setepontos.com/index.php?topic=12321.msg123760#msg123760) are some guesses from me.
Should we vote on enabling autobuild for this port?
-
my peace of mind would be greatly enhanced if I was sure it was fixed.
Well, we could build an older version of the port that does not have the RAW/DNG minimum space fix. If you test that and it bricks your camera (or locks it up for a while as also reported) then we could probably feel a lot more comfortable about thinking it was fixed.
Of course my suggestion has one major drawback .....
-
I attempted this experiment with both a build that I was sure happened after the fix (1.4.0-4265) and one that I thought happened before the fix (1.4.0-4201). If you have a build that you could PM me a link to that you are certain pre-dates the fix, I will happily try it out. It would be worthwhile for me to brick a camera to be certain that the bug is fixed.
-D
-
Hi. I own an IXUS160 camera. and would like to run recent Test build with own risk. Where can I get it?
-
Hi. I own an IXUS160 camera. and would like to run recent Test build with own risk. Where can I get it?
Sent you a link to a new build.
-
Hi,
I'll be please to try test build on my IXUS 160.
I understand the risk to damage the camera.
My goal is to make long time-lapse on the camera or from a raspberrypi with ptp.
-
Hi,
I'll be please to try test build on my IXUS 160.
I understand the risk to damage the camera.
My goal is to make long time-lapse on the camera or from a raspberrypi with ptp.
Link sent.
edit:
below post also answered in PM
-
Hi. I just got an IXUS160 camera to trial some 3d mapping. and would like the latest build and/or the most stable.
Cheers
-
I have now tested extensively using an image with free space checks disabled. Unfortunately, the revision just before the free space fix had a broken build. So I used the current version and commented out the check.
For these tests, I tried to capture pictures with varying amounts of memory free on the card. Below about 8 MB free, the jpeg free space detection prevented me from capturing photos. Between 8 MB and 35 MB, the card would fill up with a partial DNG file and a zero-size JPG. I would see the memory card error that was mentioned before. But there was no crash or any other issue.
Since this is a memory corruption error, it is inherently hard to reproduce. I am not using the same revision that Scannerall used and I don't know which one they had. And the SD card I am using was formatted as a single FAT32 partition whereas Scanerall had multiple partitions and was booting from a FAT16 partition. Any of these could be the reason why I wasn't able to reproduce.
Given that the only plausible explanation was memory corruption caused by capture of a DNG with inadequate free space, and given that I haven't been able to brick my camera after many deliberate attempts, I think that the risk of this bug is now minimal.
I will start treating this like a stable build, and I think it should be reinstated in the autobuild.
-D
-
Given that the only plausible explanation was memory corruption caused by capture of a DNG with inadequate free space, and given that I haven't been able to brick my camera after many deliberate attempts, I think that the risk of this bug is now minimal.
It's not clear what the mechanism would have been if running out of space were the cause, by itself you wouldn't expect running out of space to cause memory corruption. It's also not correct to say this is the only plausible explanation. There are an essentially unlimited number of possible porting errors that could cause memory corruption, which would at least in theory end in hardware damage if they happened to hit the right location.
An alternative possibility was capturing DNG in a mode where valid raw was not available would cause memory corruption because it reverses the bytes of a large chunk of memory that is expected to be the raw buffer, but is actually something else.
This could be tested by commenting out the corresponding CAM_DISABLE_RAW_IN_* defines and shooting DNG in those modes.
That said, I agree that it is reasonable to post builds publicly now, with a warning referencing this thread. Note that this camera was not previously enabled in the autobuild, and it's not clear to me whether or not it is ready, independent of the hardware damage issue.
Edit:
Thanks a lot for risking your camera to test this.
-
Hi,
I'll be please to try test build on my IXUS 160.
I understand the risk to damage the camera.
My goal is to make long time-lapse on the camera or from a raspberrypi with ptp.
Link sent.
edit:
below post also answered in PM
I will get my new IXUS 160 tomorrow,i also want to try the new test build, could you please send me the link of the new test build.
?
Hi,
I'll be please to try test build on my IXUS 160.
I understand the risk to damage the camera.
My goal is to make long time-lapse on the camera or from a raspberrypi with ptp.
-
i also want to try the new test build, could you please send me the link of the new test build.
Link sent.
-
i also want to try the new test build, could you please send me the link of the new test build.
Link sent.
Thanks i will report any problems i get
-
Hello, I am new to the forum.
I have a canon 160 and want to try updating the firmweare.
As I can do to download and try CHKD.
Thank you.
-
Hello, I am new to the forum.
I have a canon 160 and want to try updating the firmweare.
As I can do to download and try CHKD.
Thank you.
Guess you were asking for a test build. Sent you a link.
-
Thanks i will report any problems i get
-
Hallo. I am new in forum.
I have a canon 160 and want to try updating the firmweare.
-
I have a canon 160 and want to try updating the firmweare.
Just a quick note to remind people that CHDK does not update, or change in any way, the firmware in a camera. It acts like a temporary extension to the existing firmware in the camera, loaded into RAM each time it is needed and it goes away each time the camera is turned off.
-
Hi there.
I would like to test out the elph 160 chdk if someone could share the link with me as well.
-Scott
-
Links sent again.
-
Links sent again.
FWIW, I'm fine with people posting builds publicly here, if they reference the camera damage posts. If you want to keep using PMs that's OK too.
-
FWIW, I'm fine with people posting builds publicly here, if they reference the camera damage posts. If you want to keep using PMs that's OK too.
Ideally, I'd like to see this port enabled in autobuild.
The other reason I'm using PMs is that my build includes the .fi2 file (which might spare me writing installation instructions for those who'd like to "update" their firmware). I have not received failure reports so far.
-
can you send me the link too? i`m aware of there risk
-
Can you supply me with the test build. I own a IXSU160 and keen to try CHDK on it.
Regards
Andrew H
-
PMs sent.
-
HI,
i have 2 questions:
-does timelapse work,
-is it possible to get live video to aux video cable?
can i please get the link to the latest build..
thanx!
-
hi! I'm struggling with my IXUS 160, could you please provide me with the latest test build? Thanks in advance!
-
Is the risk of an autobuild version too high?
If I am correctly informed, originated the damage with a partitioned SD card. But this is not the standard procedure for Ixus160.
msl
-
If I am correctly informed, originated the damage with a partitioned SD card. But this is not the standard procedure for Ixus160.
Per this post (http://chdk.setepontos.com/index.php?topic=12321.msg125060#msg125060) I think it's safe to say we don't know what caused one camera to "brick" and another to lock up but not brick. And we most probably never will.
So does it get added to that autobuild until a new user reports a bricked camera (which may or may not be actually caused by this particular bug) ?
-
i have 2 questions:
-does timelapse work,
It should, but you tell me.
-is it possible to get live video to aux video cable?
No.
Links sent to those who requested it.
-
Hello. I have an ELPH160 Camera and I would like to test the latest build at my own risk. Would you please send it to me?
-
Hello. I have an ELPH160 Camera and I would like to test the latest build at my own risk. Would you please send it to me?
Link sent.
I think we should start discussing how to warn users if we decide to enable autobuild.
Include something scary in the readme? Put a word other than 'alpha' in the filename?
-
I think we should start discussing how to warn users if we decide to enable autobuild.
Include something scary in the readme? Put a word other than 'alpha' in the filename?
Replace the CHDK boot logo with a skull & crossbones bitmap ?
(https://www.carstickers.com/prodimages/2864_poison_symbol_skull_and_crossbones_sticker_decal.jpg)
-
I think we should start discussing how to warn users if we decide to enable autobuild.
Include something scary in the readme?
Should definitely put a warning and link to the relevant posts in the notes.txt.
Put a word other than 'alpha' in the filename?
Not a bad idea, but I'm not sure what would fit and convey the message. _DANGER ?
We could update the wiki downloads page, either to warn specifically about this camera, or warn about any camera with whatever we pick to put in the filename.
-
I think we should start discussing how to warn users if we decide to enable autobuild. Include something scary in the readme?
Should definitely put a warning and link to the relevant posts in the notes.txt.
Put a word other than 'alpha' in the filename?
Not a bad idea, but I'm not sure what would fit and convey the message. _DANGER ? We could update the wiki downloads page, either to warn specifically about this camera, or warn about any camera with whatever we pick to put in the filename.
All a noble effort .. but I'd bet that nobody struggling through loading CHDK for the first time will trip over them or realize what they mean.
The notes.txt file? Really ?
Sorry ...
-
I like skull logo idea :D
What if we add a prefix to platform name? That should be visible when people download file from autobuild:
Something like: RISKY_ixus160_elph160-100a-1.4.0-4265-full.zip
-
I'm experiencing a random shutdown with the lens out when simply taking a picture with CHDK loaded.
I'm using ixus160_elph160-100a-1.4.0-4262-full build.
Could you send me a newer version ?
-
I will be posting a link to ELPH 160 images in the diybookscanner.org forum soon. I am going to accompany the links with a link to this description of the bug: http://tenrec.builders/cameras/elph160.html (http://tenrec.builders/cameras/elph160.html)
It seems like there could be something similar that you click through to download an image for it from the CHDK site.
BTW, please let me know if I am incorrect in my summary at the link or if there is any way that the text can be improved or clarified.
-
Hello. I have an ELPH160 Camera and I would like to test the latest build at my own risk. Would you please send it to me?
Link sent.
Thanks, already installed. No problems so far.
-
Hey dudes, i'm patiently wayting for the porting into the autobuild of this chdk since the page n10 of this thread.
I use 3 i160 but bricked one while attempting to remove rgb filter. So i've got one for pieces in case of problem with this chdk.
Without using a partitioned sd card is the risk so important ?
-
I'm experiencing a random shutdown with the lens out when simply taking a picture with CHDK loaded.
I'm using ixus160_elph160-100a-1.4.0-4262-full build.
Can you please get a romlog (http://chdk.wikia.com/wiki/Debugging#Camera_crash_logs_.28romlog.29) and upload it here? Miscellaneous stuff -> Debug Parameters -> Save ROM crash log
Revision 4262 already has a fix that's supposed to enable some CHDK overrides, newer revisions don't have significant improvements.
@Ben29
The problem is that we don't know what was the real cause of misbehaviour.
The specific condition (card fills up while shooting raw) is no longer allowed to happen, but the bug (if any) can still be lurking somewhere.
I sent you a link in case you'd like to give it a try.
-
The notes.txt file? Really ?
The readme (which automatically includes the cameras notes.txt) seems like most likely place for it to be noticed to me.
Yes, a lot of people won't look at the readme, but it at least gives them a chance of seeing it.
-
What if we add a prefix to platform name? That should be visible when people download file from autobuild:
Something like: RISKY_ixus160_elph160-100a-1.4.0-4265-full.zip
The autobuild is some hairy tcl code that does various weird things with the filenames, so I'd be reluctant to change the format. AFAIK putting something in the same spot as alpha/beta shouldn't be a problem.
-
Another option would be to have someone volunteer to post (and periodically update) the stable release for the camera here as an attachment. With a suitably worded warning in the text of the message post. If the download count gets to some arbitrary value (200?) without any reported issues then the camera gets added to the autobuild?
-
I will be posting a link to ELPH 160 images in the diybookscanner.org forum soon. I am going to accompany the links with a link to this description of the bug: http://tenrec.builders/cameras/elph160.html (http://tenrec.builders/cameras/elph160.html)
It seems like there could be something similar that you click through to download an image for it from the CHDK site.
BTW, please let me know if I am incorrect in my summary at the link or if there is any way that the text can be improved or clarified.
As you hopefully learned from the subsequent posts to this one, the theory about this problem being caused by filing up a dual partition card is just a theory. At least one user has tried to duplicate that test condition and failed to damage his camera after many attempts. So we really do not know what caused the issue or whether you can avoid it by not filling you your SD card.
Also, the original issue actually only "bricked" one camera. The other camera being tested resumed working so there has really only been one fatal failure.
-
I'm experiencing a random shutdown with the lens out when simply taking a picture with CHDK loaded.
I'm using ixus160_elph160-100a-1.4.0-4262-full build.
Can you please get a romlog (http://chdk.wikia.com/wiki/Debugging#Camera_crash_logs_.28romlog.29) and upload it here? Miscellaneous stuff -> Debug Parameters -> Save ROM crash log
Revision 4262 already has a fix that's supposed to enable some CHDK overrides, newer revisions don't have significant improvements.
-
@Pierre
Thanks. The crash reason is an "out of memory" situation.
The bad news is: I have no idea where this comes from. The camera has more than 3MB of free heap at start (reported earlier in this thread) which does not decrease significantly in shooting mode. Then, all of a sudden - out of memory.
This has happened to me with my ixus150, and it is the reason that port isn't in autobuild yet.
I have not been able to reproduce it on my camera.
Are you using the camera manually? If so, I can prepare a special build that permanently displays the free memory on screen - this might help finding the operation that eats up the memory.
-
Are you using the camera manually?
All Auto, just switching the camera on and taking a picture... and crash.
If so, I can prepare a special build that permanently displays the free memory on screen - this might help finding the operation that eats up the memory.
I could test that.
-
I have a 160, want to help, and bricking it won't hurt my feelings... where do I sign up?
It took me a good long while to read the 20-odd pages of this thread. As I understand it, now that I've asked for it, a link to the latest test build will be coming in my direction?
Found the link to http://chdk.wikia.com/wiki/Testing (http://chdk.wikia.com/wiki/Testing) in an earlier post, about halfway through this thread. I'll study up there first and try not to ask stupid questions.
-
I have a 160, want to help, and bricking it won't hurt my feelings... where do I sign up?
It took me a good long while to read the 20-odd pages of this thread. As I understand it, now that I've asked for it, a link to the latest test build will be coming in my direction?
Found the link to http://chdk.wikia.com/wiki/Testing (http://chdk.wikia.com/wiki/Testing) in an earlier post, about halfway through this thread. I'll study up there first and try not to ask stupid questions.
Sent you a link. If you'd like to post your experiences / test results, please use this thread.
edit:
Reply sent to below request too.
-
Pls could you send me a Link too?
I am thinking about a rig of 10-20 cams for a head/face scanner.
So i will test my ixus 160 ... and maybe sacrify it ... ;)
-
Eyh guys, since two days now i've installed this CHDK on two ixus 160 cameras. I used a 4 GB and 16 Gb Sd cards.
I don't have lot of returns, to do any problem, certain time the OSd is not transparent but it return back to the normal few seconds later.
I tried to shoot in raw and dng, with and without timelapse scripting, but anything bugged.
I cross the fingers for the next.
I'll post a task on the forum about the USB video signal cable that i want to build for having FPV mode and duplicate image on a small tv.
-
certain time the OSd is not transparent but it return back to the normal few seconds later.
This is the same for all versions of CHDK on every camera. The Canon firmware is not aware that CHDK is writing to the screen and so it sometimes overwrites the information that CHDK is trying to display. This tends to be worse in shooting mode (vs playback / shot review) and is especially bad if you have a focus tracking window active.
While there might be a way for CHDK to tell the Canon firmware not to update the display, so far nobody has found a reliable method to do so.
I tried to shoot in raw and dng, with and without timelapse scripting, but anything bugged.
Does this mean everything is working?
-
Hi,
When I run this script on 1.4.0-4273:
print('start')
set_mf(1)
print('after mf 1')
sleep(1000)
print('before mf 0')
set_mf(0)
print('after mf 0')
My IXUS160 crash @ set_mf(0). It is no happening on another camera (A2500).
ROMLOG attached.
I found it trying to figure out if there are some interferences between set_md_filter() and set_focus()
after some bad focus @ infinity doing timelapses with a modified YASS4.LUA to always force the ND filter.
-
Hi, everybody!
I have two questions that are struggling me:
1) For my Canon Ixus 160, is there any chance to give a separate and constant name for each camera to be displayed when it connected to the PC? Something like C101, C102, C103 etc.
2) Is there any chance to add to each photo file name name of the camera where shoot took place?
So, standard photo file name is IMG_0019.JPG, how to give it a name like C101_IMG_0019.JPG, or C102_IMG_0019.JPG if the photo from another camera.
Thanks in advance!
-
1) For my Canon Ixus 160, is there any chance to give a separate and constant name for each camera to be displayed when it connected to the PC? Something like C101, C102, C103 etc.
You mean something like this : http://chdk.setepontos.com/index.php?topic=11631.0 (http://chdk.setepontos.com/index.php?topic=11631.0)
Or are you thinking more about the issues of knowing which camera is which when you are using CHDKPTP?
Edit :typo
-
When I run this script on 1.4.0-4273:
(...)
My IXUS160 crash @ set_mf(0). It is no happening on another camera (A2500).
ROMLOG attached.
I've been able to reproduce this on my ixus150. What I found is: the above sequence doesn't cause a crash if you half press the shutter at least once before you issue set_mf(0).
Technical explanation: it appears some live view related callback routine(s) do not get set after using set_mf(1), which causes asserts in various places. These script commands use the SS.MFOn and SS.MFOff event procedures currently.
Suggestions:
- half press or shoot between set_mf(1) and set_mf(0)
- try set_aflock() instead
The script doesn't seem to make a lot of sense to me in its current form.
Back to this issue
I'm experiencing a random shutdown with the lens out when simply taking a picture with CHDK loaded.
Pierre has since reported that re-installing the same release to a clean card solved the problem. Guess it would be beneficial to add integrity check to the CHDK core and modules...
-
@waterwingz : yes for my 2 ixus any problem, any bug, that's perfect !
-
Can I have the link for latest IXUS 160 CHDK firmware...please
-
Can I have the link for latest IXUS 160 CHDK firmware...please
Sent you a link along with the usual warning.
-
May I have the link for latest IXUS 160 CHDK firmware, please?
(2) brand new cameras in-hand.
I don't care if they brick - I understand and accept the risk.
Thanks.
-
May I have the link for latest IXUS 160 CHDK firmware, please?
(2) brand new cameras in-hand.
I don't care if they brick - I understand and accept the risk.
Thanks.
Link sent in PM.
In case someone is wondering: the purpose of these public answers is to inform others that the request has been fulfilled. If there's no such post, it can be assumed that I have not answered the request.
-
Can I please get a link to the latest IXUS 160 CHDK Firmware? If I could get it by early tomorrow that would be ideal. I understand the risks and am willing to take them. I have a brand new camera ready to test. Thanks.
-
If I could get it by early tomorrow that would be ideal.
Link sent.
Note that I'm not on 24-hour watch here. I'm also not preventing anyone to share the link, the only request is that it should be done in private.
BTW, "early tomorrow" does not mean much in a forum that has members from all around the world.
-
Thanks for the link. CHDK version 1.4.0 rev 4285 ixus160_elph160 with firmware version 100a
is successfully installed and running. Proceeding to http://chdk.wikia.com/wiki/Testing (http://chdk.wikia.com/wiki/Testing)
-
Tested according to wiki page.
DNG images appear ok - raw buffers appear to be in correct places.
viewed with Shotwell and DarkTable
DNG image is saved when quick shutter press 95% of time.
button is kind of sloppy & I am inconsistent.
RAW file numbers match jpeg file numbers.
No RAWs are skipped.
RAWs are saved with JPEG correctly.
Zebra showed something reasonable.
free mem 164864 bytes
CHDK size 137632 bytes
USB Remote works as expected.
---Scripts---
isobase.lua -> set CAM_MARKET_ISO_BASE=200
mftest.lua -> results attached; errored but took pictures
setmode.lua -> results attached; one error
ubtest.bas -> log not attached due to "2 per post limit"
I see no visible difference between the images
Not sure what to expect re:exposure
Subject matter of the tests was close-up, 10-30cm
MD_tune.bas -> console output of "x cells trigger y"
when waving my hand in front of cam
press shutter to INTTERUPT, graceful exit of script
hooktest.lua -> all pass
I did not test the "fill the SD card and brick the cam." If you'd like me to test that, please suggest a "preferred" method. Please advise if you'd like specific test scripts run, re-runs of above tests, etc.
I will assist with testing and minor hacking on this port if/as newer versions become available.
Not afraid of blue smoke - I have 2 cams and they are relatively cheap.
-
Not afraid of blue smoke - I have 2 cams and they are relatively cheap.
Another one of those times when I wish this forum had a "Like" button.
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fwww.ufo.ethz.ch%2F__we_thumbs__%2F75_1_463px-Symbol_thumbs_up.png&hash=d21d5b6d80806360982d87024d0aab3b)
-
Thanks for the detailed report
free mem 164864 bytes
This is very low. At a minimum, ARAM should be enabled, but the port will still be pretty low.
It's not totally implausible that running out of free RAM could be connected to the earlier problems. This would be very hard to confirm, since running out of RAM would generally just cause a regular crash.
isobase.lua -> set CAM_MARKET_ISO_BASE=200
This is set correctly in platform_camera.h port.
MD_tune.bas -> console output of "x cells trigger y"
It doesn't look like the AF led has been defined in platform_camera.h for this port, so this test won't work. According to comments on set_led, it should be 1.
The way it is supposed to work is you point the camera at a a non-moving subject like a wall, the script triggers the AF led and then times how long it takes for to be picked up by motion detection. Statistics should be displayed on the screen.
I'll PM a build with ARAM enabled and the LED defined.
If you can check the free ram, and verify that the AF led blinks when you run MD_tune, that would be helpful.
This port doesn't have vid_get_viewport_live_fb set, so MD performance will be poor, but the MD_tune stats could be used as a baseline.
-
Thanks for providing test results. I have a few questions.
DNG image is saved when quick shutter press 95% of time.
For the remaining 5%, is it only the DNG that is missing or no photo is taken at all? The latter would be expected.
free mem 164864 bytes
That's strange. The amount of free RAM is usually reported around 3MB, except for 'Pierre' who experienced out-of-memory crashes (which seemed to have gone away after re-installing CHDK). It would be great to find out what (camera or CHDK) feature eats up memory.
setmode.lua -> results attached; one error
Can you repeat this one? If P mode still fails, please do this:
Miscellaneous stuff -> Debug parameters -> Debug data display [Props], Propcase/Paramsdata page [4]
and report the value of entry '49' in P mode.
I see no visible difference between the images
Not sure what to expect re:exposure
You should see differently exposed pictures. If there's no difference that means exposure overrides have failed.
Please make sure you run the test in P mode and deactivate 'servo AF' in the Canon menu.
Since the script tries to switch the cam in P mode, it's possible that it failed to do so (as it happened with setmode.lua).
mftest.lua -> results attached; errored but took pictures
Finally someone provided that. Seems like all methods are 'safe' (except for the weirdness of set_mf() as reported recently).
I did not test the "fill the SD card and brick the cam."
That can't be tested using current CHDK releases (and bricking cameras with a plain old release would not bring us forward either).
-
I'll PM a build with ARAM enabled and the LED defined.
If you can check the free ram, and verify that the AF led blinks when you run MD_tune, that would be helpful.
Will do.
I can build from source as well, if that's of any use.
-
For the remaining 5%, is it only the DNG that is missing or no photo is taken at all? The latter would be expected.
No photo taken at all.
setmode.lua -> results attached; one error
Can you repeat this one? If P mode still fails, please do this:
Miscellaneous stuff -> Debug parameters -> Debug data display [Props], Propcase/Paramsdata page [4]
and report the value of entry '49' in P mode.
Ran script while in Play mode with no debug. Same error.
Ran script while in Play mode with debug enabled as requested. Lens extends, cam powers off. Lens remains extended. Will not power on (using play button or power button) unless battery pull.
Repeated the "Play mode with debug On" test (3) times in succession, with same behavior each time.
Re-ran Play mode test with no debug turned on. Cam behaves normally, test runs, same error in setmode.log
Ran script while in Rec mode with debug. Pass.
Prop values shown on console: Prop 49 = 33345
Re-ran script in Rec mode with debug. Pass.
Re-ran script in Rec mode with no debug. Pass.
Sorry, I don't seem to be able to get you the props when running the Play mode case.
I see no visible difference between the images
Not sure what to expect re:exposure
You should see differently exposed pictures. If there's no difference that means exposure overrides have failed.
Please make sure you run the test in P mode and deactivate 'servo AF' in the Canon menu.
Since the script tries to switch the cam in P mode, it's possible that it failed to do so (as it happened with setmode.lua).
Confirmed that Servo AF = Off in Canon menu
Confirm to run test from Play mode.
ubtest arguments at default.
Comparing images to the "default" image #44 taken by the test;
shoot Tv+2 45 ; is a hair less grainy compared to default
shoot Sv-2 46 ; more grainy than default, pixel blobs visible
shoot ND in 47 ; can't tell apart from #44
shoot ND out 48 ; tiny bit darker in background
LOG_0001.TXT attached.
I'm ignorant re: photography terms so probably not using the right words. Will seek info to get the proper vocabulary. Also, my eyes are going bad from squinting at this tiny stuff - so it's hard to see subtle differences in the images. After study, the images produced by ubtest *are* different. But not very much to my eye.
-
Ran script while in Play mode with no debug.
'P' is not playback mode, it is the most manual shooting mode this camera offers (if you take it out of AUTO mode, it can be found in the Canon shooting menu - the one you get when pressing SET). 'P' stands for 'Program' mode.
Ran script while in Play mode with debug enabled as requested. Lens extends, cam powers off. Lens remains extended. Will not power on (using play button or power button) unless battery pull.
That was not meant to happen, the cam apparently crashed and got stuck in some infinite loop...
Prop values shown on console: Prop 49 = 33345
That should be the shooting mode named 'live'.
So, again, to clarify: the setmode script is for testing the validity of the camera's shooting modes, it's not meant to be used in playback mode.
shoot Tv+2 45 ; is a hair less grainy compared to default
shoot Sv-2 46 ; more grainy than default, pixel blobs visible
shoot ND in 47 ; can't tell apart from #44
shoot ND out 48 ; tiny bit darker in background
The differences should be obvious, apparently they are not. You can use the camera's playback mode histogram to compare.
The script appears to have succeeded switching the cam to P mode.
-
Ran script while in Play mode with no debug.
'P' is not playback mode, it is the most manual shooting mode this camera offers (if you take it out of AUTO mode, it can be found in the Canon shooting menu - the one you get when pressing SET). 'P' stands for 'Program' mode.
Ahh.. Thanks for clarifying what P mode stands for. My bad.
That should be the shooting mode named 'live'.
Yes, you are correct. LIVE shows in the camera osd.
So, again, to clarify: the setmode script is for testing the validity of the camera's shooting modes, it's not meant to be used in playback mode.
Got it, sorry about that.
The differences should be obvious, apparently they are not. You can use the camera's playback mode histogram to compare.
The script appears to have succeeded switching the cam to P mode.
I correctly set the cam to P mode (not live mode), & re-ran the test a couple of times.
Resulting images have subtle differences, nothing dramatic to my eye. I used darktable for evaluating the histograms of resulting DNG images. The CHDK on-screen display is quite difficult for me to physically see and focus on, so using darktable was easier.
Histograms for Tv+2 and Sv-2 look similar to each other, and look similar to default image. But they look different than the histograms for ND tests.
Histograms for ND tests look similar to each other but different than Tv/Sv images, or the default image.
I'm sorry I can't offer you more explanation, but I'm not qualified to evaluate the histogram results. I can post the histogram results as tiny png's if it's useful.
-
I re-ran a couple tests due to my mis-understanding what mode the camera should be in for the test.
setmode.lua -> pass, log attached
mftest.lua -> different results, log attached
Looked again at CHDK Testing url. I think these two are the only tests that are affected by my using an incorrect mode. If there are others, please advise which ones and I'll re-test.
-
Re: MD_tune.bas
for this test, http://chdk.wikia.com/wiki/Testing (http://chdk.wikia.com/wiki/Testing) mentions "record mode" and "AF led."
Can someone please clarify what record mode means in this context? I'm not sure if it means P mode, or Video record mode, or something I've missed in the Canon menus..
The AF led - is this the led on front face of camera, roughly at the same level as the flash, but on the other side of the lens?
I've never seen it be lit.. Tried to provoke lighting it using Canon menu choices; activated autofocus, snap snap, tried a video.. No led blink under any circumstances. But maybe I haven't provoked it correctly.
Can someone suggest under what circumstances this led should light?
Thanks!
-
Can someone please clarify what record mode means in this context? I'm not sure if it means P mode, or Video record mode, or something I've missed in the Canon menus..
I think it just means that the camera is in shooting mode instead of playback. P mode with the lens extended and ready to shoot should do it.
The AF led - is this the led on front face of camera, roughly at the same level as the flash, but on the other side of the lens?
Yes.
I've never seen it be lit.. Tried to provoke lighting it using Canon menu choices; activated autofocus, snap snap, tried a video.. No led blink under any circumstances. But maybe I haven't provoked it correctly. Can someone suggest under what circumstances this led should light?
It's there to assist with AF when the lighting level is low. So, you probably want to try it in AF mode in a mostly dark room?
-
free mem 164864 bytes
This is very low. At a minimum, ARAM should be enabled, but the port will still be pretty low.
It's not totally implausible that running out of free RAM could be connected to the earlier problems. This would be very hard to confirm, since running out of RAM would generally just cause a regular crash.
I don't know how much free memory there is supposed to be, but I think I can confirm your suspicion that the memory is low enough to cause a crash.
Using chdkptp, I can connect. But sometimes executing commands results in "not enough memory" error. If I disconnect, pull the usb cable and start over, I can sometimes execute a string of commands like;
chdkptp -i -c
connected: Canon PowerShot ELPH 160, max packet size 512
con> rec
con 1> shoot
con 2> play
con 3> imdl -ddir=/home/foo/Pictures -last=1 -d=${name} A/DCIM/100__11
A/DCIM/100__11/IMG_0043.DNG->/home/foo/Pictures/IMG_0043.DNG
con 4> q
It's not predictable. But if I quit chdkptp, unplug and replug usb, it usually works.
-
I've never seen it be lit.. Tried to provoke lighting it using Canon menu choices; activated autofocus, snap snap, tried a video.. No led blink under any circumstances. But maybe I haven't provoked it correctly. Can someone suggest under what circumstances this led should light?
It's there to assist with AF when the lighting level is low. So, you probably want to try it in AF mode in a mostly dark room?
Thanks, enabling autofocus + testing in a dark room did the trick.
-
Can you report the free memory with the build I sent, as well as whether the AF led flashes when you run md_tune.bas? The flashing should not depend on lighting conditions or camera settings.
edit
free mem 164864 bytes
That's strange. The amount of free RAM is usually reported around 3MB, except for 'Pierre' who experienced out-of-memory crashes (which seemed to have gone away after re-installing CHDK). It would be great to find out what (camera or CHDK) feature eats up memory.
Yes, this is quite odd.
I'd suggest checking right after startup, then after switching to rec, after shooting, after running a script etc.
-
Can you report the free memory with the build I sent, as well as whether the AF led flashes when you run md_tune.bas? The flashing should not depend on lighting conditions or camera settings.
Yes, thanks for the build file.
Free memory: 3161824 bytes
Yes, the AF led flashes when MD_tune.bas runs.
Not sure if this test has an end.
After 100 triggers, at top of console, values were displayed:
Min = 100 Max = 820 Avg = 184
I killed the test by powering off - not sure how to gracefully stop it.
Cam responded correctly, eg retract lens and turn off.
-
Resulting images have subtle differences, nothing dramatic to my eye.
This is what you should expect as results of running ubtest (it's the same 'scene'):
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FMMObvOW.jpg&hash=2093e977f1d77a224be08fe843f520df)
I can't really explain why exposure overrides fail on your cam. The required hook is at the usual location and the hooktest script reports success...
As for memory, it might be a good idea to determine the size of kernel RAM area that is not used (I mentioned this here (http://chdk.setepontos.com/index.php?topic=12511.0) once). I can detail this if interested.
-
Resulting images have subtle differences, nothing dramatic to my eye.
This is what you should expect as results of running ubtest (it's the same 'scene'):
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FMMObvOW.jpg&hash=2093e977f1d77a224be08fe843f520df)
Here are results using the most recent build from reyalp.
Let me know if further test/debug on ubtest is needed. Thanks.
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Ffilebin.net%2Fk3tjo0d445%2Fubtest_scene_results.jpg&hash=6ea8302939064422f0995210b54a56b3)
-
Free memory: 3161824 bytes
Thanks. ARAM only adds ~130k, so this is the odd memory behavior srsa mentioned. It would be good to try to narrow down what causes the low memory.
Yes, the AF led flashes when MD_tune.bas runs.
Not sure if this test has an end.
You can press the shutter to end any script (unless the script has re-assigned the key)
After 100 triggers, at top of console, values were displayed:
Min = 100 Max = 820 Avg = 184
The max probably means some triggers were missed, but anyway, no need to do more with this test until someone tries to implement fast MD.
I've checked in both the changes from that test build, in trunk r4287 and r4290
-
Would someone be willing to share the link to the most recent version please?
I would love to give it a try.
Thanks :)
-
Would someone be willing to share the link to the most recent version please?
I would love to give it a try.
Sent you a link.
-
I split discussion of STEREO_A's 64 cam project to http://chdk.setepontos.com/index.php?topic=12668.0 (http://chdk.setepontos.com/index.php?topic=12668.0) since it is likely to involve a lot of discussion that isn't port specific.
-
Regarding the low memory issue, the discussion in the sx510 thread (http://chdk.setepontos.com/index.php?topic=10984.160) made me think it would be worth checking if having zebra enabled triggers the problem on ixus160.
-
Volunteering to try this idea -
A more reliable way to test this theory would be to make a build without the low space protection, verify that it works on a card with plenty of space, and then see if it bricks the camera when using a tiny partition.
Scannerall used LICKS to prepare the card, and something was not right about partitioning.. I could try to re-create how he had it, testing using a build without low space protection. Could compare that to a 'clean' partitioning using Linux Method #2b, but also code without low space protection. Do partitioning differences expose something..?.. Also, the 'current' build has more free memory than the first one I tried. Perhaps using *that* version with low space proection disabled?
I realize there is no guarantee this particular test can provoke the failure that was reported. But I would like to try harder to break it (or not) in such a way that could satisfy concern about risks in using the firmware.
-
Can I please get a link to the latest IXUS 160 CHDK Firmware?
I'd like to test. I understand and accept the risk.
Thanks.
-
Volunteering to try this idea -
Scannerall used LICKS to prepare the card, and something was not right about partitioning.. I could try to re-create how he had it, testing using a build without low space protection. Could compare that to a 'clean' partitioning using Linux Method #2b, but also code without low space protection. Do partitioning differences expose something..?.. Also, the 'current' build has more free memory than the first one I tried. Perhaps using *that* version with low space proection disabled?
Thanks for the offer.
If the cause was running out of space, I wouldn't expect partitioning differences to matter much, but it's not totally out of the question. Same goes for free RAM. In either case, there may be an essentially random component like where a particular data structure ends up in RAM or something like that.
The best would be to use the exact same build and settings as scannerall did, but AFAIK we don't know the settings and I don't know if anyone has that specific build saved.
I'm not particularly convinced that running out of SD space was the cause of the problem, it would seem to require multiple unlikely failures in the canon firmware. As I've mentioned earlier, memory corruption due shooting DNG in a mode without valid raw (Digital IS or Low Light) is at least as likely a cause, and AFAIK no one has tested.
I'll PM you a build with both the free space and raw mode protection disabled. For the raw mode test, make sure DNG is enabled, and shoot in one of the "bad" modes (Digital IS or Low Light).
I would also like to repeat my request form a few posts ago that someone test zebra. I suspect this port suffers the same problem as the sx510 did. Since this involves memory corruption, this could also theoretically cause bricking. To test this, just enabled zebra and half press and check free memory repeatedly.
-
Can I please get a link to the latest IXUS 160 CHDK Firmware?
I'd like to test. I understand and accept the risk.
Thanks.
Build sent.
-
Thanks for link.
-
Could I please have a link to the latest ixus 160 firmware please? I have two of them and accept the risk. Thanks,
-
Could I please have a link to the latest ixus 160 firmware please? I have two of them and accept the risk. Thanks,
Link sent.
-
Could I please have a link to the latest IXUS160 firmware. I am happy to take the risks.
Thank you,
John
-
Could I please have a link to the latest IXUS160 firmware. I am happy to take the risks.
Link sent.
-
Hey Reyalp! I would like to test CHDK on my IXUS 160. I understand there is a possibility I might brick my camera.
Thanks!
-
Hi Reyalp. Can I have the link for the latest build CHDK for the IXUS 160? I understand the risks and i'm willing to take them.
Thanks
-
Hey Reyalp! I would like to test CHDK on my IXUS 160. I understand there is a possibility I might brick my camera.
Hi Reyalp. Can I have the link for the latest build CHDK for the IXUS 160? I understand the risks and i'm willing to take them.
Links sent.
NB
I would also like to repeat my request form a few posts ago that someone test zebra. I suspect this port suffers the same problem as the sx510 did. Since this involves memory corruption, this could also theoretically cause bricking. To test this, just enabled zebra and half press and check free memory repeatedly.
-
I would also like to repeat my request form a few posts ago that someone test zebra.
I almost hate to say this, and it's absolutely not something that you should have to do, but you could always tweak the custom build for this camera to come up with zebra enabled and a running total for free memory permanently in the corner of the screen ;)
-
Could I please have a link to the latest IXUS160 firmware. I am happy to try & take the risks.
Thank you !!!!!!!
-
Could I please have a link to the latest IXUS160 firmware. I am happy to try & take the risks.
Thank you !!!!!!!
Sent.
-
Could I please have a link to the latest IXUS160 firmware. I understand the risk. Thank you.
-
Could I please have a link to the latest IXUS160 firmware. I understand the risk. Thank you.
Sent.
Also :-[
I would also like to repeat my request form a few posts ago that someone test zebra. I suspect this port suffers the same problem as the sx510 did. Since this involves memory corruption, this could also theoretically cause bricking. To test this, just enabled zebra and half press and check free memory repeatedly.
-
I'm testing zebra using trunk rev 4298. I have not seen any change in memory info.
-
I'm testing zebra using trunk rev 4298. I have not seen any change in memory info.
Thanks :)
Did you do half presses where a substantial part of the viewport would show something on the zebra? If so, I'd expect bad things to happen pretty quickly if it has the same problem as sx510 did.
The reason I asked is that vid_get_viewport_height returns 480 or _GetVRAMVPixelsSize. Most cameras with a viewport height of 480 use vid_get_viewport_yscale 2 and return half height values. This is a big mess of interacting functions and defines, so I'm not 100% sure it's wrong but it seems suspect.
A comment says "taken from n" but the N port actually returns 240 or _GetVRAMVPixelsSize/2, and uses yscale 2
Do edge overlay and zebra display correctly on this camera? chdkptp live view?
-
Did you do half presses where a substantial part of the viewport would show something on the zebra? If so, I'd expect bad things to happen pretty quickly if it has the same problem as sx510 did.
Yes, I did that yesterday.
The reason I asked is that vid_get_viewport_height returns 480 or _GetVRAMVPixelsSize. Most cameras with a viewport height of 480 use vid_get_viewport_yscale 2 and return half height values. This is a big mess of interacting functions and defines, so I'm not 100% sure it's wrong but it seems suspect.
A comment says "taken from n" but the N port actually returns 240 or _GetVRAMVPixelsSize/2, and uses yscale 2
Do edge overlay and zebra display correctly on this camera? chdkptp live view?
I tested again, an now I see that zebra area appears at right position, then it appears with vertical offset, then it backs to right position. I did not noticed that offset yesterday probably because zebra areas were at top of screen and it looked like the areas were blinking.
chdkpt live view works correctly with all capture modes. ixus160 does not have option to change aspect ratio.
-
Hi,
Could you send me the latest CHDK version for canon ixus 160?
Thank you very much! ::) ::)
-
Could you send me the latest CHDK version for canon ixus 160?
Sent.
-
Could I get the latest ixus160 firmware build? I understand the risks and the bug that was experienced doesn't fit my use case anyway. Thanks!
-
Could I get the latest ixus160 firmware build?
Sent.
I understand the risks and the bug that was experienced doesn't fit my use case anyway. Thanks!
The root cause is unknown, so unless your use case is "paper weight" I would be not assume it's completely safe ;) That said, many people appear to be using this port without problems, so the risk is likely to be low.
-
I also would like to test it, I asume the risks. Could you send me the link?
Thank you and congrats for your work!
-
I also would like to test it, I asume the risks. Could you send me the link?
Sent.
-
Hi, Could you send me the latest CHDK version for canon ixus 160?
thanks so much
-
Hi, Could you send me the latest CHDK version for canon ixus 160?
thanks so much
Sent
-
Are the hookutil /rawoplib implemented on the IXUS160?
Did somebody try to run rawopint on the IXUS160?
-
Are the hookutil /rawoplib implemented on the IXUS160?
This should work, the raw hook is implemented.
-
hello reyalp!
thanks for your hard job with the ixus160! could you be so nice and send me the latest CHDK version for this camera? thank you!
-
hello reyalp!
thanks for your hard job with the ixus160!
To be clear, the hard work was mostly done by adong.
could you be so nice and send me the latest CHDK version for this camera? thank you!
Sent.
On the future of this port:
I've shared builds with over a dozen people, and heard virtually nothing back from anyone. Presumably that means it's working, or at least that no one else has bricked there camera.
I don't see any practical way to put a visible warning on the build, but at some point it's probably time to say enough is enough and enable it in the auto-build.
Thoughts?
There is still an possible issue with the zebra that needs to be investigated:
http://chdk.setepontos.com/index.php?topic=12321.msg125750#msg125750 (http://chdk.setepontos.com/index.php?topic=12321.msg125750#msg125750)
-
I don't see any practical way to put a visible warning on the build, but at some point it's probably time to say enough is enough and enable it in the auto-build. Thoughts?
Another choice might be to just attach a stable build to a post here with a suitable warning as part of the post. When the stable version is bumped for a major bug fix, someone just needs to remember to update here. Not a great solution but it saves you (& others) from having to constantly respond to requests?
Something like :
WARNING : the CHDK port for the ixus160/elph160 posted here is believed to be stable but one camera was "bricked" during the completion of this port. As with any CHDK port, use with caution as there are no guarantees.
-
I've shared builds with over a dozen people, and heard virtually nothing back from anyone. Presumably that means it's working, or at least that no one else has bricked there camera.
Same here.
at some point it's probably time to say enough is enough and enable it in the auto-build.
I agree.
There is still an possible issue with the zebra that needs to be investigated:
I believe that no framebuffers (= those we're using) have a height over 240 pixels, so the 480 in the source is not correct. (but that's probably not all)
Another choice might be to just attach a stable build to a post here
The firmware update boot can be useful sometimes (I usually use that to make a card bootable). Due to our unwritten rules, we don't publish those files here.
-
I believe that no framebuffers (= those we're using) have a height over 240 pixels, so the 480 in the source is not correct. (but that's probably not all)
Agreed. This really needs someone to go through all the viewport/bitmap values. I'll try get around to it eventually if no one else does. Maybe after that is a good point to add it to the autobuild.
The firmware update boot can be useful sometimes (I usually use that to make a card bootable). Due to our unwritten rules, we don't publish those files here.
FWIW, I avoid posting the keys, but I don't see any problem posting FI2 files. (disclaimer: not a lawyer ;))
-
hallo, i am very new in handling with a camera, but in the short time i am working with the ixus 160 and the last chdk-built i want to report what i did yet:
made a sd-card bootable with cardtricks144, installed ptpcam and ptpcamgui on my pc and let this gui work for me.
all the possible buttons are working very good, slow, but they are doin their job. also the dng-captures are working. so far so good, i am very happy that you sent me this maybe instable built to test but i didn't recognized any problem. thanks a lot!
-
made a sd-card bootable with cardtricks144
Thanks for the report.
Be aware that the CardTricks program is very old and does not correctly handle SD cards larger than 4G in size. If you would like to use a better utility to correctly format and setup CHDK on a larger card, the STICK Utility (http://zenoshrdlu.com/stick/stick.html) is highly recommended.
For loading an unofficial build like the ixus160, you will also need to read this as well : STICKX (http://zenoshrdlu.com/stick/stickx.html)
-
thank you waterwingz
it seems i had a little bit luck, i used a 4 gb card. so the next time i am warned.
-
I just ran into a crash myself during capture. It is flaky, but it happened during remote capture after I had just AF-locked the focus. I have attached the romlog.log. Ideas?
-D
-
I just ran into a crash myself during capture. It is flaky, but it happened during remote capture after I had just AF-locked the focus. I have attached the romlog.log.
The crash was a consequence of the AF lock procedure.
For devs: DoAFLock sends message #0x11 to captseqtask, and one of the fw routines there failed. The failed routine is in ImgSensDrvConv.c, could be related to something like 'sensor operating mode' (that's a guess).
Question:
Can you reproduce it?
-
It happened twice in a row (once on one camera, once on a second camera), but didn't happen again over a dozen or so trials. I'll try a more systematic stress test and see if I can reliably get it to happen once every N trials.
Two other kinds of problems that I've heard about, but don't have crash logs for:
(1) is the auto-focus going wonky when AF-lock is left off. The camera can look at a scene and take several crisp shots with AF on, but then start taking blurry shots. The blurry shots consistently happen until the camera is power cycled.
(2) is random crashes after a large number of remote captures (>30). No AF Locking is used in these cases from what I hear. I haven't got any crash logs back from one of these cases yet. Could be the out of memory bug from before. Could be something else.
So far, I have distributed a build to a number of users and nobody has reported a bricked camera yet.
-D
-
Hi, Could you send me the latest CHDK version for canon ixus 160?
thanks so much
Mitraraw
-
Hi, Could you send me the latest CHDK version for canon ixus 160?
thanks so much
Mitraraw
Sent.
-
Hi, Could you send me the latest CHDK version for canon ixus 160?
Just wondering. I've sent you a link 2 months ago. Have you experienced problems with that older build?
-
There is still an possible issue with the zebra that needs to be investigated:
I believe that no framebuffers (= those we're using) have a height over 240 pixels, so the 480 in the source is not correct. (but that's probably not all)
Regarding this: Can someone provide a chdkptp lvdump of this camera? Should in record mode, with both viewport and UI overlay enabled. A "quick dump" from the GUI or default 'lvdump' from the CLI is fine.
-
Could I get access to the latest canon ixus 160 CHDK version link to test.
Thanks,
-
Regarding this: Can someone provide a chdkptp lvdump of this camera? Should in record mode, with both viewport and UI overlay enabled. A "quick dump" from the GUI or default 'lvdump' from the CLI is fine.
I sent you a PM with the link to the lvdump file. Thanks.
-
Could I get access to the latest canon ixus 160 CHDK version link to test.
Sent
I sent you a PM with the link to the lvdump file. Thanks.
Received. Thanks :)
-
From nafrafs lvdumps it looks like this camera has 720x240 viewport and bitmap, similar to older cameras like D10 (I expected to be 480 like elph130). So the only (probable) error I see is returning a height of 480 in playback mode. I'm assuming the chdkptp live view shows the whole viewport area, it looks to me like it does but it's hard to be certain.
This wouldn't explain the issue nafraf reported with the zebra (http://chdk.setepontos.com/index.php?topic=12321.msg125750#msg125750). I'm not sure how this would happen, an lvdump showing it might be useful. One thing that occurs to me is that zebra does not currently honor DRAW_ON_ACTIVE_BITMAP_BUFFER_ONLY, disp_zebra just draws on both buffers, and assumes the second immediately follows the first. If there was a gap, that might produce something like nafraf described.
Here's a test build that has the playback mode height set to 240 and shows the bitmap addresses. I'm mostly interested in the BM0 and BM1 values.
https://app.box.com/s/6m917eq3z6bepg1se2gs1v6o0zpsxaiq (https://app.box.com/s/6m917eq3z6bepg1se2gs1v6o0zpsxaiq)
I'm posting this publicly, but the usual elph160 bricking warning applies (http://chdk.setepontos.com/index.php?topic=12321.msg123736#msg123736). If it destroys your camera don't blame us.
-
just draws on both buffers, and assumes the second immediately follows the first. If there was a gap, that might produce something like nafraf described.
Not sure if this is what you're looking for, but just in case. This is from the RAM dump I have. Buffer size = 720x360, only the first 240 lines are used.
edit:
Turns out, these might be necessary (as in the ixus150 port):
#undef CAM_BITMAP_HEIGHT
#define CAM_BITMAP_HEIGHT 360
-
General framebuffer discussion split to http://chdk.setepontos.com/index.php?topic=12709.0 (http://chdk.setepontos.com/index.php?topic=12709.0)
-
This patch is based on your comments and ixus150 port. zebra and chdkptp liveview work without problems.
Is there any other test that you suggest?
-
This patch is based on your comments and ixus150 port. zebra and chdkptp liveview work without problems.
Is there any other test that you suggest?
Seems good to me. You could check edge overlay.
-
Thanks. Edge overlay works. Changes committed to trunk rev. 4317 (https://www.assembla.com/spaces/chdk/subversion/commits/4317)
-
I can get the AFL bug to happen consistently if occasionally. It seems to be a crash 1 time in 10 or so. So if somebody has a proposed fix, I can test it. I can verify that it happens on build 4317.
There is also an idle crash that I see happening. Randomly while I have left the camera on, it shuts down spontaneously. I've attached a romlog I took after a recent incident. I'm not 100% sure that this is a crash. I suppose it could also be a power-saving setting I don't know about.
-D
-
If by AFL bug we mean
1. set aflock ON
2. play with zoom values
3. shoot randomly during step #2
4. Camera shuts off / crashes etc
then it happened to me too.Every time.. zooming in out / shooting...it would crash after some tries.
With aflock OFF , there is no problem.After many repeats of the above steps.
Using build 4317 here too.
Other than that i cant tell i am seeing any other problem...during my messing around.
Camera will stay for looong time here , so anything needs testing ...tell me.
-
I can get the AFL bug to happen consistently if occasionally. It seems to be a crash 1 time in 10 or so. So if somebody has a proposed fix, I can test it. I can verify that it happens on build 4317.
Not a fix, just ideas.
The romlog seems too show that you're doing something like
- half press
- wait a second
- issue set_aflock(1)
- immediately release half press
If so, try without half-pressing the shutter. set_aflock(1) does a focus scan on its own.
There is also an idle crash that I see happening. Randomly while I have left the camera on, it shuts down spontaneously.
Are you sure it's a crash? It is if you find the cam powered off with extended lens.
If the lens is retracted, it's likely just a regular shutdown. Check the power saving settings in the Canon menu.
I'd also like to note that CHDK seems to interfere with ECO mode (it doesn't activate reliably even when CHDK is set to allow power saving). If you have it 'on', try disabling it.
I've attached a romlog I took after a recent incident. I'm not 100% sure that this is a crash. I suppose it could also be a power-saving setting I don't know about.
That's an AF lock crash.
-
1. set aflock ON
2. play with zoom values
3. shoot randomly during step #2
4. Camera shuts off / crashes etc
Since set_zoom() is kinda hack-ish, I'd avoid using it while AF lock is on. Try locking the focus before you actually start shooting and unlock the focus when you need to zoom.
-
My 'idle crash' does seem to be power saving. The lens retracted and I went into the settings and found that there was some kind of power saving option enabled that I was able to turn off. Oddly enough, I have two identical cameras and one has the power saving menu option ghosted out and the other one does not. I'll have to check them when they come out of the box in future to see if the power saving is enabled by default.
Regarding AFL: I will try commenting out the half-press-and-wait. When I was experimenting before, it seemed necessary. But that was with an A2200 which might work a bit differently.
-D
-
FWIW, menu items that are greyed out in AUTO mode will often be active in P mode. So your issue might be related to other settings and not a camera to camera difference.
-
Switching to P-mode and doing AFL alone without the half-presses does seem to make things a lot more stable. I need to figure out how to switch to P-mode in code rather than manually configuring the camera. But there still seems to be an occasional AFL crash. See attached ROMLOG.
-
Switching to P-mode and doing AFL alone without the half-presses does seem to make things a lot more stable. I need to figure out how to switch to P-mode in code rather than manually configuring the camera. But there still seems to be an occasional AFL crash. See attached ROMLOG.
I have no idea about this crash, it's not an obvious one. I don't know if it's normal to see the following logged actions in the same moment:
00813410: SS:AFUL
00813410: SS:AFUL*
00813410: SS:AFLAFUL is AF unlock, AFL is AF lock.
P mode is highly recommended when using CHDK scripting. Auto modes enable several features that do not go well with CHDK overrides.
However, P mode also offers many features that an cause problems - but there's at least a chance for disabling them.
Can you go through the Canon menu (the one you get when pressing MENU) in shooting mode and list the current settings? If that's easier, upload screenshots.
For mode change, use set_capture_mode() (http://chdk.wikia.com/wiki/Script_commands#set_capture_mode.28modenum.29). You may find the scripting cross reference (http://chdk.wikia.com/wiki/CHDK_Scripting_Cross_Reference_Page) useful.
-
Hmm. Perhaps as a workaround I need a delay in there. I set aflock to 0 then immediately set aflock to 1 in order to refocus the camera even if it had already been in AFL from a previous run. I'll let you know if I run into any more crashes as I am testing. Thanks.
-
You can get a refocus by just calling set_aflock 1 again. You don't need to release the aflock in between. Adding a short sleep between commands is always a good idea.
-
Setting white balance seems broken on this camera using build 4317. For example, here is me trying to set white balance to Tungsten:
set_prop(require('propcase').WB_MODE, 3); sleep(50);
There is no crash, it just doesn't change any setting as far as I can tell.
I can verify that this same code does work on an A2500.
-D
-
Setting white balance seems broken on this camera using build 4317. For example, here is me trying to set white balance to Tungsten:
set_prop(require('propcase').WB_MODE, 3); sleep(50);
One thing you can check is whether that propcase changes when you set the WB mode through the canon UI. Enable the propcase viewer, set to page 27 and watch what happens to 271.
It may also depend on what shooting mode the camera is in. If it doesn't allow setting WB in the canon UI (like in AUTO), setting the propcase may be ignored.
-
Good call on this. Checking the propcase values after setting it by hand reveals that the propcase key is the same, but the values have shifted meaning. The Tungsten white balance is 4 on an ELPH 160 while it is 3 on other cameras.
There is a similar issue with disabling the flash. Though that isn't a propcase. I'll have to see what I can figure out.
-D
-
Good call on this. Checking the propcase values after setting it by hand reveals that the propcase key is the same, but the values have shifted meaning. The Tungsten white balance is 4 on an ELPH 160 while it is 3 on other cameras.
So setting to 4 gives you the correct result?
There is a similar issue with disabling the flash. Though that isn't a propcase. I'll have to see what I can figure out.
You should be able to disable the flash using the FLASH_MODE propcase, but it's possible the values have changed. propset6.h says
#define PROPCASE_FLASH_MODE 143 // 0 = Auto, 1 = ON, 2 = OFF
-
Setting the propcase for flash mode changes both the result of get_prop() for the key and get_flash_mode(). But the old flash mode persists on the viewscreen of the camera. My testing was in bright light, so the flash wasn't being triggered in any case. So I suppose I need to test whether (a) the flash is being set to off but is not showing up in the interface or (b) the flash is not being correctly set.
-
Setting the propcase for flash mode changes both the result of get_prop() for the key and get_flash_mode(). But the old flash mode persists on the viewscreen of the camera.
Changes to propcases do not usually show up on screen immediately.
-
Could someone summarize hows the port going, i mean what works, or what doesnt work... (the thread is long i dont have the time to read it currently, sorry :-( ).
Im mainly targeting the functionality with some sort of ptp (mainly simple captures, download of files through usb would be nice also) or the usb remote trigger.
Do these two functions (ptp functions (mainly capture)) and USB remote trigger. Do these work?
-
Could someone summarize hows the port going, i mean what works, or what doesnt work... (the thread is long i dont have the time to read it currently, sorry :-( ).
Im mainly targeting the functionality with some sort of ptp (mainly simple captures, download of files through usb would be nice also) or the usb remote trigger.
Do these two functions (ptp functions (mainly capture)) and USB remote trigger. Do these work?
My impression is quite a few people are using this port with book scanners, so these function probably work.
You should be aware of the reported camera damage (http://chdk.setepontos.com/index.php?topic=12321.msg123736#msg123736) earlier in development of the port.
-
edit: old, port is in autobuild now
For all ixus160 users, here's a build of the most recent sources:
I know a lot of people are using builds that were provided though PM at various points. Before adding this to the autobuild, I'd like to give everyone a chance to try the current version.
The usual warning about camera damage (http://chdk.setepontos.com/index.php?topic=12321.msg123736#msg123736) applies. No warranty, use at your own risk. If it destroys your camera don't blame us, but please do tell us ;)
Please do not share zip or the download link without directing people to this post.
-
For all ixus160 users, here's a build of the most recent sources:
I know a lot of people are using builds that were provided though PM at various points.
Before adding this to the autobuild, I'd like to give everyone a chance to try the current version.
I have just received my first Ixus160 and did a very Quick Ixus160 CHDK check.
The camera Powered Up Ok and seemed to work Ok when just testing a few basic CHDK Functions.
Edit #1, Some More detailed test results:- Seemed to work Ok.
Re: IXUS160/ELPH160 Porting attempt « Reply #368
Edit #2 "...The usual warning about camera damage applies...":- my Camera is still Ok.
However there appears to be a small amount of the Ixus 160-100a port that,
"May have some Porting Errors", my thoughts are that this may be a potential problem
and the cause of the "...camera damage ..." reports. (???)
.... Comments Anyone ......
More details in another post.
H-H
-
Thanking you guys that help many people by developing CHDK, I am a new member here.
firstly I apologize if i am sending my question among your valuable posts, but I need help and decided to ask you here:
I know that CHDK is capable of doing many functions in Canon cameras. I see that "IXUS 160" is not fully supported by CHDK and this model is not listed as a camera that could run CHDK in full functions. and you guys are helping to solve the problems.
now my question; I want a specific action among all the functions of CHDK and that is "Remote Shutter Release". I don't need all professional functions that CHDK is capable of performing. I just want to connect a USB cable with a button at the end to the camera and start focusing and shooting by hitting the button. that's all.
in this case, is it OK and risk-less to use CHDK on my IXUS 160? Does CHDK perform this specific action? will it work?
Many thanks,
Ressa
-
now my question; I want a specific action among all the functions of CHDK and that is "Remote Shutter Release". I don't need all professional functions that CHDK is capable of performing. I just want to connect a USB cable with a button at the end to the camera and start focusing and shooting by hitting the button. that's all.
The ixus 160 port is pretty functional. The only reason it isn't in the auto build is the camera damage incidents discussed earlier in the thread.
What you are describing is the USB remote function (http://chdk.wikia.com/wiki/USB_Remote). As far as I know, this feature works.
in this case, is it OK and risk-less to use CHDK on my IXUS 160?
There are too many unknowns unknowns to say that any CHDK port is risk free. CHDK is provided as is, and comes with absolutely no warranty. Given the history of this port, it is probably higher risk than some others. The only thing we know for sure at this point is that a number of people have used this port without any additional reports of damage.
-
However there appears to be a small amount of the Ixus 160-100a port that,
"May have some Porting Errors", my thoughts are that this may be a potential problem
and the cause of the "...camera damage ..." reports. (???)
.... Comments Anyone ......
Without details of the supposed bugs, there is nothing to comment on.
-
However there appears to be a small amount of the Ixus 160-100a port that,
"May have some Porting Errors", my thoughts are that this may be a potential problem
and the cause of the "...camera damage ..." reports. (???)
.... Comments Anyone ......
Without details of the supposed bugs, there is nothing to comment on.
He's trying to "fix" things he thinks are erroneous. That includes:
- messing up assert string references
- "fixing" subroutine references where code_gen removed an intermediate jump
- modifying some instructions, for example
" MOV R1, #0 \n"
" MOV R0, #0x48 \n"
" BL sub_FF8B38E0 \n"
becomes
" MOV R1, #0 \n"
" MOV R1, #0X48 \n"
" BL sub_FF8B38E0 \n" // 100a
- re-instating the usual CreateTask patch, even though the function is in ROM
etc.
Above comes from his ixus170 "stuff" for which he used the blind port uploaded by me.
He clearly has no clue about ARM assembly. I'd be cautious about any CHDK binary uploaded by him (though he rarely manages to compile anything).
-
Thanking your response, I have another basic question:
I understood that "IXUS 160" has a number of damage reports when using CHDK. now my question; when do these damages exactly occur?
I assume the damage might occur in two different times:
1st case: Camera boots fine with CHDK and damage occurs only when trying to reach an specific item of CHDK menu.
2nd case: After loading CHDK in memory card, Camera does not boot in the first place and we understand that camera has been damaged.
Which one of mentioned cases happens when we say" IXUS 160" has a damage report?
-
I understood that "IXUS 160" has a number of damage reports when using CHDK. now my question; when do these damages exactly occur?
See discussion starting at this post: http://chdk.setepontos.com/index.php?topic=12321.msg123736#msg123736 (http://chdk.setepontos.com/index.php?topic=12321.msg123736#msg123736)
-
For all ixus160 users, here's a build of the most recent sources:
https://app.box.com/s/qzkq5j29ncs84064fpog03f6z2an0xpk (https://app.box.com/s/qzkq5j29ncs84064fpog03f6z2an0xpk)
I think this is link of latest version of CHDK for "IXUS 160". but this link is not working for me, may someone send another link in other sharing website or as direct attachment here?
-
For all ixus160 users, here's a build of the most recent sources:
https://app.box.com/s/qzkq5j29ncs84064fpog03f6z2an0xpk (https://app.box.com/s/qzkq5j29ncs84064fpog03f6z2an0xpk)
I think this is link of latest version of CHDK for "IXUS 160". but this link is not working for me, may someone send another link in other sharing website or as direct attachment here?
The link is functional. Perhaps box.com is banned in your country?
Here's the same file uploaded to an alternative site, if it's still not working, please name a file host that works for you.
http://filebin.net/yto2np9sgs/ixus160_elph160-100a-1.4.1-4319-full.zip (http://filebin.net/yto2np9sgs/ixus160_elph160-100a-1.4.1-4319-full.zip)
-
For all ixus160 users, here's a build of the most recent sources:
https://app.box.com/s/qzkq5j29ncs84064fpog03f6z2an0xpk (https://app.box.com/s/qzkq5j29ncs84064fpog03f6z2an0xpk)
I think this is link of latest version of CHDK for "IXUS 160". but this link is not working for me, may someone send another link in other sharing website or as direct attachment here?
The link is functional. Perhaps box.com is banned in your country?
Here's the same file uploaded to an alternative site, if it's still not working, please name a file host that works for you.
http://filebin.net/yto2np9sgs/ixus160_elph160-100a-1.4.1-4319-full.zip (http://filebin.net/yto2np9sgs/ixus160_elph160-100a-1.4.1-4319-full.zip)
Many thanks, the link worked like a charm and I just downloaded CHDK. about your question, the answer is yes, the site seems to be banned in my country / I don't know why!!!
Ok, So i should just easily extract and copy the files into sd-card and turn on the camera, right?
-
Ok, So i should just easily extract and copy the files into sd-card and turn on the camera, right?
Installation methods are listed here: http://chdk.wikia.com/wiki/Prepare_your_SD_card (http://chdk.wikia.com/wiki/Prepare_your_SD_card)
We usually recommend the STICK (http://www.zenoshrdlu.com/stick/stick.html) utility. If you choose to try it, you need to follow the method described here: http://www.zenoshrdlu.com/stick/stickx.html (http://www.zenoshrdlu.com/stick/stickx.html)
There is an even simpler method (if you're not using a Mac and card is smaller than 64G):
- extract zip to card (all files and directories)
- start cam with the PLAYBACK button, press MENU, locate "Firm update" in the bottom of the menu, execute it
-> cam will reboot, CHDK will start
- press the PLAYBACK button for a moment, then MENU to enter the CHDK menu
- navigate to "Miscellaneous stuff" -> "SD Card" and execute "Make card bootable"
- switch off the cam, take out the card, lock it, put it back in
- CHDK will automatically start from now on
edit:
clarified one of the steps, thx. WW
-
- start cam, press MENU, locate "Firm update" in the bottom of the menu, execute it
-> cam will reboot, CHDK will start
Don't forget to mention starting the camera by pressing the Play button (the one with the triangle in the rectangle) and not the On/Off button.
-
I am a complete noob,, but I would like to use my ELPH 160 for FPV camera triggering. I am interested in trying the CHDK but not sure where to download the firmware. Any help would be appreciated. I would also like live video out, I have a Canon cable, but the video out only works on replays.
-
I am a complete noob,, but I would like to use my ELPH 160 for FPV camera triggering. I am interested in trying the CHDK but not sure where to download the firmware.
See this post: http://chdk.setepontos.com/index.php?topic=12321.msg126202#msg126202 (http://chdk.setepontos.com/index.php?topic=12321.msg126202#msg126202)
Any help would be appreciated. I would also like live video out, I have a Canon cable, but the video out only works on replays.
Unfortunately, like many recent Canon cameras, the elph160 do not let you use video out while shooting. We don't currently have a method to bypass this, although srsa did some initial investigation http://chdk.setepontos.com/index.php?topic=11439.0 (http://chdk.setepontos.com/index.php?topic=11439.0)
You can get the camera display using the PTP extension (http://chdk.wikia.com/wiki/PTP_Extension) live view, but this requires a USB host capable of running CHDK client software connected to the camera.
If you want to find a camera that does support video out while shooting, check the Canon manual for the camera. If the camera supports shooting with video out, it will be mentioned in the TV display section. If it doesn't, then only playback will be mentioned.
-
Thanks for your help. :)
-
It worked great on my ELPH160, I just low (check box) formatted the SD card in the camera, then inserted my SD into PC and extracted all files to SD, left unlocked, SD in camera, started camera with Play button, then menu-> to firmware update, ok, CHDK logo displayed, then camera shutter, the Alt button is the Play button, Alt displayed, then press Menu, Success, CHDK menu displayed.
This may help other noobs.
Thanks everyone for your hard work.
-
Hi, Could you send me the latest CHDK version for canon ixus 160?
thanks so much
Enrique
-
Hi, Could you send me the latest CHDK version for canon ixus 160?
thanks so much
Enrique
See the links in this post http://chdk.setepontos.com/index.php?topic=12321.msg126271#msg126271 (http://chdk.setepontos.com/index.php?topic=12321.msg126271#msg126271)
-
Congratulations for the hard work! :D
What is the minimum time interval between photos for this camera?
-
There is an even simpler method (if you're not using a Mac and card is smaller than 64G):
- extract zip to card (all files and directories)
- start cam with the PLAYBACK button, press MENU, locate "Firm update" in the bottom of the menu, execute it
-> cam will reboot, CHDK will start
- press the PLAYBACK button for a moment, then MENU to enter the CHDK menu
- navigate to "Miscellaneous stuff" -> "SD Card" and execute "Make card bootable"
- switch off the cam, take out the card, lock it, put it back in
- CHDK will automatically start from now on
edit:
clarified one of the steps, thx. WW
Thanks for your help, Should I run this "walk-through" every time I start my camera? in the last step you mentioned that "CHDK will automatically start from now on", but it didn't when i started the camera again....
and another issue, in the step before the last one, you mentioned that I have to "lock" the SD Card and put it back in. but If I lock SD Card, it is not possible to take pictures anymore since the SD Card is locked. What is missing in my understanding? should I unlock it after all steps mentioned above? I did it but no CHDK logo when I started it again.
-
but If I lock SD Card, it is not possible to take pictures anymore since the SD Card is locked.
The card needs to be locked for CHDK autoboot to work. When the cameras starts, if the card is locked, the camera firmware looks on the SD card for a file called DISKBOOT.BIN. If it finds it, it loads that file and runs it. CHDK is stored in DISKBOOT.BIN - that's how it gets loaded.
Once CHDK loads, it tricks the camera into thinking the card is not longer locked so that you can save pictures normally.
What is missing in my understanding? should I unlock it after all steps mentioned above? I did it but no CHDK logo when I started it again.
You will only get the CHDK logo if the card is correctly formatted, the CHDK files are correctly installed, and the SD card lock switch is in the LOCKED position.
-
Thanks friends, I could run CHDK on my IXUS 160 and it worked like a charm.
I just enable "remote shutter", set the "switch type" on "One Push" and "control mode" on "Normal".
Then easily connected a USB cable to camera. Whilst connecting the other end of cable to "USB port on my laptop", camera goes to "half press" mode and then by quickly unplugging the cable from "USB port on my laptop", camera goes to "full press" and picture is taken.
No DIY, No switch button, No battery, just by using a USB cable I could take pictures remotely!!! amazing!!
i would like to thank all developers and friends here who answered my questions.
I also encourage all newbies like me to start CHDK.
-
I just found a camera with firmware version 100b in the wild. I will figure out what I need to do and attempt to fetch a firmware dump of it.
-D
-
I just found a camera with firmware version 100b in the wild. I will figure out what I need to do and attempt to fetch a firmware dump of it.
Use the canon basic dumper http://chdk.wikia.com/wiki/Canon_Basic/Scripts/Dumper (http://chdk.wikia.com/wiki/Canon_Basic/Scripts/Dumper)
To run the script, you must set up an SD card for canon basic: http://chdk.wikia.com/wiki/Canon_Basic/Card_Setup (http://chdk.wikia.com/wiki/Canon_Basic/Card_Setup)
If you already have CHDK on another camera, you can use the Lua script on that page to prepare the card, but make sure to unlock the card or delete the diskboot before putting it in the camera you want to dump.
Once you have the dump, upload it to a file hosting site.
-
I managed to follow the instructions and the resulting firmware for ELPH 160 version 100b is at:
http://tenrec.builders/cameras/elph160-100b/PRIMARY.BIN (http://tenrec.builders/cameras/elph160-100b/PRIMARY.BIN)
I've opened up the wiki page about how to port to a new minor firmware version.
---
Btw, the instructions for making a universal dumper image seemed very complex, all things considered. So I created an SD card image for doing it:
http://tenrec.builders/cameras/canon-universal-dumper.zip (http://tenrec.builders/cameras/canon-universal-dumper.zip)
Instructions for this are simple:
(1) Download file
(2) Unzip file
(3) Use win32 disk imager or equivalent mac/linux program to write to sd card.
(4) Put sd card in camera
(5) Press play button to start camera
(6) Press function button
(7) Put sd card in reader and copy off PRIMARY.BIN
-D
-
I've opened up the wiki page about how to port to a new minor firmware version.
I ran rebuild-stubs on your 100b dump, all the addresses are identical, so 100b should be supportable as a copy of 100a. (see ixus140 for an example)
I haven't actually looked back through the thread to see if anyone has seen this firmware before.
edit:
searching the print view, it looks like this is the first mention of 100b.
http://tenrec.builders/cameras/canon-universal-dumper.zip (http://tenrec.builders/cameras/canon-universal-dumper.zip)
Instructions for this are simple:
(1) Download file
(2) Unzip file
(3) Use win32 disk imager or equivalent mac/linux program to write to sd card.
(4) Put sd card in camera
(5) Press play button to start camera
(6) Press function button
(7) Put sd card in reader and copy off PRIMARY.BIN
Thanks :)
-
I've added 100b as a copy of 100a. This is only relevant for 1.5 builds, since 1.4 doesn't have the compatibility check.
The 1.4 build I posted earlier in http://chdk.setepontos.com/index.php?topic=12321.msg126202#msg126202 (http://chdk.setepontos.com/index.php?topic=12321.msg126202#msg126202) should work on both 100a and 100b cameras.
-
I have a question, but maybe it's not the right moment for this question. You know? I'm just gonna ask my question. This is the IXUS160 and it has a digit IV+ processor isn't it then just posssible that this firmware/chdk release works for the sx 520 hs (with a bit of tweaking of course)? Or am I just being stupid?
-
This is the IXUS160 and it has a digit IV+ processor isn't it then just posssible that this firmware/chdk release works for the sx 520 hs (with a bit of tweaking of course)?
Every camera model needs its own version of CHDK - you can't use CHDK from one camera model on a different model. Having said that, there is a lot of similarity between all CHDK ports but the difference are more than just "a bit of tweaking".
-
Added the
full 16MB dump by duerig from this forum post (http://chdk.setepontos.com/index.php?topic=12321.msg126499#msg126499) to the CHDK P&S FW dumps (https://drive.google.com/folderview?id=0B08pqRtyrObjTy11Y003Sk1lYTQ#list) repository.
-
Hi,
currently I have managed to launch CHDK in IXUS160 and it didn't crash. I didn't read that part why camera is "bricking", but later i will have 6 more IXUS160 I will be glad to give you "bricking" stats.
Also I used mrweerden .net libs with IXUS 135 in my project. I use simple functions such as capture picture and livestream, but I am experiencing problems with livestream. I am getting livestream picture 720x240px I would be glad to get 480, but I don't even have a clue from where to begin.
-
Also I used mrweerden .net libs with IXUS 135 in my project. I use simple functions such as capture picture and livestream, but I am experiencing problems with livestream. I am getting livestream picture 720x240px I would be glad to get 480, but I don't even have a clue from where to begin.
This camera has a 240 line viewport, see http://chdk.setepontos.com/index.php?topic=12321.msg126063#msg126063 (http://chdk.setepontos.com/index.php?topic=12321.msg126063#msg126063)
-
This camera has a 240 line viewport, see http://chdk.setepontos.com/index.php?topic=12321.msg126063#msg126063 (http://chdk.setepontos.com/index.php?topic=12321.msg126063#msg126063)
ok then what params I should use to call viewfinder to get picture same as at CHDK PTP application with checkbox "scale for A/R" checked?
-
ok then what params I should use to call viewfinder to get picture same as at CHDK PTP application with checkbox "scale for A/R" checked?
You'll need to scale the live view image on the PC side. The aspect ratio info is available (in the live view stream) as metadata, but you can just scale the image to 4:3 if you don't use any special modes on the camera.
-
Hello Guys,
I'm new here.
I'm interesting in long explosure photographing.
I bought an IXUS160 because CHDK beta version is avaible.
Now CHDK is under testing, but some functinos I cannot use propely, ISO setting and darkframe subtraction switch.
If I set ISO 3200 one of the pictures will be capture by ISO 3200, but all of them use ISO 1600.
For example: The camera shoot 7 pics with ISO1600, 8th with ISO3200, and the others are ISO1600 again, but the ISO setting was constantly 3200.
The darkframe subtraction cannot switch off, regardless of the switch state subtraction is alwalys ON.
These are known "bugs" or my mistake? At all, this is very useful device.
Thanks guys to the this big effort to develop it.
My favourite stuffs:
Max. shutter speed is 250s, selectable filter, manual focus, remote shooting...
I love it!Best Regards,Joseph
-
If I set ISO 3200 one of the pictures will be capture by ISO 3200, but all of them use ISO 1600.
For example: The camera shoot 7 pics with ISO1600, 8th with ISO3200, and the others are ISO1600 again, but the ISO setting was constantly 3200.
According to the Canon specifications, this camera only supports ISO1600 http://shop.usa.canon.com/shop/en/catalog/powershot-elph-160-black
You might see 3200 in the EXIF, but it probably doesn't affect the actual exposure. CHDK overrides usually don't let you use higher ISO than the canon firmware does.
The darkframe subtraction cannot switch off, regardless of the switch state subtraction is alwalys ON.
This sounds like a bug. Can you describe how you tested it? Are you using CHDK shutter overrides, or the camera "long shutter" mode?
-
Hello Reyalp,
Yes, you right this camera can ISO1600 according the spec.
I made a lot of pictures from the night sky, if I set iso1600 all of the pictures has the same brightness.
But if I used ISO3200, some of the pictures was more brighter and noisier.Now I took some test pics. Camera in Night mode. CHDK settings: exp:2s, ISO3200, light conditions are the same, the camera is fixed.
The first picture is bright, but further pictures are darker than the first.(-1EV difference )
If I go to playback mode then go back shooting mode, and take a picture, the picture will be as bright as the very first.
If I make this procedure after every shoot (go to playback mode then go back shooting mode) all of the pictures will have the same brightness (ISO3200). It is strange.
At "P" mode I cannot take pictures with ISO3200.
Regarding the subtraction:
I try: - "night" mode + CHDK DF subtraction OFF
- "P" mode + CHDK long exp.+ DF subtraction OFF
- "night mode" + CHDK DF subtraction OFF
- "night mode"+ CHDK long exp. + CHDK DF subtraction OFF
The picture taking time alwalys double than the adjusted exp. time.
Best Regards,
Joseph
-
The darkframe subtraction cannot switch off, regardless of the switch state subtraction is alwalys ON.
I think dark frame control can be made working* with the patch at the bottom of this post.
* There's one catch: the selected dark frame setting does not affect the next photo, only the ones taken afterwards.
Test version attached (diskboot only), feedback would be appreciated.
The patch and the test build doesn't address the other issues mentioned above.
Index: platform/ixus160_elph160/sub/100a/stubs_min.S
===================================================================
--- platform/ixus160_elph160/sub/100a/stubs_min.S (revision 4525)
+++ platform/ixus160_elph160/sub/100a/stubs_min.S (working copy)
@@ -6,8 +6,8 @@
// 0xff883c54 (0x32d4), 0xff883c90 (0x54); see ixus140 0xff0a7858, 0xff0a7890
DEF(viewport_fb_d, 0x00003328)
-// guessed from sub_FF99A728 ShutterSoundTask
-DEF(_nrflag, 0x75F4)
+// see NRTBL.SetDarkSubType, ineffective for the next photo (it 'lags')
+DEF(_nrflag, 0xa4c8)
// guessed by comparing with a2500 and ixus140
DEF(active_viewport_buffer, 0x2108)
edit: test build removed
-
Perfect!
It is working as you wrote.
Many thanks.
-
It is working as you wrote.
Thanks for the report, I have made this change in both CHDK 1.4 and 1.5.
I'd like to note that it might be possible to remove the lag in darkframe control, but that would require some further research.
@reyalp
I have taken down my test build, can you refresh the build you provide?
-
Updated build attached. This build should work with 100a and 100b canon firmwares.
The usual warning about camera damage (http://chdk.setepontos.com/index.php?topic=12321.msg123736#msg123736) applies. No warranty, use at your own risk. If it destroys your camera don't blame us, but please do tell us ;)
Please do not share the zip without directing people to this post.
edit:
Port is in the autobuild now, build removed.
-
Hi,
Does anyone here have experience playing with gphoto2 to capture image from the IXUS160 which has the newest CHDK installed?
I recently met a really strange problem:
I made this IXUS160 working on my old Ubuntu machine, which has gphoto2.5.8, libgphoto2.5.8, and libgphoto2_port 0.12.0, able to --auto-detect and --capture-image.
But when I tried the raspberry pi 2 which simply has raspbian jessie and gphoto2, gphoto2 was installed by gphoto2-updater (2.5.9), my canon DSLR cameras work well, but IXUS160 can be detected with --auto-detect but cannot capture image reporting error:
*** Error ***
Sorry, your camera does not support generic capture
ERROR: Could not capture image.
ERROR: Could not capture.
*** Error (-6: 'Unsupported operation') ***
And I tried my new ubuntu system, installed gphoto2 with gphoto2-updater (2.5.9), the same problems...
I'm stuck here for some days, any hints?
Many thanks,
Elaine
-
I recently met a really strange problem:
I made this IXUS160 working on my old Ubuntu machine, which has gphoto2.5.8, libgphoto2.5.8, and libgphoto2_port 0.12.0, able to --auto-detect and --capture-image.
But when I tried the raspberry pi 2 which simply has raspbian jessie and gphoto2, gphoto2 was installed by gphoto2-updater (2.5.9), my canon DSLR cameras work well, but IXUS160 can be detected with --auto-detect but cannot capture image reporting error:
*** Error ***
Sorry, your camera does not support generic capture
ERROR: Could not capture image.
ERROR: Could not capture.
*** Error (-6: 'Unsupported operation') ***
And I tried my new ubuntu system, installed gphoto2 with gphoto2-updater (2.5.9), the same problems...
I'm stuck here for some days, any hints?
Many thanks,
Elaine
You might have more luck asking on a gphoto mailing list or forum. As far as I know, no recent powershots support Canon's old remote capture SDK, so if you had remote capture working with ixus160 and gphoto, gphoto must be implementing CHDK remote capture in some way. There is some mention of chdk support on http://gphoto.sourceforge.net/news/ but I don't know anything about it beyond that.
Alternatively, you could use chdkptp. A build for raspberry pi is available from https://www.assembla.com/spaces/chdkptp/documents
-
I'm stuck here for some days, any hints?
Try something like:
gphoto2 --set-config chdk_script="script code"
-
Guys,
Probably I should ask this question in chdkptp thread, but want to make quick cross- check here as well.
My goal is to build relatively cheap time-lapse machine with Ixus 160 (CHDK-ed), and raspberry pi 1st gen with HDD to store the images.
When I trying to connect it with chdkptp on raspberry, I got a message no supported camera, seems that raspberry simple dont see the camera.
Do we have ptp support embedded into chdk for ixus 160?
-
When I trying to connect it with chdkptp on raspberry, I got a message no supported camera, seems that raspberry simple dont see the camera.
Do we have ptp support embedded into chdk for ixus 160?
Yes, ptp is supported.
Do you have "USB remote" is enabled on the camera? This refers to the DIY hardware remote, not PTP, and must be off to use PTP. This is the most common reason a camera isn't recognized at all.
-
Hi Guys,
Im new to this site, and love your work.
I have an IXUS 160 and want to be able to remotely trigger it to enable some 3D mapping from a UAV. Is this possible using the firmware on the previous page? and do I follow the installation instruction in the manual.
Noob questions i know......
Thanks again, and will report back any issues.
Cheers All
-
Hi Guys,
Im new to this site, and love your work.
I have an IXUS 160 and want to be able to remotely trigger it to enable some 3D mapping from a UAV. Is this possible using the firmware on the previous page?
It should be.
and do I follow the installation instruction in the manual.
The manual is always a good place to start. If the question is whether the manual applies to this build, the answer is yes.
You may want to check out waterwingz KAP/UAV script: https://chdk.setepontos.com/index.php?topic=10822.0
-
:)
Thanks very much, I will load onto the SD and give it a go.
The wiki from the thread is very informative.
I'm going to start by trying the remote trigger from the flight controller, then move on the script.
I will be triggering via the USB port.
Thanks again.
-
There is one think about IXUS160. get_nd_present() returns 1. Where the value does comes from?
Watching at the user manual I got the following information:
Aperture: f/3.2 / f/9.0 (W), f/6.9 / f/20.0 (T)
Does the IXUS160 have an iris aperture?
-
Watching at the user manual I got the following information:
Aperture: f/3.2 / f/9.0 (W), f/6.9 / f/20.0 (T)
Does the IXUS160 have an iris aperture?
The number in the manual just tells you the effective f-stop at the minimum and maximum zoom positions. Changing the zoom position changes the lens opening size and thus the reported f-stop.
-
The number in the manual just tells you the effective f-stop at the minimum and maximum zoom positions. Changing the zoom position changes the lens opening size and thus the reported f-stop.
Yes of courcse…
I got the 3.2 in wide angle and the 6.9 in tele.
But what does the 9.0 in wide and 20.0 in tele mean?
-
The number in the manual just tells you the effective f-stop at the minimum and maximum zoom positions. Changing the zoom position changes the lens opening size and thus the reported f-stop.
Yes of courcse… I got the 3.2 in wide angle and the 6.9 in tele. But what does the 9.0 in wide and 20.0 in tele mean?
I don't know. It seems like it's too big a jump to be just from an ND filter. Those are typically the equivalent of three f-stops.
Looking at the DPReview article for the camera, it does not appear to have an adjustable aperture.
Sometimes the camera vendors play games with quoting some lens specifications in terms of "35mm equivalent" values. Might be something to do with that?
-
I don't know. It seems like it's too big a jump to be just from an ND filter. Those are typically the equivalent of three f-stops.
Looking at the DPReview article for the camera, it does not appear to have an adjustable aperture.
Sometimes the camera vendors play games with quoting some lens specifications in terms of "35mm equivalent" values. Might be something to do with that?
Yes, that’s the ND Filter. I checked it with isoinc and the ND has 3 steps. But when I set the ND with CHDK, this didn’t affect the EXIF data.
And from 3.2 to 9 and from 6.9 to 20 are nearly 3 steps.
When I point the camera near the sun, then I see that the aperture on the screen changes from 3.2 to 9. And this is seen in the EXIF as well.
I hoped I had a iris as well to get longer exposure for time-lapse but I’m happy with the cam and you can’t have everything….
-
I’m not sure if the right place to post here. But feel free to move it.
This might be interesting for other user:
I did some investigation with my IXUS160 and it looks like, that the noise reduction starts already on an exposure time around 1/7s. Typically on my other cams is > 1s.
I run a timelapse script (rawopint). The exposure time goes from approx. 0.02s to 2s. The sleep in the plot shows you how long the script slept between shots. If the noise reduction is ‘on’, sleep makes already a jump on an exposure time from 1/7s (upper plot). The lower plot shows a run with noise reduction ‘off’.
-
I would like to try slowing down the movie frame rate.
Using _EngDrvRead(0xC0F06014) to read the shadow RAM crashes the camera.
Does anyone know the correct value to use with _EngDrvRead() ?
thanks
Zweistein
-
I would like to try slowing down the movie frame rate.
Using _EngDrvRead(0xC0F06014) to read the shadow RAM crashes the camera.
Does anyone know the correct value to use with _EngDrvRead() ?
You might check with the people over at the SDM Yahoo Groups site (or at stereoforum.org). IIRC they use that call for their 3D video sync code. Unfortunately, the current SDM source code is not available so it's a bit hard for us to help you with that here.
-
OK, I have just tried installing SDM for the S95 and in the Welcome pages it says the source code is available via email on request.
The IXUS160 does not seem to be supported.
greetings
Zweistein
-
OK, I have just tried installing SDM for the S95 and in the Welcome pages it says the source code is available via email on request.
That's good to know. Did you try making that request? It would be interesting to see how _EngDrvRead(0xC0F06014) is being used.
The original discussion about this can be found here : testing sync among more cameras (https://chdk.setepontos.com/index.php?topic=8312.msg104025#msg104025)
The IXUS160 does not seem to be supported.
Typically the SDM project can only support a camera once they "import" the essential code from the CHDK project. The IXUS160 port is fairly new so perhaps they have not found time (or user interest) to support it yet?
-
Using _EngDrvRead(0xC0F06014) to read the shadow RAM crashes the camera.
Can't imagine how that would happen. The address delivered by the sigfinder is correct.
OK, I have just tried installing SDM for the S95 and in the Welcome pages it says the source code is available via email on request.
That's good to know. Did you try making that request?
I'd be fairly surprised if "they" actually shared their source with anyone.
-
Did you try making that request?
No, as the IXUS160 is not supported, but the original information by 'funnel' is here :-
https://chdk.setepontos.com/index.php?topic=7938.0 (https://chdk.setepontos.com/index.php?topic=7938.0)
He explains how the DIGIC address 0xC0F06014 is used and that it comes from information provided by MagicLantern.
I guess that address is not correct for IXUS160 ........ for some reason.
greetings
Zweistein
-
Did you try making that request?
No, as the IXUS160 is not supported,
To debug this, it would be quite useful to see how it's used with other cameras. Complete SDM source code would allow us to do that.
-
OK, I will request it.
-
Well, that was easy enough.
The SDM developers asked me to contact them on sdm_support AT btinternet DOT com.
I also noticed that in the User Manual provided with the ASSIST download, they say :-
"SDM is only possible because of the work done by CHDK developers, those who 'port' cameras to
CHDK, the developers of MagicLantern, members of the CHDK Forum and those who test SDM.
Many contributors use 'Internet id's' rather than their real names, the main contributions relevant to SDM
are :-
EWAVR/Damir Vrancic - using usb switch for synchronised shooting
vnd - precision synchronisation for more recent cameras
MagicLantern/srsa_4c/funnel - information that indirectly led to video sync 'solution'.
Friendly CHDK developers philmoz,srsa_4c and reyalp have provided invaluable advice."
greetings
Zweistein
-
small mistake - to get the source code for SDM you need to write the email to:
sdm_source_code AT btinternet DOT com
greetings
Zweistein
-
I have enabled this port in the 1.5 and 1.4 autobuilds, currently listed as ALPHA.
The hardware damage issue hasn't been conclusively resolved, but a lot of people have been using this port without any new incidents.
-
Great news!
Not a directly CHDK related question, anyway : I get RAW file with my IXUS160 thanks to CHDK, but I can't find the correct lens correction profile in Lightroom. Somenone's got a solution to this ?
-
I get RAW file with my IXUS160 thanks to CHDK, but I can't find the correct lens correction profile in Lightroom.
Lightroom only includes lens correction profiles for cameras with native RAW function. But you can create a profile with an Adobe tool: Adobe Lens Profile Creator (https://www.adobe.com/support/downloads/product.jsp?product=193&platform=Windows). As an alternative to lightroom you can use RawTherapee (http://rawtherapee.com/). This program has manual adjustment possibilities for the lens correction.
msl
-
Thank you to everyone who helped make this port possible! As expected, the quality of my photos have increased exponentially! I'm not sure that I can accurately express my gratitude!
For convenience, here is a Camera Raw Lens Profile, and ColorChecker DNG Profile for the ELPH 160. (https://drive.google.com/folderview?id=0B7jikbgSgffHV21mYmtFOUg2TTg)
NOTE: The Lens profile does not exactly match the corrections made in-camera. The ColorChecker Profile was made by taking a photo of the image in the above Google Drive folder on a Samsung Galaxy S5 in Cinema mode at full brightness in complete darkness. It was then processed in Adobe DNG Profile Editor (https://www.adobe.com/support/downloads/thankyou.jsp?ftpID=5494&fileID=5490). This isn't a perfect solution, but it's exceedingly better than no corrections at all.
-
Booting up the camera with USB inserted gives the following ROMLOG (fw 100a):
ixus160hs_160_100a System Panic: Module = 64, Panic = 3 Occured Time 2016:05:07 10:31:09 StackDump(0xFC0 - 0x1040): 0x00000FC0 0xC0400000 0x00001974 0x00000001 0x00000003 0x19980218 0x19980218 0xFF822A3C 0x20000013 0x00000000 0x60000013 0x19980218 0x19980218 0xC0400000 0x19980218 0xFF822A3C 0x1E3CDE55 0x56FD8A78 0x9EFC1EBC 0x1E788C1C 0x3E38087C 0x5E3A163F 0x123E1E2C 0x3E6C7F08 0x1E681C3C 0x1E7C1E3C 0x3E3DBE04 0x1E3C0C3C 0x5E2C1C2C 0x1FFC1E1C 0x3E341E7C 0x0E7E163D
pastebin because I cannot paste here :\
http://pastebin.com/raw/mKQbetp7
-
Booting up the camera with USB inserted gives the following ROMLOG (fw 100a):
Nice. Does it make any difference if you enable (or disable) USB remote in the CHDK menu?
-
Booting up the camera with USB inserted gives the following ROMLOG (fw 100a):
Nice. Does it make any difference if you enable (or disable) USB remote in the CHDK menu?
I was just testing forcing the USB bit, I think I managed to break it :) (overextending the zoom a few times when doing a failed booting = boom)
I will now try masking the usb bit, that was the second option...oh well...
edit: false alarm, testing the usb bit mask...
-
Booting up the camera with USB inserted gives the following ROMLOG (fw 100a):
Nice. Does it make any difference if you enable (or disable) USB remote in the CHDK menu?
physw_status[USB_IDX] = physw_status[USB_IDX] & ~(USB_MASK);
does the trick for bootup, why is that happening? Is this something new in the chdk land? Since I need ptp I think I will try to mask the bit later when the CHDK initialization has been done...
spoke too soon, issue persists, weird.. maybe I should mask it earlier?
-
Okay. Can you explain what is happening, without making it unreadable?
If you're changing the source, post some kind of a diff.
-
Okay. Can you explain what is happening, without making it unreadable?
If you're changing the source, post some kind of a diff.
Commenting out calls to:
CreateTask_low_my()
and
init_required_fw_features()
make the camera work as expected (except when ptp-ing will shoot twice O_o), I will now try enabling features at once in order to identify which task is locking the camera up
edit: the culprit seems to be "init_required_fw_features()" but I'm not entirely convinced...ewww
-
edit: the culprit seems to be "init_required_fw_features()" but I'm not entirely convinced...ewww
In case you're hunting for the infamous bug of this port, init_required_fw_features() was introduced much later.
-
edit: the culprit seems to be "init_required_fw_features()" but I'm not entirely convinced...ewww
In case you're hunting for the infamous bug of this port, init_required_fw_features() was introduced much later.
what was it? I please don't make me skim through 45 pages :)
However I don't want to call victory too soon but I'm looping through:
- remove camera power
- apply (enable) USB cable
- power on camera
- connect to camera and run commands (various scripts + shooting)
no error so far with "init_required_fw_features()" commented out.
I suppose I'm not using its features (hence not hitting bugs fixed by this fixup addition) but now I'm getting a correct boot-up when the USB cable is plugged in...this camera is weird.
-
what was it? I please don't make me skim through 45 pages :)
https://chdk.setepontos.com/index.php?topic=12321.msg123736#msg123736
I'm getting a correct boot-up when the USB cable is plugged in...this camera is weird.
What is happening when you use an official build? No-one mentioned startup problems when USB is connected.
Although an earlier generation, but my ixus150 boots normally in presence of a USB connection.
-
what was it? I please don't make me skim through 45 pages :)
https://chdk.setepontos.com/index.php?topic=12321.msg123736#msg123736 (https://chdk.setepontos.com/index.php?topic=12321.msg123736#msg123736)
I'm getting a correct boot-up when the USB cable is plugged in...this camera is weird.
What is happening when you use an official build? No-one mentioned startup problems when USB is connected.
Although an earlier generation, but my ixus150 boots normally in presence of a USB connection.
I once tried an ixus140 (iirc) and it performed OK, so this is new also for me..but then again it has been a while since I last played with CHDK :)
regarding that post you linked:
Actually in the crash itself, the camera extended the lens to far to a point it couldn't retract. I tried rebooting normally a couple of times, but it kept giving the lens error and not retracting. I left it on its back overnight. Next morning I retried and it retracted normally! As my washing machine was on and it vibrates the floor a lot, it might have shaken the lens motor back or such. Or I just got lucky...
I experienced this very same issue today, it happened like this:
- remove power to camera
- insert usb
- give power to camera
< camera tries to bootup, fails and extends the lens a little more than it was before >
- goto "give power to camera" a few more times
< at this point lens is far out >
- now the lens cannot retract anymore with or without chdk active
- fiddle a bit with power on/off
- get the camera to finally retract the lens
Now, after building and running current trunk without "init_required_fw_features()" this didn't happen anymore..
At this point I'm not sure on what to think, I would like to try this very same procedure on another camera (same model), hopefully a friend will give to me in the next days..
-
pastebin because I cannot paste here :\
http://pastebin.com/raw/mKQbetp7
You can attach files.
-
pastebin because I cannot paste here :\
http://pastebin.com/raw/mKQbetp7 (http://pastebin.com/raw/mKQbetp7)
You can attached files.
right, sorry, I wanted to avoid cluttering the forum with such small files..
however reading my previous responses I want to add that the issues were experienced with current chdk trunk from mighty-hoersche.
-
I experienced this very same issue today, it happened like this:
- remove power to camera
- insert usb
- give power to camera
< camera tries to bootup, fails and extends the lens a little more than it was before >
This seems weird to me because
1) The camera should never extend the lens when CHDK is booted, unless you hold the power button down (the code for this is present in boot.c, but it could be wrong)
2) The Canon firmware should never extend the lens when it thinks USB is present, even without CHDK.
Assuming your camera is still working (not clear to me from your posts) if you click the power button to start when USB is not present, does the lens extend?
I would be surprised if init_required_fw_features is actually relevant, but if so, it should be fairly simple to create the required eventflags and semaphores directly, as done on g7x.
-
I experienced this very same issue today, it happened like this:
- remove power to camera
- insert usb
- give power to camera
< camera tries to bootup, fails and extends the lens a little more than it was before >
This seems weird to me because
1) The camera should never extend the lens when CHDK is booted, unless you hold the power button down (the code for this is present in boot.c, but it could be wrong)
2) The Canon firmware should never extend the lens when it thinks USB is present, even without CHDK.
Assuming your camera is still working (not clear to me from your posts) if you click the power button to start when USB is not present, does the lens extend?
I would be surprised if init_required_fw_features is actually relevant, but if so, it should be fairly simple to create the required eventflags and semaphores directly, as done on g7x.
I saved the camera fortunately.
I was holding the power button down, yes, and I think the issue was related to semaphores in play mode. In fact the issue was reproducible even by powering on through the playback button.
There may be other minor things that I have overlooked (I confess I tried hacking fast), but what I said is more or less what I experienced.. now I'm not home anymore unfortunately so I cannot make further tests..
What I'm sure about is that my now working build vs vanilla from mighty hoersche has that function I mentioned commented out. (I compiled locally with gcc4.6 arm-elf)
-
I experienced this very same issue today, it happened like this:
- remove power to camera
- insert usb
- give power to camera
When you say "remove power" or "give power", what does that mean? Were you using something other than the battery?
-
I was holding the power button down, yes, and I think the issue was related to semaphores in play mode. In fact the issue was reproducible even by powering on through the playback button.
With CHDK installed, the lens fully retracted, and without USB:
If you click play, does the lens extend?
If you click power does the lens extend?
If you hold power does the lens extend?
If the camera crashed with the lens not completely closed, it's likely the camera will try to move it regardless of the how it was powered on, so the above should be tested after powering down normally.
I was holding the power button down, yes, and I think the issue was related to semaphores in play mode.
The semaphores and eventflags affected by init_required_fw_features should be specific to eventprocs that are never called in normal Canon firmware operation and are only used by CHDK when the corresponding overrides are issued. The whole reason we need these functions is that they are not created by default and modern dryos crashes if it tries to use initialized synchronization objects (see https://chdk.setepontos.com/index.php?topic=12516.0).
-
Right, sorry, i made a fake battery at 3.8something volts.
I didnt connect the middle pin to anything (not the first time I try this).
Do you think it could matter?
Unfortunately I destroyed the original battery in the process of making the fake adapter.
-
I didnt connect the middle pin to anything (not the first time I try this).
Do you think it could matter?
Probably not. None of Chinese knock-off adapters I have connect it (I'm not sure if the real canon ones do), and they seem to work fine.
Power supply problems could cause all kinds of weird behavior though.
-
Well I was removing power with the lens extended, it could be then the error condition propagating then..
I guess I will have to try it again with vanilla...
However I think I tried repeating this with my own fw but everything worked...I share your concerns though, Im kind of burned from this crazy weekend : )
-
Well I was removing power with the lens extended, it could be then the error condition propagating then..
I would strongly suggest doing a proper shutdown if you can, e.g. post_levent_to_ui('PressOffButton'). That said, if powering on with the lens extended triggers this problem, that's very good information.
Normally on these cameras, when the camera crashes with the lens out, it retracts on the next power up, even if powering on in rec. Maybe having USB present interferes with this process on this camera.
If you are willing to experiment, it would be interesting to see if this happens without CHDK: cut power with lens out, connect USB, connect power.
-
Well I was removing power with the lens extended, it could be then the error condition propagating then..
I would strongly suggest doing a proper shutdown if you can, e.g. post_levent_to_ui('PressOffButton'). That said, if powering on with the lens extended triggers this problem, that's very good information.
Normally on these cameras, when the camera crashes with the lens out, it retracts on the next power up, even if powering on in rec. Maybe having USB present interferes with this process on this camera.
If you are willing to experiment, it would be interesting to see if this happens without CHDK: cut power with lens out, connect USB, connect power.
well the power-cycle was the last resort for coming back from unsolvable usb errors (usb and arm socs...ewww)..
Hopefully I will make some proper (more scientific) tests next week or so, thanks reyalp and srsa for your support!
-
I finally had the chance to test more what was going on with a couple of ixus160 and here are the results:
1) I found out that the camera having issues booting up etc. was a faulty camera (!) The issues were reproducible in "chdk-usage" but apparently the camera was working ok in "normal use"..a few other cameras I tried were working as expected! I don't know how and why that specific camera was giving issues but now I guess it's on its way for a RMA
2) I also found out you shouldn't use no-brand SD cards, because they will make your life a lot worse..by triggering random errors here and there..
greets
-
2) I also found out you shouldn't use no-brand SD cards, because they will make your life a lot worse..by triggering random errors here and there..
What sort of errors? If it's like https://chdk.setepontos.com/index.php?topic=12795.0 it might not just be due to cheap cards.
-
2) I also found out you shouldn't use no-brand SD cards, because they will make your life a lot worse..by triggering random errors here and there..
What sort of errors? If it's like https://chdk.setepontos.com/index.php?topic=12795.0 (https://chdk.setepontos.com/index.php?topic=12795.0) it might not just be due to cheap cards.
the major issues were found when I was trying shoot()-save-download and the SD card was injecting random lags and/or errors during shooting and downloading, changing the card to a better one solved the trick.. I think I may have sporadically even experienced random chdk errors when booting up...however upon discovery I cut the SD in a half :haha hence unfortunately I cannot reliably reproduce this anymore..
-
I'm a bit confused, but then I'm a noob at this.. I want to use the ELPH160 for a book scanner using a Pi. Is this commonly done, and are people using that camera with this software now without problems, or are thereproblems? Are there just two reports that cams were bricked without any knowledge of why? Can someone describe where we are with this, or I do I need to look for another cam to use?
-
I'm a bit confused, but then I'm a noob at this.. I want to use the ELPH160 for a book scanner using a Pi. Is this commonly done, and are people using that camera with this software now without problems, or are thereproblems?
I'd suggest looking on http://www.diybookscanner.org/
The 'pi-scan' project linked from there mentions using ixus160/elph160 https://github.com/Tenrec-Builders/pi-scan
Are there just two reports that cams were bricked without any knowledge of why? Can someone describe where we are with this
The bricking happened in early test builds. The exact cause is not known for certain, but there have been no additional reports.
-
IXUS160 zoom crash
Hello, and thanks for developing this wonderful software.
I'm in the middle of testing IXUS160, using chdkptp as client. Most of the functions seem to work and be stable. But I have problems with camera crash (power off with lens still out) when zooming. It's very easy to reproduce, just fiddle the zoom back and forth:
___> c
connected: Canon IXUS 160, max packet size 512
con> rec
con 1> luar set_zoom(60)
con 2> luar set_zoom(0)
con 3> luar set_zoom(60)
con 4> luar set_zoom(0)
ERROR: I/O error
___>
Both chdk and chdkptp are the latest one can get (built yesterday). Computer platform seems to make no difference, ubuntu+gnome behaves same as gui-less centos.
I noticed different crash probablility with different zoom values. 60 seems to stand few times, whereas 35 causes almost immediate crash.
I also tried A2500 at the end of exactly same cable. With that, no problems at all, so the problem is more likely at the camera end.
Any comments on this? Anyone else experiencing zoom crash? I would like to provide more accurate information (logs, dumps, whatever) but for that I would need a bit of assistance, what is needed and how to get it. (Maybe there a problem reporting guide somewhere, just did not hit my eye)
esa
-
I'm in the middle of testing IXUS160, using chdkptp as client. Most of the functions seem to work and be stable. But I have problems with camera crash (power off with lens still out) when zooming. It's very easy to reproduce, just fiddle the zoom back and forth:
I would like to provide more accurate information (logs, dumps, whatever) but for that I would need a bit of assistance, what is needed and how to get it. (Maybe there a problem reporting guide somewhere, just did not hit my eye)
If you can post a romlog (http://chdk.wikia.com/wiki/Debugging#Camera_crash_logs_.28romlog.29) that might be helpful.
If you can build CHDK yourself, try increasing CAM_NEED_SET_ZOOM_DELAY in platform/ixus160_elph160/platform_camera.h
IIRC, 300 is largest value we use in other ports.
-
ok, thanks
below is romlog from this short session:
con 5> rec
con 6> luar set_zoom(35)
ERROR: I/O error
ASSERT!! FocusLensController.c Line 1064
Occured Time 2016:08:09 19:28:08
Task ID: 14614561
Task name: PhySw
SP: 0x0059DB0C
StackDump:
0x00000000
0x00000000
0xFF98C9AC
0x00000428
0x00001CE8
0x00000001
0x00001CE8
0x00000001
0x19980218
0x19980218
0x19980218
0x19980218
0xFF98D50C
0x00000BB4
0x0000EF74
0x00001CE8
0xFFB7E858
0x00000000
0x00000BB4
0x0000EF74
0x00040100
0x00286AD0
0xFFB7E8B0
0x00000BB4
0x001A6D48
0x00040100
0x00199A5C
0x00000BB4
0x00000BB4
0x00000200
0x0018FF5B
0x00000023
0x00000B91
0x00040100
0x0018FF99
0x0018FF71
0x00286AD0
0x00286DE0
0x00612CED
0x00612CE1
0x006173D3
0x00288620
0x00000010
0x00000000
0x00288628
0x006107E0
0x00000000
0x00286DE0
0x00040100
0x00286AD0
0x0061C143
0x00000000
0x00286AD0
0x00286DE0
0x00288870
0x002885C8
0x0028886C
0x00288578
0x00000001
0x00000000
0x00000000
0x006107E0
0x00000005
0x006170CD
0x00286AD0
0x00000000
0x00627534
0x001A6868
0x0061743D
0x00286AD0
0x00616EBB
0x00286AD0
0x006173ED
0x00286DE0
0x00000000
0x00286AD0
0x00000000
0x00286AD0
0x00000000
0x00627534
0x001A6868
0x19980218
0x19980218
0x19980218
0x19980218
0x0018BB21
0x0059DC28
0x00616EAF
0x00629650
0x00000000
0x0060E000
0x00629650
0x00000020
0x00286AD0
0x00189D69
0x001A5C64
0x00189E53
0x0062728C
0x00000000
0x00627534
0x00000000
0x0003FCB4
0x006174E9
0x00000000
0x0062728C
0x00000000
0x006139F9
0x006139CD
0x001A6868
0x00000001
0xA32F1C9E
0x001A6868
0x0019628D
0xA32F1C9E
0x00195CF5
0x00610838
0x0059DD04
0x00629650
0x00000000
0x00000020
0x0060FDD0
0x0060FDD0
0x00286AD0
0x0059DD30
0x0061608B
0x00000002
0xFFFFFFFF
0x00610446
ShootConDump:
0f 0f 0f 0f 0f 0f 0f 0f 0f 0f
CameraConDump:
07 0a 02 0d 09 01 0f 0f 0f 0f
00239840: UI:DispSwCon_MuteOffPhysicalScreen
00239840: UI:LogicalEvent:0x00003110:adr:0,Para:0
00239840: UI:DispSwCon_TurnOnDisplayDevice
00239840: UI:UI_StrobeCon_Start
00239840: UI:LogicalEvent:0x00003136:adr:0,Para:0
00239840: UI:_ManagePTMProperty
00239850: UI:LogicalEvent:0x0000301c:adr:0,Para:0
00239850: SS:ModChg
00239850: SS: Evf=1
00239850: SS: 0069->8005
00239850: SS: Asp 0000->0000
00239860: SS:ModChg*
00239860: UI:_DecideCaptureMode
00239860: UI:_StartStill
00239860: UI:_ContiCount->0(5632)
00239860: UI:DSIC:42,6
00239860: UI:DSIC:1b,0
00239890: UI:VTMUnLock
00239900: UI:TerminateDeliverToZoomController
00239900: UI:OPTICAL_ZOOM_POS
00239900: UI:DispSwCon_TurnOnDisplayDevice
00239900: UI:LogicalEvent:0x0000313e:adr:0,Para:0
00239900: UI:_EnrySRec
00239900: UI:DCIC:1,0
00239900: UI:CaptModeChanger_CheckRTCRrepared
00239900: UI:DispSwCon_MuteOffPhysicalScreen
00239900: UI:_ChangeDisplayOut
00239900: UI:Window MuteOff
00239900: UI:MuteOffPhysicalScreen
00239900: UI:UnpressZoomLever
00239900: UI:DSIC:e9,0
00239900: UI:_DecideModeDial
00239900: UI:No Change Capture Mode
00239900: UI:DSIC:d4,0
00239900: UI:VTMLock
00239900: UI:VTMReduuce
00239910: UI:LogiEvnt_NotPowerType:0x000009a4:adr:0,Para:0
00239910: UI:LogiEvnt_NotPowerType:0x000009a2:adr:0,Para:0
00239920: UI:DSIC:6a,0
00239920: UI:VTM SW
00239920: UI:VTMUnLock
00240000: UI:VTMLock
00240010: UI:VTMUnLock
00241250: SS:ChargeComplete
00241370: UI:VTMLock
00241380: UI:DSIC:a9,1
00241380: UI:DSIC:55,0
00241380: UI:VTMUnLock
00243390: UI:VTMLock
00243390: UI:VTMUnLock
00245870: UI:VTMLock
00245880: UI:VTMUnLock
00249950: UI:DSIC:13,0
00249950: UI:DispSwCon_MuteOnPhysicalScreen
00249950: UI:Window MuteOn
00249950: UI:MuteOnPhysicalScreen
00249950: UI:DispSwCon_TurnOffBackLight
00249950: UI:TurnOffBackLight
00249950: UI:DCIC:10,0
00249950: UI:VTMLock
00249950: UI:VTMUnLock
00249950: UI:LogicalEvent:0x00003136:adr:0,Para:0
00249950: UI:VTMLock
00249950: UI:VTMReduuce
00249950: UI:VTMLock
00249960: UI:VTMUnLock
00249960: UI:DSIC:16,0
00249960: UI:VTMLock
00249960: UI:VTMReduuce
00249960: UI:VTMLock
00249970: UI:VTMReduuce
00249970: UI:VTMLock
00249970: UI:VTMReduuce
00249970: SS:StopFdr 1
00250420: UI:DispSwCon_TurnOffDisplayDevice
00250420: UI:DispSwCon_TurnOffBackLight
00250420: UI:TurnOffDisplay
00250470: UI:DispSwCon_TurnOffDisplayDevice
00250470: UI:DispSwCon_TurnOffBackLight
00250470: UI:VTM SW
00250470: UI:VTMUnLock
00261290: UI:DSIC:21a,0
00261300: SS:OptAt=35 3
00261350: UI:VTMLock
00261350: UI:VTMUnLock
00261440: UI:VTMLock
00261440: UI:VTMUnLock
-
ok, thanks
below is romlog from this short session:
con 5> rec
con 6> luar set_zoom(35)
ERROR: I/O error
ASSERT!! FocusLensController.c Line 1064
Occured Time 2016:08:09 19:28:08
Task ID: 14614561
Task name: PhySw
SP: 0x0059DB0C
This looks a lot like the problem that increasing CAM_NEED_SET_ZOOM_DELAY would address. Did you try that? I thought from your earlier post that you were set up to build CHDK, but if not I can post a test build.
-
This looks a lot like the problem that increasing CAM_NEED_SET_ZOOM_DELAY would address. Did you try that? I thought from your earlier post that you were set up to build CHDK, but if not I can post a test build.
[/quote]
I built chdkptp and downloaded autobuilt chdk. It might take considerable time to learn to build chdk so I would appreciate if you could post a test build.
-
No problem. Here's a test build with zoom delay 300
-
No problem. Here's a test build with zoom delay 300
Big, huge, enormous thanks!!
I have been torturing my poor ixus with various scripts some hours now, zooming and focusing back and forth, taking pictures in between, etc. Not a single crash!
(excluding crash from "set_prop(221,1)", Differing from comment at PROPSET6.LUA, in ixus160 M1 pic size value seems to be 2, leaving 1 being something undefined...)
Increased delay seems also fix the aflock crash. Aflock behaviour seems to be a bit mystery in ixus160. It looks like aflock is not needed to achieve manual focus. However, with aflock focus behaves differently than without it. (With aflock there seems to be some kind of ceiling, focus does not change anymore after certain value)
Noticed also something which is very good news, at least for me: Zoom positioning accuracy in ixus160 is very good, totally at different level compared to A2500
-
I have been torturing my poor ixus with various scripts some hours now, zooming and focusing back and forth, taking pictures in between, etc. Not a single crash!
Thanks for confirming, I've checked this in for both 1.4 and 1.5
(excluding crash from "set_prop(221,1)", Differing from comment at PROPSET6.LUA, in ixus160 M1 pic size value seems to be 2, leaving 1 being something undefined...)
Can you check what the value is for each resolution? In chdkptp, you can just use =get_prop(221) after highlighting the resolution in the func menu.
Aflock behaviour seems to be a bit mystery in ixus160. It looks like aflock is not needed to achieve manual focus. However, with aflock focus behaves differently than without it. (With aflock there seems to be some kind of ceiling, focus does not change anymore after certain value)
When you say "ceiling" you mean you can't set_focus beyond a certain distance unless you use aflock?
FWIW, CHDK behavior with AF is slightly different from aflock and MF. In AF, calling set_focus just stores a value, which is applied during shooting after the cameras normal AF process has finished. If aflock or MF is enabled, calling set_focus immediately sets the focus.
-
FWIW, CHDK behavior with AF is slightly different from aflock and MF. In AF, calling set_focus just stores a value, which is applied during shooting after the cameras normal AF process has finished. If aflock or MF is enabled, calling set_focus immediately sets the focus.
So it seems. Thanks for clarification.
When you say "ceiling" you mean you can't set_focus beyond a certain distance unless you use aflock?
Yes. For example, if I locate object, say, at 1m distance and start increasing focus, the object becomes sharp at somewhere around 1000. If I increase the value beyond that, without aflock the object becomes blur again, with aflock it stays sharp or blurs only very little.
Can you check what the value is for each resolution? In chdkptp, you can just use =get_prop(221) after highlighting the resolution in the func menu.
Sure. The values are: L = 0, M1 = 2, M2 = 3, S = 5
There is also a "W" (wide) value, which sets prop 221 value to 0. Maybe "W" has effect on some other prop. I took a propdump with "L" and "W" setting, below is the diff.
$ diff PROPDUMP.LOG_L PROPDUMP.LOG_W
67c67
< [65]= 0,
---
> [65]= 3100,
94c94
< [92]= 0,
---
> [92]= 5152,
106c106
< [104]= 0,
---
> [104]= 5152,
117c117
< [115]= 0,
---
> [115]= 1,
250c250
< [248]= 0,
---
> [248]= 3100,
274c274
< [272]= 1040,
---
> [272]= 897,
-
Now that zoom is working perfectly, I ran into focusing problems.
Example: Without chdk, I zoomed in to somewhere middle and took a photo of the camera box with autofocus. Crop of that picture attached.
Next, I booted into chdk and figured out the zoom used in previous step. Then took pictures with all possible focus settings. Crop of the best picture attached.
As you see, there is quite a difference.
It looks like the camera is not able to bring focus "close enough" . Lowest and highest possible focus number seems to change with the zoom. With example zoom (45) the best focus is 1014 and it is also the lowest.
Process before shoot was:
luar set_prop(143,2)
luar set_zoom()
luar set_aflock(1)
luar set_focus(1014)
I also tried to set focus mode (prop 6) into manual but it made no difference.
Any idea?
-
Now that zoom is working perfectly, I ran into focusing problems.
Example: Without chdk, I zoomed in to somewhere middle and took a photo of the camera box with autofocus. Crop of that picture attached.
Next, I booted into chdk and figured out the zoom used in previous step. Then took pictures with all possible focus settings. Crop of the best picture attached.
Does it happen if you just have chdk running, and do everything else the same as the no CHDK case? E.g. zoom manually and use auto focus? Or does it only happen when you use set_focus and/or set_zoom?
Any idea?
If your commands are in a script, you might need some delay in between some of them.
You can try using set_mf() instead of set_aflock()
-
Does it happen if you just have chdk running, and do everything else the same as the no CHDK case? E.g. zoom manually and use auto focus? Or does it only happen when you use set_focus and/or set_zoom?
It looks like the autofocus behaves exactly same with or without CHDK. It works also from command line with press('shoot_half')
With no zoom or with very little zoom (under 10) it is possible to reach correct focus with set_focus(). There is even some room, you do not have to set focus value as low as you could.
It looks like with higher zoom values the minimum focus value is too high. Thus set_focus() is not able to go as low as autofocus is. For example, with full zoom (100) lowest possible focus value is 1300, which is still blur, and setting higher value only makes it worse. So the correct value is probably somewhere under 1300
Are these minimum values defined somewhere in CHDK?
You can try using set_mf() instead of set_aflock()
Tried that, no difference. Looks like the result is the same with set_aflock(), set_mf() or neither, only the timing of focus is changed.
-
With no zoom or with very little zoom (under 10) it is possible to reach correct focus with set_focus(). There is even some room, you do not have to set focus value as low as you could.
It looks like with higher zoom values the minimum focus value is too high. Thus set_focus() is not able to go as low as autofocus is. For example, with full zoom (100) lowest possible focus value is 1300, which is still blur, and setting higher value only makes it worse. So the correct value is probably somewhere under 1300
On the less expensive Powershots (which usually do not have Canon MF capability) the accuracy of set_focus() is usually pretty bad. This is even the case with higher end camera and it actually varies from camera to camera. I've written at length about this in other threads on this forum.
On my "roundtuit" list is some method of building a calibration table that would provide a calibrated set_focus() by determining MoveFocusLensWithPosition values for various actual focus settings at different zoom settings. If possible, it will internally use the set mecha position functions rather than set_focus(). It would have to be calibrated for each person's camera manually but for those who care about having MF capability through CHDK, it would be a nice feature to have.
That's not to say the IXUS160 does not have it's own MF problems. But it's far from perfect on most other Powershots.
-
It looks like with higher zoom values the minimum focus value is too high. Thus set_focus() is not able to go as low as autofocus is. For example, with full zoom (100) lowest possible focus value is 1300, which is still blur, and setting higher value only makes it worse. So the correct value is probably somewhere under 1300
Are these minimum values defined somewhere in CHDK?
CHDK doesn't have a zoom dependent limit. It is possible to define hard limits, but they aren't defined for the ixus160 port.
A couple more questions:
When you tried zooming to 100, have you tried doing this manually with the camera buttons vs using set_zoom?
If you focus with AF at a distance you can focus with set_focus, what does get_focus return?
FWIW, my elph130 appears to be able to set_focus at about the same distance as minimum AF, around 1300 mm. It doesn't appear to be affected by zoom method used.
That's not to say the IXUS160 does not have it's own MF problems. But it's far from perfect on most other Powershots.
I think what gaphill described is something quite different: The focus distance *range* accessible to set_focus is different from what the canon AF can do.
-
I think what gaphill described is something quite different: The focus distance *range* accessible to set_focus is different from what the canon AF can do.
Could be different.
But my ongoing theory is that Canon AF does a closed loop focus based on "rate of change" contrast that does not "know" the actual distance. Our set_focus() hack invokes some sort of open loop setting of the lens mecha position - probably via a internal table lookup or linear function on Canon's part. On the better cameras with actual MF, Canon takes steps to calibrate this function but the low end Powershots just get a guesstimate.
So MF accuracy involves a lot of luck. And it would thus make sense that the "focus distance *range* accessible to set_focus is different from what the canon AF can do."
Or maybe I'm blowing smoke. After a couple of years chasing this, I don't know.
-
When you tried zooming to 100, have you tried doing this manually with the camera buttons vs using set_zoom?
If you focus with AF at a distance you can focus with set_focus, what does get_focus return?
set_zoom() vs. manually behaves the same. Here's kind of "minimum session" of how to get focus confused:
___> c
connected: Canon IXUS 160, max packet size 512
con> rec # After this driving to max zoom manually
con 1> rs # Result: sharp image
con 4> luar return get_focus()
5:return:1300
con 5> luar set_focus(1300)
con 6> rs # Result: blur image
con 9> luar return get_focus()
10:return:1300
On the second question: I used zoom 0 where manual focus works. Located subject at to distance 300, 400 and 500 and half-pressed shutter until the focus indicator turned green. Then immediately red get_focus(). Here's what I got: 300 -> 260, 400 -> 320, 500 -> 380
It looks like values set by autofocus are somewhat constantly smaller than the actual distance. Probably not the source of the problem but might just make it worse.
Waterwingz theory matches with this test: I set zoom into 44. Lowest possible focus value seems to be 1014, which (assuming focus number equals subject distance) feels way too high. With half press, the camera is able to autofocus into subject at distance 400, producing nice sharp picture. And the camera still thinks the focus value is 1014 when queried by get_focus(). So it really looks like the camera has no clue about the actual distance, it just (intelligently) drives the focus motor back and forth until the centerpiece of the image is sharp enough.
So it looks like mf mecha positions (and more importantly the limits of it) might well be generated by some left-hand-crafted function or table.
Is it somehow possible to set/query mecha position from lua? (I'm willing to take the risk of damaging the camera) Or is there some not-extremely-hard way to overwrite camera-given limits of focus value? (of course if there is a table which just ends too early then it does not help)
-
Is it somehow possible to set/query mecha position from lua? (I'm willing to take the risk of damaging the camera)
I've attached an old short script that manually sets a focus position and then reads back the focus value and the mechanical position. You will need to set Enable Lua Native Calls [ * ] in the Miscellaneous menu.
I couldn't find any thing where I had actually set the mechanical position and tested the script. But here are a few links if you are feeling adventurous.
Re: Porting A410 - help wanted (https://chdk.setepontos.com/index.php?topic=2597.msg80181#msg80181)
Re: A570is- Latest Build from svn problem resolved (I think...) (https://chdk.setepontos.com/index.php?topic=396.msg3076#msg3076)
Re: Manual Focus @ Infinity not working (https://chdk.setepontos.com/index.php?topic=12062.msg118282#msg118282)
Or is there some not-extremely-hard way to overwrite camera-given limits of focus value? (of course if there is a table which just ends too early then it does not help)
Nothing that I know about. You'll probably need to do a lot of disassembly and wading through the camera code to figure that one out.
-
On the second question: I used zoom 0 where manual focus works. Located subject at to distance 300, 400 and 500 and half-pressed shutter until the focus indicator turned green. Then immediately red get_focus(). Here's what I got: 300 -> 260, 400 -> 320, 500 -> 380
This is interesting.
It looks like values set by autofocus are somewhat constantly smaller than the actual distance. Probably not the source of the problem but might just make it worse.
One possible source of differences is mixing up distance to lens vs distance to sensor. There are some functions that make this distinction in the firmware, so if CHDK used the wrong one somewhere, that could result in discrepancies. However, that shouldn't result in >10cm difference on a compact like this.
Waterwingz theory matches with this test: I set zoom into 44. Lowest possible focus value seems to be 1014, which (assuming focus number equals subject distance) feels way too high. With half press, the camera is able to autofocus into subject at distance 400, producing nice sharp picture. And the camera still thinks the focus value is 1014 when queried by get_focus(). So it really looks like the camera has no clue about the actual distance, it just (intelligently) drives the focus motor back and forth until the centerpiece of the image is sharp enough.
Yeah, that makes sense, and fits with waterwingz theory.
FWIW, the specs give the ixus160 minimum focus distance at max zoom as 1.3 meters.
-
I've attached an old short script that manually sets a focus position and then reads back the focus value and the mechanical position.
In the script, MoveFocusLensToDistance returned -1. I found somewhere the forum these:
call_event_proc("FA.Create")
call_event_proc("InitializeAdjustmentFunction")
After adding those, MoveFocusLensToDistance started to work. Although it does seem to do the same thing as set_focus() and obey same limits.
I couldn't find any thing where I had actually set the mechanical position and tested the script. But here are a few links if you are feeling adventurous.
MoveFocusLensToPosition would likely be a sufficient workaround, but using it just hangs the camera. Maybe i160 does not have such function, at least the address not definened here (http://subversion.assembla.com/svn/chdk/trunk/platform/ixus160_elph160/sub/100a/stubs_entry.S)
-
MoveFocusLensToPosition would likely be a sufficient workaround, but using it just hangs the camera. Maybe i160 does not have such function, at least the address not definened here (http://subversion.assembla.com/svn/chdk/trunk/platform/ixus160_elph160/sub/100a/stubs_entry.S)
I don't believe it would be in your stubs_entry.S file unless it's used somewhere in the build.
You can check for it here (http://subversion.assembla.com/svn/chdk/trunk/platform/ixus160_elph160/sub/100a/funcs_by_name.csv). It shows up there as MoveFocusLensToPosition_FW.
I shouild know why the _FW is tagged onto the end and whether you need it in the string you pass to call_event_proc() but it escapes me at the moment. Hopefully srsa_4c will chime in here.
Did you look at all three function calls and experiment with the necessary parameters as posted here (https://chdk.setepontos.com/index.php?topic=12062.msg118283#msg118283) ?
edit : I'll let @srsa_4c answer by proxy : "Remove the _FW ending if you'd lke to use them from Lua" (https://chdk.setepontos.com/index.php?topic=1365.msg111670#msg111670)
-
Did you look at all three function calls and experiment with the necessary parameters as posted here (https://chdk.setepontos.com/index.php?topic=12062.msg118283#msg118283) ?
I can report some intermediate success here. MoveFocusLensToPosition hangs the camera but MoveFocusLensWithPosition was finally a success. I tested with zoom 44 (of 100) where set_focus stops into 1023. I was able to get beautifully sharp images of a subject at distance bit more then 40cm.
First parameter of MoveFocusLensWithPosition is the position as reported by GetFocusLensCurrentPosition and second seems to be speed. 100 is fast, 10 is slow and leaving the parameter out is horribly slow, causing crash in larger movement (maybe some timeout)
-
First parameter of MoveFocusLensWithPosition is the position as reported by GetFocusLensCurrentPosition and second seems to be speed. 100 is fast, 10 is slow and leaving the parameter out is horribly slow, causing crash in larger movement (maybe some timeout)
Good information.
For eventprocs, leaving the parameter out will just use whatever garbage happens to be in memory / registers, so you definitely don't want to do that.
-
For eventprocs, leaving the parameter out will just use whatever garbage happens to be in memory / registers, so you definitely don't want to do that.
Do you have any idea what MoveFocusLensWithPosition 3rd parameter could possibly be. Looks like after very long (focus-pos-searching) session camera starts to crash when position changed at max zoom. Probably due aforementioned garbage. Battery-off reboot fixes the matter
-
Do you have any idea what MoveFocusLensWithPosition 3rd parameter could possibly be. Looks like after very long (focus-pos-searching) session camera starts to crash when position changed at max zoom. Probably due aforementioned garbage.
Possible.
You generally need to look at Canon firmware disassembly to know how many parameters there are and figure out what they do. From a quick look at the elph130 dump it's not obvious to me what the 3rd param does, but in other cases the firmware seems to pass 1 or 0 to the underlying function that uses the value, so those would be my first choices to try.
Note that calling hardware control functions with random values in unknown parameters is probably one of the more risky things you can do with CHDK ;)
-
For eventprocs, leaving the parameter out will just use whatever garbage happens to be in memory / registers, so you definitely don't want to do that.
Do you have any idea what MoveFocusLensWithPosition 3rd parameter could possibly be. Looks like after very long (focus-pos-searching) session camera starts to crash when position changed at max zoom. Probably due aforementioned garbage. Battery-off reboot fixes the matter
Did you have any success with those tests?
I remember having such a problem with zooming (e.g. camera going out of focus) at a "normal" value (iirc 60 or so..)
Also set_focus(-1) couldn't fix such problem..
EDIT: script is like this (I want to focus infinity)
set_iso(100)
set_zoom(60)
set_focus(-1)
shoot()
EDIT2: the script was much more complex and it looks like some press() calls might have screwed the whole thing up! now it's working flawless...fingers crossed!
-
So, since i'm currently in the process of building a DIY bookscanner from two IXUS 160's, i naturally ran into the problem of the broken subject distance override thing. I dont want to rely on the autofocus to re-focus after each shot and would rather set the focus manually to a fixed value.
I want to share some of my findings which builds on the stuff of the last couple of posts:
Setting a custom focus distance via LUA works with the following call:
call_event_proc("MoveFocusLensWithPosition", a, 100)
Where "a" is a value from around 0 to 1840 indicating the focus position, and 100 being the focussing speed.
Whats very interesting:
a.) Using 1840 moves the minimum focus distance at zoom level 0 inside the front lense as you can see from the almost in focus dirt in pic 1.
b.) It reduces the minimum focussing distance at full zoom to a mere 50 centimeters which gives this nice magnification you see in pic 2.
c.) The reported subject distance that CHDK gets maxes out long before the MoveFocusLensWithPosition command is done moving the lens. It stops at around 1.3 meters reported subject distance (which is also the minimum focussing distance of this camera according to the datasheet).
Now i have no idea if that could damage the camera in the long term, but i think since it's willingly executing those commands they are safe. Anything above a value of 1840 will crash the camera immediately.
I'll be using that for my bookscanner together with aflock. From the few tests i have been running this method looks far more precise and reproducable than using the sd override.
Perhaps the subject distance override function for this particular ixus model (or others that suffer from this peculiar behaviour) could be overwritten to use MoveFocusLensWithPosition instead of MoveFocusLensToDistance?
-
Perhaps the subject distance override function for this particular ixus model (or others that suffer from this peculiar behaviour) could be overwritten to use MoveFocusLensWithPosition instead of MoveFocusLensToDistance?
Having spent a lot of time on getting SD override to sort of work on most CHDK cameras, I find this very interesting but not surprising. The fact that SD override works at all for cameras without Canon manual focus is mostly just luck IMHO.
Do you have any thoughts on how to calibrate the position value against actual distance? I assume it would need to be done at each zoom step.
-
Third time i'm writing this post, this board software is annoying... :lol
I started by mapping the set/get_focus values to GetFocusLensCurrentPosition. See attached file.
This creates just more confusion:
1. Between set_focus 0 and 10 the camera will assume the same focus position, get_focus returns a nonsensical 37 while GetFocusLensCurrentPosition returns 1352. This is already less than the cameras Autofocus in macro mode can achieve, which is about 1420 or about 1 cm in front of the lens.
I suppose nobody has noticed because the difference is negligible at that distance.
2. Between set_focus 10 and 16 GetFocusLensCurrentPosition changes as expected while get_focus returns more nonsense. Only at set_focus 17 do things start to make sense overall.
Since this only affects the very near field (below 1cm at zoom level 0, below ~1 meter at max zoom) it might be sufficient to map the area where GetFocusLensCurrentPosition correlates nicely with a subject distance and "guess" or extrapolate for the areas where it doesnt.
It wont be all too accurate, but i dont think anybody is expecting any level of accuracy from those crappy little cameras.
Besides, i dont get the need for setting a subject distance in cm anyways. I can only gauge the distance to the subject very roughly by eye and i wont get out my tape measure any time i set manual focus. So its something of a guessing game anyways.
What would be infinitely more helpful would be being able to force on the AF Zoom which magnifies a part of the frame in the middle to help confirm focusing.
Unfortunately on the ixus 160 that zoom thing is available, but only comes on after the camera has autofocused on its own successfully.
-
Besides, i dont get the need for setting a subject distance in cm anyways.
AFAIK, there are really only three reasons for wanting to set focus manually.
The first is the one you found - you know or can measure the subject distance accurately and want to always force the focus there. Doing this accurately has proven to be a big challenge.
The second is for focus stacking - usually with a script. Accuracy is not important here, you just need the focus to move through a range with each successive shot. For most Powershots, the CHDK manual focus code works adequately for that use.
The third (and perhaps most common) is to be able to lock the focus at either Infinity or huperfocal distance. Making this work was my original goal when I reworked all the SDO code in CHDK and I was only marginally successful in the end.
But a calibration routine that takes sequential shots at increased focus lens position settings, and then at the different zoom positions, would let the user pick a suitable value for an infinity setting at any zoom step setting. It would be interesting to see if those values were the same for each camera model because, if so, we could add it to the base CHDK code.
-
Oh yeah, i get the need for manual focus, what i mean is why do we need to set it with a "tangible" value like centimeters.
It might as well just be an arbitrary scale, say from 1 to 1000 where 1 is the minimum und 1000 is infinity.
Thats essentially how it works on my powershots, you dont actually see any numerical value for the manual focus, just a horizontal bar that fills and indicates wether the focus is near or far. Dont know how it is on other canon compats with stock manual focus.
How about keeping the subject distance override thing as it is on this camera but adding the option to replace it with MoveFocusLensWithPosition instead, and allowing people to enter the full range from 0 to 1840, directly in there? That would be a whole lot more accurate, reproducible, and actually enables to use a wider focus range.
A menu option for engaging the focus lock on those cameras would be a very nice touch as well.
By the way; theres some shenanigans with the subject distance override value anyways. I think its due to this function in shooting.c:
int shooting_get_subject_distance_override_value()
{
if (conf.subj_dist_override_koef != SD_OVERRIDE_INFINITY)
return (conf.subj_dist_override_value < shooting_get_lens_to_focal_plane_width()?0:(conf.subj_dist_override_value - shooting_get_lens_to_focal_plane_width()));
else
return INFINITY_DIST;
}
Both shooting_get_lens_to_focal_plane_width() and shooting_get_lens_to_focal_plane_width() return garbage when the lens is moving or even just when you press the shutter button and take a picture, so your sd override value changes on its own.
This is not unique to the ixus 160, i tested it on my powershot sx110 and observed the same behaviour.
Unfortunately any more testing on my sx110 is impossible since i bricked it yesterday during a repair of the battery compartment. Fragile ribbon cables.. ::)
-
How about keeping the subject distance override thing as it is on this camera but adding the option to replace it with MoveFocusLensWithPosition instead, and allowing people to enter the full range from 0 to 1840, directly in there?
If we go down that route, it would make sense to allow either to be used. But it would be nice to know a lot more about how it works across a reasonable selection of cameras (I have at least seven to start with) before adding it to the build. Is 1840 the same limit on all cameras? Do they all crash at 1841? How much does zoom position affect things? How would you explain this to the average user?
You get the idea.
For now, adding it to scripts to learn more makes some sense. I assume you are using a script for your book scanner?
A menu option for engaging the focus lock on those cameras would be a very nice touch as well.
Setting an SDO value essentially does this. But I see your point.
-
Yeah, i get it.
I dont know yet how exactly i will control the two cameras.
The thing i'm building is inspired by https://www.diybookscanner.org/ (https://www.diybookscanner.org/), they have some raspberry pi control unit for the Ixus 160. ( https://github.com/Tenrec-Builders/pi-scan (https://github.com/Tenrec-Builders/pi-scan) )
But i think i'll just control them via the chdkptp tool and my computer via a script indeed.
One more observation: The 2nd parameter for MoveFocusLensWithPosition takes a maximum value of 7400.
7401 will crash the camera.
0 will set the focus at maximum speed, same as 7400.
Max speed will set the focus from the near to far limit in less than half a second and you can clearly hear the focus motor working, no idea how healthy that is.
Zoom level does not appear to change any of those limits, it works within the same range and speed at any zoom levels.
By the way, i just triggered that Lens error that was reported earlier.
I could reproduce it once by crashing the camera when the lens was extended fully, but then not even after 10 tries.
First time around it fixed itself and the second time i could fix it with some force.
The camera is trying to move the lens but cant for some reason, grabbing in applying some force counter clockwise (viewed from the front) to the base ring of the lens fixes it after a couple of powercycles. What happens when you do that is that the lens is trying to wiggle back and forth but because you apply that force it can only rotate towards the retracted position. Once its retracted a little bit it'll retract itself and work normally after another powercycle.
It does not appear to have any connection to the focus commands, other than being triggered by a crash.
-
Report of two bricked ixus160 using recent (as of March 2018) stable builds: https://chdk.setepontos.com/index.php?topic=13372.0
-
Found and corrected a typo that made CHDK LED signals inoperable (and may have caused other trouble).
Stable builds starting from revision 5084 (https://app.assembla.com/spaces/chdk/subversion/commits/5084) and unstable builds starting from revision 5074 (https://app.assembla.com/spaces/chdk/subversion/commits/5074) no longer have this bug.