CHDK PTP interface

srsa_4c

4451

Re: CHDK PTP interface

« Reply #930 on: 03 / January / 2013, 19:49:36 »

Advertisements

I've checked in the above mentioned changes. It's worth to note that converting offsets to structure members is a small additional challenge.

Also done some tests, and found that the new rs command doesn't work reliably with the A410. Reason not yet known (it's not related to my latest changes). It usually works after the camera is switched to rec mode, but fails with timeout after the camera goes to powersave mode (rs wake up the cam as usual and the half press phase is OK, but then nothing happens). I don't remember experiencing this with the monolithic rs, hopefully it's not related to the completefilewrite replacement. OTOH the A470 is working normally, no problems.
There's another small bug in rs, it fails to append the received file name when a target directory is given (I can probably figure out how to solve this one).

Logged

reyalp

14082

Re: CHDK PTP interface

« Reply #931 on: 04 / January / 2013, 00:35:20 »

Quote from: srsa_4c on 03 / January / 2013, 19:49:36

It usually works after the camera is switched to rec mode, but fails with timeout after the camera goes to powersave mode (rs wake up the cam as usual and the half press phase is OK, but then nothing happens). I don't remember experiencing this with the monolithic rs, hopefully it's not related to the completefilewrite replacement. OTOH the A470 is working normally, no problems.

One difference is that this one uses shoot_half, wait for get_shooting etc, instead of shoot() Full camera side code is in lua/rlibs.lua rs_shoot

I seem to remember having had other weird problems when the camera goes to screen off mode, I usually disable it when I'm doing ptp stuff.

Quote

There's another small bug in rs, it fails to append the received file name when a target directory is given (I can probably figure out how to solve this one).

Whoops, I left that half finished, should be better in changeset 321.
rs (no file) = use camera filename
rs foo = if foo is a directory, use foo/<camera filename>, otherwise foo.jpg, foo.raw
rs foo/ = create foo if it doesn't exist, use foo/<camera filename>

Logged

Don't forget what the H stands for.

srsa_4c

4451

Re: CHDK PTP interface

« Reply #932 on: 04 / January / 2013, 19:25:57 »

Quote from: reyalp on 04 / January / 2013, 00:35:20

I seem to remember having had other weird problems when the camera goes to screen off mode, I usually disable it when I'm doing ptp stuff.

I don't remember anything weird in connection with powersave mode. During earlier testing I left the cameras in rec mode sleeping for hours and rs always succeeded when executed later. I guess I'll investigate this stuff.

Quote

Whoops, I left that half finished, should be better in changeset 321.
rs (no file) = use camera filename
rs foo = if foo is a directory, use foo/<camera filename>, otherwise foo.jpg, foo.raw
rs foo/ = create foo if it doesn't exist, use foo/<camera filename>

Thanks

Logged

reyalp

14082

Re: CHDK PTP interface

« Reply #933 on: 05 / January / 2013, 01:04:29 »

I updated the ptp-remote-capture-test up to the last change before phils reorg merge. Because of the file moves, it's not really practical to merge in the normal way. I suspect the best approach is going to be to make a new branch from the trunk, and manually port over the changes from the moved files. I'll try that this weekend.

Logged

Don't forget what the H stands for.

reyalp

14082

Re: CHDK PTP interface

« Reply #934 on: 05 / January / 2013, 22:26:33 »

New remote capture branch is ptp-remote-capture-test2, all future development should go there.

Note that CAM_CHDK_PTP_REMOTESHOOT can't be turned off at the moment, because ptp.c is now in platform independent code. I'm not sure it's worth keeping this as an option at all, since all cameras should at least support raw. It would save a small amount of memory.

I split remotecap.h into into two parts,
remotecap.h is now the "public" interface available to modules (lua)
remotecap_core.h is only for core code.

Please don't check anything into ptp-remote-capture-test. I'll delete it soon (only removes it from the list of current branches)

Logged

Don't forget what the H stands for.

philmoz

3450

Re: CHDK PTP interface

« Reply #935 on: 05 / January / 2013, 22:42:39 »

Quote from: reyalp on 05 / January / 2013, 22:26:33

Note that CAM_CHDK_PTP_REMOTESHOOT can't be turned off at the moment, because ptp.c is now in platform independent code. I'm not sure it's worth keeping this as an option at all, since all cameras should at least support raw. It would save a small amount of memory.

If it needs to be turned off because the functionality is not available then it should be done at runtime. Add a new entry to camera_info.h/.c and check that in the code.

Phil.

Logged

CHDK ports:
sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
g12 (1.00c, 1.00e, 1.00f & 1.00g)
sx130is (1.01d & 1.01f)
ixus310hs (1.00a & 1.01a)
sx40hs (1.00d, 1.00g & 1.00i)
g1x (1.00e, 1.00f & 1.00g)
g5x (1.00c, 1.01a, 1.01b)
g7x2 (1.01a, 1.01b, 1.10b)

reyalp

14082

Re: CHDK PTP interface

« Reply #936 on: 05 / January / 2013, 22:58:06 »

Quote from: philmoz on 05 / January / 2013, 22:42:39

If it needs to be turned off because the functionality is not available then it should be done at runtime. Add a new entry to camera_info.h/.c and check that in the code.

The minimum functionality (raw only) is available on any camera, so there's really no point in turning it off at runtime. The only reason to keep the #ifdef would be to reduce the core executable size slightly. This can be done, it would just require moving some of the code out of ptp.c and stubbing out the public functions when it's not available. I don't really think this is worthwhile.

Logged

Don't forget what the H stands for.

srsa_4c

4451

Re: CHDK PTP interface

« Reply #937 on: 06 / January / 2013, 09:26:31 »

Quote from: srsa_4c on 03 / January / 2013, 19:49:36

Also done some tests, and found that the new rs command doesn't work reliably with the A410.

It's puzzling, but after putting in larger amounts of debug code, it appears that the problem is related to flash. In other words, it's probably the same issue that skrylten is experiencing. I usually disable flash when testing, but haven't always done so recently, hence the issue...

Even when operated manually, a short full shutter press often fails to take a shot. When pressed for longer, the camera shoots.

Quote from: reyalp on 05 / January / 2013, 22:58:06

The only reason to keep the #ifdef would be to reduce the core executable size slightly.

Not fully related, but I'd consider putting the whole filewritetask related code inside #ifdefs, including the copied task code and the lines related to task replacement.
The same would be good for other standard tasks we replace (capt_seq, movie_record, ...), but that's probably not feasible. Conditionally compiled task replacements would enable one to create a smaller sized CHDK that excludes unwanted (or unstable) features. Space-wise, on low memory ports even a few kBytes could matter.

« Last Edit: 06 / January / 2013, 09:36:16 by srsa_4c »

Logged

srsa_4c

4451

Re: CHDK PTP interface

« Reply #938 on: 09 / January / 2013, 18:07:38 »

Some news.
I've been trying to implement YUV support for the A470. Looks like it's a no-go with the filewrite hook. It appears that by the time the filewritetask hook is reached, the YUV source of the JPEG is overwritten by the decompressed Y411 version of the fresh JPEG (unless 640x480 size is selected). So, either a new hook or no YUV support on this camera...
The interesting find is that in addition to the resized YUV, there are remnants of a full sized YUV image, regardless of the selected image dimensions.

For the rs "bug" I came up with the following (it's probably influenced by lapser's findings)

Code: [Select]

function rs_shoot(opts)
	local rec,vid = get_mode()
	if not rec then
		return false,'not in rec mode'
	end
	if type(init_remotecap) ~= 'function' then
		return false, 'remotecap not supported'
	end
	if bitand(get_remotecap_support(),opts.fformat) ~= opts.fformat then
		return false, 'unsupported format'
	end
	if not init_remotecap(opts.fformat,opts.lstart,opts.lcount) then
		return false, 'init failed'
	end
	press('shoot_half')
	local shtimeout = get_tick_count()
	repeat
		sleep(10)
	until ( get_shooting() ) or ( (get_tick_count()-shtimeout)>5000 )
	reset_shoot_ok()
	press('shoot_full')
	local gsrtime = get_tick_count()
	repeat
		sleep(10)
	until  ( get_shoot_ok() ) or ( (get_tick_count()-gsrtime)>5000 )
	release('shoot_full')
	return true
end

reset_shoot_ok() and get_shoot_ok() are new functions. They use a new static variable which is set in ~~the raw hook~~ capt_seq_hook_set_nr() . This approach appears to work on the A410 and 470 - even with flash. My trials included putting arbitrary delays after pressing shoot_full, but that method was unreliable (unless the delay was set to like 2 seconds).

edit: not raw hook, capt_seq_hook_set_nr()

« Last Edit: 10 / January / 2013, 17:56:12 by srsa_4c »

Logged

reyalp

14082

Re: CHDK PTP interface

« Reply #939 on: 09 / January / 2013, 22:29:27 »

Quote from: srsa_4c on 09 / January / 2013, 18:07:38

Some news.
I've been trying to implement YUV support for the A470. Looks like it's a no-go with the filewrite hook. It appears that by the time the filewritetask hook is reached, the YUV source of the JPEG is overwritten by the decompressed Y411 version of the fresh JPEG (unless 640x480 size is selected). So, either a new hook or no YUV support on this camera...

Unless there is some really compelling use for the YUV, this doesn't seem like it would justify adding a new task hook. Even at full size, I'm have trouble seeing one.

Quote

For the rs "bug" I came up with the following (it's probably influenced by lapser's findings)
...
reset_shoot_ok() and get_shoot_ok() are new functions. They use a new static variable which is set in the raw hook. This approach appears to work on the A410 and 470 - even with flash. My trials included putting arbitrary delays after pressing shoot_full, but that method was unreliable (unless the delay was set to like 2 seconds).

did you check get_flash_ready() ?

Logged

Don't forget what the H stands for.