CHDK PTP interface - page 102 - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: 1 ... 97 98 99 100 101 [102] 103 104 105 106 107 ... 125   Go Down

CHDK PTP interface

  • 1244 Replies
  • 557931 Views
*

Offline srsa_4c

  • ******
  • 4451
Re: CHDK PTP interface
« Reply #1010 on: 02 / July / 2013, 14:05:44 »
Advertisements
Quote from: reyalp on 02 / July / 2013, 13:18:44
The current code gets the address and size once for each chunk. If the timeout expires while that chunk is being transferred, the transfer will continue using that address/size (which may no longer contain valid data). If the chunk wasn't the last chunk, it will get an error because the remotecap state has been cleared.
OK then, I thought that it can't halt in the middle of a certain datatype. In this case, the user will get corrupted/truncated file.

Quote
Nafraf reported it worked on sx160.
That's good :)
Quote
But I'm thinking that the situation above may have additional problems, because there could be calls to the filewrite hook after the remotecap state is cleared... but maybe it's ok because the ignore write flag is still set?
To prevent confusing crashing the camera, writes should not be re-enabled in the middle of the 'jpeg save' operation. I think the 'current_write_enabled' flag should take care of this, as it only gets cleared when all data chunks are 'written' from the filewritetask's perspective.

Quote
I'm not sure I follow. This would get called from the ptp task at the end of it's chunk. Meanwhile, filewritetask is waiting. When filewritetask is finished waiting, it will immediately set jpeg_chunks null. I guess there could be another call from ptp before it gets there?
Can't recall what exactly happened, but this change was the solution (the commit is a bit noisy).
Logged
*

Offline reyalp

  • ******
  • 14131
Re: CHDK PTP interface
« Reply #1011 on: 02 / July / 2013, 16:51:37 »
Thanks for the comments
Quote
In this case, the user will get corrupted/truncated file.
Yes. Not good, but better than crashing. I'm tempted to add a timeout flag, so we can check after the send_data is complete and set a ptp error. Or maybe check if the data available flag is cleared? I'm worried it will get too complicated...
Quote
I think the 'current_write_enabled' flag should take care of this, as it only gets cleared when all data chunks are 'written' from the filewritetask's perspective.
Yeah, I think that is right.

Another concern:
Can the raw hook be entered for the next shot before the jpeg from the previous is downloaded? I haven't set up a test for this but it seems like it might be possible, depending on how much overlap canon firmware allows (and might change between cameras or shooting modes). A check for remotecap_get_available_data_type at the start of the raw hook should catch this, but the correct response is not clear. Maybe wait the timeout length for it to clear? That should guarantee any previous request had finished or timed out. If timed out, the remote cap settings would have been cleared by the timeout, so the new shot won't use remotecap.
Logged
Don't forget what the H stands for.
*

Offline nafraf

  • *****
  • 1308
Re: CHDK PTP interface
« Reply #1012 on: 03 / July / 2013, 00:25:18 »
I tested on A810, without flash, remote capture works.  If flash enabled it returns timeout.  Same behavior on sx160. It seems that if flash is not ready, capture is interrupted.
Code: [Select]
connected: Canon PowerShot A810, max packet size 512
con> rec
con 1> =set_prop(require("propcase").FLASH_MODE,2)
con 2> rs -jpg
con 5> =set_prop(require("propcase").FLASH_MODE,1)
con 6> rs -jpg
ERROR: timed out
A495 works without problems in both cases.  Am I missing something?
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: CHDK PTP interface
« Reply #1013 on: 03 / July / 2013, 13:45:06 »
Quote from: nafraf on 03 / July / 2013, 00:25:18
I tested on A810, without flash, remote capture works.  If flash enabled it returns timeout.  Same behavior on sx160. It seems that if flash is not ready, capture is interrupted.
I had similar experience on some cameras, see http://chdk.setepontos.com/index.php?topic=4338.msg95368#msg95368 . I'll re-check with one of them.
Still happens on the a410.
« Last Edit: 03 / July / 2013, 14:59:48 by srsa_4c »
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: CHDK PTP interface
« Reply #1014 on: 03 / July / 2013, 15:32:16 »
Quote from: reyalp on 02 / July / 2013, 16:51:37
Can the raw hook be entered for the next shot before the jpeg from the previous is downloaded?
This should probably be tested. Cameras with 2 raw buffers could in theory take advantage of the extra buffer, but... wouldn't that kind of parallelism already cause problems with CHDK raw/dng? We block filewritetask before its "open" stage, so anything that would signal "next shot is available" from there is also blocked. BTW, there are event procedures that could be used for testing (one or more of those around 'completefilewrite').
Logged
*

Offline reyalp

  • ******
  • 14131
Re: CHDK PTP interface
« Reply #1015 on: 03 / July / 2013, 23:12:39 »
Quote from: nafraf on 03 / July / 2013, 00:25:18
I tested on A810, without flash, remote capture works.  If flash enabled it returns timeout.  Same behavior on sx160. It seems that if flash is not ready, capture is interrupted.
Does shooting raw/dng without using PTP work in this situation?

How about a (non-ptp) script that just does

Code: [Select]
press('shoot_half')
repeat sleep(10) until get_shooting()
click('shoot_full')

The rs command use something like the above rather than shoot().

shoot() has a shooting_is_flash_ready() check.
but looking back at the old discussion, that wasn't it...
« Last Edit: 03 / July / 2013, 23:17:40 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline Hardware_Hacker

  • ****
  • 322
Re: CHDK PTP interface
« Reply #1016 on: 04 / July / 2013, 04:36:37 »
ChdkPtp-r330 Demo on Windows Blue Pe [PreView version] is now partly working ... Also See this Post.

http://chdk.setepontos.com/index.php?topic=10256.msg102410#msg102410

Happy-Hacking By  H-H
« Last Edit: 04 / July / 2013, 04:48:47 by Hardware_Hacker »
Logged
*

Offline reyalp

  • ******
  • 14131
Re: CHDK PTP interface
« Reply #1017 on: 04 / July / 2013, 17:24:56 »
Quote from: srsa_4c on 03 / July / 2013, 15:32:16
Quote from: reyalp on 02 / July / 2013, 16:51:37
Can the raw hook be entered for the next shot before the jpeg from the previous is downloaded?
This should probably be tested. Cameras with 2 raw buffers could in theory take advantage of the extra buffer, but... wouldn't that kind of parallelism already cause problems with CHDK raw/dng? We block filewritetask before its "open" stage, so anything that would signal "next shot is available" from there is also blocked. BTW, there are event procedures that could be used for testing (one or more of those around 'completefilewrite').
I can confirm this happens on both a540 and d10. Both only have a single raw buffer, so I guess this means the final jpeg buffer does not overlap the raw buffer. The canon firmware is happy to start a new exposure before the previous one has finished writing.

The following code demonstrates.
In remotecap.c
Code: [Select]
Index: D:/chdk/remotecap4/core/remotecap.c
===================================================================
--- D:/chdk/remotecap4/core/remotecap.c (revision 2921)
+++ D:/chdk/remotecap4/core/remotecap.c (working copy)
@@ -133,6 +133,16 @@
 extern long hook_raw_size(void); // TODO should use camera_sensor, but see note on size mismatch!
 
 void remotecap_raw_available(char *rawadr) {
+// temp sanity check
+    while(remotecap_get_available_data_type()) {
+        int i;
+        for(i=0; i<10; i++) {
+            started();
+            msleep(250);
+            finished();
+            msleep(250);
+        }
+    }
 // TODO this should probably just be noop if hook doesn't exist
 #ifdef CAM_HAS_FILEWRITETASK_HOOK
     filewrite_set_discard_jpeg(1);
In chdkptp:
Code: [Select]
con 1> rec
con 2> =return init_remotecap(1)
3:return:true
con 3> .shoot(); press('shoot_half'); repeat sleep(10) until get_shooting(); click('shoot_full') sleep(100)
I will add the timeout logic I described earlier.

edit:
done in changeset 2922
« Last Edit: 04 / July / 2013, 18:23:56 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline nafraf

  • *****
  • 1308
Re: CHDK PTP interface
« Reply #1018 on: 04 / July / 2013, 19:39:06 »
Quote from: reyalp on 03 / July / 2013, 23:12:39
Does shooting raw/dng without using PTP work in this situation?
Yes, it works.


Quote
How about a (non-ptp) script that just does

Code: [Select]
press('shoot_half')
repeat sleep(10) until get_shooting()
click('shoot_full')
It does not work. but changing sleep(10) to sleep(500) it works. ???
Logged
*

Offline reyalp

  • ******
  • 14131
Re: CHDK PTP interface
« Reply #1019 on: 04 / July / 2013, 19:56:53 »
Quote from: nafraf on 04 / July / 2013, 19:39:06
It does not work. but changing sleep(10) to sleep(500) it works. ???

ok, try
Code: [Select]
press('shoot_half')
repeat sleep(10) until (get_flash_ready() and get_shooting())
click('shoot_full')
On my a540 get_flash_ready() only goes true if the flash is enabled and would fire, so "real" usage requires a more complicated check.
Logged
Don't forget what the H stands for.
Pages: 1 ... 97 98 99 100 101 [102] 103 104 105 106 107 ... 125   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal