IXUS160/ELPH160 Porting attempt

srsa_4c

4451

Re: IXUS160/ELPH160 Porting attempt

« Reply #270 on: 12 / November / 2015, 19:41:21 »

Advertisements

Quote from: axman on 12 / November / 2015, 17:58:06

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.

Logged

brad11313

1

Re: IXUS160/ELPH160 Porting attempt

« Reply #271 on: 13 / November / 2015, 00:02:16 »

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.

Logged

srsa_4c

4451

Re: IXUS160/ELPH160 Porting attempt

« Reply #272 on: 13 / November / 2015, 11:17:21 »

Quote from: brad11313 on 13 / November / 2015, 00:02:16

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.

Logged

axman

145

Re: IXUS160/ELPH160 Porting attempt

« Reply #273 on: 13 / November / 2015, 13:08:17 »

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

Logged

axman

145

Re: IXUS160/ELPH160 Porting attempt

« Reply #274 on: 13 / November / 2015, 18:16:34 »

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.

mf_ixus160_elph160.csv (1.04 kB - downloaded 21 times.)

setmode.log (1.7 kB - downloaded 16 times.)

Logged

waterwingz

12139

Re: IXUS160/ELPH160 Porting attempt

« Reply #275 on: 13 / November / 2015, 18:38:19 »

Quote from: axman on 13 / November / 2015, 18:16:34

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.

Logged

Ported : A1200 SD940 G10 Powershot N G16

reyalp

14082

Re: IXUS160/ELPH160 Porting attempt

« Reply #276 on: 13 / November / 2015, 21:58:38 »

Thanks for the detailed report

Quote from: axman on 13 / November / 2015, 18:16:34

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.

Quote

isobase.lua -> set CAM_MARKET_ISO_BASE=200

This is set correctly in platform_camera.h port.

Quote

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.

Logged

Don't forget what the H stands for.

srsa_4c

4451

Re: IXUS160/ELPH160 Porting attempt

« Reply #277 on: 14 / November / 2015, 08:44:30 »

Thanks for providing test results. I have a few questions.

Quote from: axman on 13 / November / 2015, 18:16:34

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.

Quote

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.

Quote

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.

Quote

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

Quote

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

Quote

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

Logged

axman

145

Re: IXUS160/ELPH160 Porting attempt

« Reply #278 on: 14 / November / 2015, 11:02:54 »

Quote from: reyalp on 13 / November / 2015, 21:58:38

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.

Logged

axman

145

Re: IXUS160/ELPH160 Porting attempt

« Reply #279 on: 14 / November / 2015, 12:27:29 »

Quote from: srsa_4c on 14 / November / 2015, 08:44:30

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.

Quote from: srsa_4c on 14 / November / 2015, 08:44:30

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

Quote from: srsa_4c on 14 / November / 2015, 08:44:30

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

LOG_0001.TXT (0.46 kB - downloaded 17 times.)

Logged