CHDK PTP Java + remoteshoot (was Re: alternative ptp client) - page 2 - General Discussion and Assistance - CHDK Forum supplierdeeply

CHDK PTP Java + remoteshoot (was Re: alternative ptp client)

  • 17 Replies
  • 17051 Views
*

Offline reyalp

  • ******
  • 14117
Re: CHDK PTP Java + remoteshoot (was Re: alternative ptp client)
« Reply #10 on: 23 / June / 2015, 21:51:47 »
Advertisements
1. Luaj requires to load Lua script and call it for declare functions, etc. Currently, I'm calling main.lua, but it starts to chdkptp itself, with calls to dngcli.init_cli(), etc. i.e. many things that not need to my framework. Could you move startup code that initializes some thing and includes all required lua files("fsutil=require'fsutils'") into separate file (probably init.lua ?) ? After that, main.lua can just include this startup code and run usual methods. I will use init.lua, then will get required function and call from java. main.lua will not be loaded in my code, but will be still used in chdktptp.
I'll look into splitting this up more, but you might also consider just writing your own lua file. Aside from the requires at the top, it's almost all dealing with command line options and startup stuff you don't need.

Of the top of my head, the other things you might want are
the prefs._add lines, the con global, and get_chdkptp_home

Quote
2. It would be good all functions (that can be called in chdkptp from java) as separate functions with table parameters. I.e. something like this:

function remoteshoot(params)
  if (params.raw) ...
  if (params.isomode>200) ...
...

But I understand that is big changes. I will send just array with text parameters yet. But how can I get remoteshoot function ? I see cli:add_commands but I don't know Lua so good to understand hot to get function by name. Could you please to write me simple Lua script for just get and call 'remoteshoot' function ? Somethins like :
  func = table.get('remoteshoot')
  func(['-raw','-isomode=100'])
The simplest way is to just use cli:execute and build the full command as a string. See gui_user.lua for an example of this with remoteshoot. This is the recommended way to call cli commands.

If you really want to call the function directly, you could use  cli.names.commandname:func(), like
Code: [Select]
cli.names.help:func({v=true,'help'})
Note that :func expects the args to have already been parsed by the commands parse function (cli.names.commandname.args:parse), so you'd need to supply them in the appropriate table. This varies by command, you'll need to look in the definitions in the cli:add_commands section, but it's a bit like what you requested in the first part. For most commands, the -x options are named elements in the table, and other arguments (like file names etc) are in the array part of the table.

Defaults are in the argparser, so if you bypass that you will have to provide them yourself. Things that default to false can probably be left out most of the time, but there may be cases where false behaves differently from nil.

FWIW, I never intended the CLI to be called this way (outside of cli:execute), it's an "internal" interface and I'm not likely to spend effort keeping it backward compatible if I need to make changes.

Quote
3. If capture_get_data_pcall throws some error, script just dumps this error and continues to work. I.e. I can't know from my code was remoteshoot processed good or not. Is it possible to change code somehow(additional error throing or status return) for be able to check status on the remoteshoot function end ?
The cli command :func or cli:execute will usually return status, <error message>. If you use cli:execute, it will normally be protected by xpcall, so any lua errors will be caught and turned into an error message. If you call :func directly, it's possibly you will get lua errors. In chdkptp, errors may be a table or a string (the table does have a tostring metamethod)
Don't forget what the H stands for.

Re: CHDK PTP Java + remoteshoot (was Re: alternative ptp client)
« Reply #11 on: 26 / June / 2015, 15:08:47 »
Thank you, reyalp, it goings forward - I fixed all issues with Lua scripting.

Now, there are some questions about performance of shooting. I'm testing Ixus 160 camera.

1. Remote shooting works better than local storage. I fixed one issue in libusb - buffer size for receive data. It was 512 bytes in the usb4java, like USB reported. As result, transfer required up to 5 seconds for raw file. I changed packet size for 16KiB, like in chdkptp, and it works good. Is it correct behavior ? Did you make something special for setup buffer size in chdkptp ?

2. Full remote shooting(with jpeg and raw transfer) requires 3.8 seconds. Is there any way to increase speed ? You can see full log in attachment, but below is short summary:

Ixus160:
 100ms: rs_init call, then rlib_shoot_init_exp call
2100ms: waiting for capture_ready for raw file (on the end, it waits about 250ms between checks)
 900ms: raw file transfer
 500ms: waiting for capture_ready for jpeg file
  50ms: jpeg file transfer


So, is it really need to process remote shooting so long ? Is there any way for decrease 2100ms and 500ms delay ? If no, can I decrease delay between status checking to 50ms ? In my case, 0.5 sec increase speed is also good. Is there any way to understand what camera doing so long time ?

*

Offline reyalp

  • ******
  • 14117
Re: CHDK PTP Java + remoteshoot (was Re: alternative ptp client)
« Reply #12 on: 26 / June / 2015, 22:35:05 »
1. Remote shooting works better than local storage. I fixed one issue in libusb - buffer size for receive data. It was 512 bytes in the usb4java, like USB reported. As result, transfer required up to 5 seconds for raw file. I changed packet size for 16KiB, like in chdkptp, and it works good. Is it correct behavior ? Did you make something special for setup buffer size in chdkptp ?
I'm not sure which buffer sizes you are referring to. chdkptp uses a 2 MB buffer for reads in a given transaction (PTPCAM_USB_URB)

There is also the max packet size stuff in init_ptp_usb, which is typically 512.

When CHDK is sending it makes a single call for however much data it has (e.g. the entire raw buffer or a jpeg chunk) and the camera OS handles any buffering.

Quote
2. Full remote shooting(with jpeg and raw transfer) requires 3.8 seconds. Is there any way to increase speed ? You can see full log in attachment, but below is short summary:
First of all, this is roughly what I'd expect with raw on a camera like this. On my ixus140
set cli_time=1
rs -tv=1/1000 -jpg -dng
time 3.3512
Quote
Ixus160:
 100ms: rs_init call, then rlib_shoot_init_exp call
2100ms: waiting for capture_ready for raw file (on the end, it waits about 250ms between checks)
You can change the polling behavior. See  chdku.lua con_methods:wait_status. The default is to poll with increasing delays, to make fast operations will return quickly but not use excessive camera CPU polling on longer ones. The polling related wait_status options are passed through capture_get_data options, but aren't exposed as CLI options.

A lot of the 2100ms is probably used by the camera pre-shoot process. If you don't need to re-focus and re measure exposure between each shot, you can do things a lot faster. If you just want to shoot a burst, -cont and -quick options give you ways to do this. If you want to control the shots individually, rsint is an example.

If you do need to need AF and/or AE, it's possible some settings will be a bit quicker, but I wouldn't expect big gains. If you can set focus in advance you could try AFlock or set_mf.
Quote
900ms: raw file transfer
20Mpixel = ~30Mbyte raw = 33 Mbyte/sec

You can use
!require'camtests':xfermem()
to benchmark raw transfer speed, but ~30 Mbyte/sec is about what I see on recent-ish cameras like ixus140 and sx160.

Quote
500ms: waiting for capture_ready for jpeg file
Canon settings may affect how long it takes to generate the jpeg. High ISO is probably the biggest factor, but quality or jpeg size might have some effect too. Also make sure you have review turned off in the Canon UI.
Don't forget what the H stands for.

Re: CHDK PTP Java + remoteshoot (was Re: alternative ptp client)
« Reply #13 on: 27 / June / 2015, 04:52:54 »
Hi reyalp.
I'm not sure which buffer sizes you are referring to. chdkptp uses a 2 MB buffer for reads in a given transaction (PTPCAM_USB_URB)

There is also the max packet size stuff in init_ptp_usb, which is typically 512.

I don't know. I saw these packet via wireshark. You can download pcapng file of "rs -jpg -dng" from your chdkptp on the https://drive.google.com/file/d/0B79T6_pg7ncVUlVfNnpuNGVVblE/view?usp=sharing . You can open it in the Wireshark for see all packets details.
This buffer used in the IrpQueue.read() method in the usb4java

Quote
You can change the polling behavior. See  chdku.lua con_methods:wait_status. The default is to poll with increasing delays, to make fast operations will return quickly but not use excessive camera CPU polling on longer ones. The polling related wait_status options are passed through capture_get_data options, but aren't exposed as CLI options.

As far as I understand, I need to change "remoteshoot" method for that. It's not so good because I'm trying to use all your Lua code as-is. Is it possible to change 250ms default interval in the chdku.lua in chdkptp to something that can be changed by set command, like "set cli_poll=50" ?

Quote
A lot of the 2100ms is probably used by the camera pre-shoot process. If you don't need to re-focus and re measure exposure between each shot, you can do things a lot faster. If you just want to shoot a burst, -cont and -quick options give you ways to do this. If you want to control the shots individually, rsint is an example.

If you do need to need AF and/or AE, it's possible some settings will be a bit quicker, but I wouldn't expect big gains. If you can set focus in advance you could try AFlock or set_mf.
I'm not sure that it is delay for focusing and measure exposure. I will lock these values, but shoot sound starts just after rs command sent. So, it looks like some copy from sensor to memory time.

Quote
500ms: waiting for capture_ready for jpeg file
Canon settings may affect how long it takes to generate the jpeg. High ISO is probably the biggest factor, but quality or jpeg size might have some effect too. Also make sure you have review turned off in the Canon UI.
[/quote]

Review was turned of.

Thank you, will check other things.


Re: CHDK PTP Java + remoteshoot (was Re: alternative ptp client)
« Reply #14 on: 29 / June / 2015, 15:46:10 »
One more question not about remoteshoot but about camera control from desktop.

About properties. I read http://chdk.wikia.com/wiki/PropertyCase, able to use it, and able to get/set properties for Ixus 160(propset 6).

My goal is to setup camera into some predefined state after power on.

For example, I want to disable digital zoom for have optical zoom only. There is properties 91 and 94 for that. When I change value by set_prop, get_prop returns my values, but settings menu on camera doesn't display changes and digital zoom still work.

Is it usual behavior ? I understand that I can change settings by emulate buttons pressing, but it's very unreliable way.


Re: CHDK PTP Java + remoteshoot (was Re: alternative ptp client)
« Reply #15 on: 29 / June / 2015, 16:09:54 »
In many cases, these propset values are "read only".
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline msl

  • *****
  • 1280
  • A720 IS, SX220 HS 1.01a
    • CHDK-DE links
Re: CHDK PTP Java + remoteshoot (was Re: alternative ptp client)
« Reply #16 on: 29 / June / 2015, 16:53:46 »
My goal is to setup camera into some predefined state after power on.
There is a further option. Read this thread: UI properties

msl
CHDK-DE:  CHDK-DE links

Re: CHDK PTP Java + remoteshoot (was Re: alternative ptp client)
« Reply #17 on: 30 / June / 2015, 01:52:44 »
My goal is to setup camera into some predefined state after power on.
There is a further option. Read this thread: UI properties

msl

Thank you. It looks promising, but works strange yet in Ixus 160. Probably it depends on camera. Will investigate.


 

Related Topics


SimplePortal 2.3.6 © 2008-2014, SimplePortal