CHDK PTP interface - page 87 - General Discussion and Assistance - CHDK Forum supplierdeeply
« previous next »
Pages: 1 ... 82 83 84 85 86 [87] 88 89 90 91 92 ... 125   Go Down

CHDK PTP interface

  • 1241 Replies
  • 487494 Views
*

Offline reyalp

  • ******
  • 14079
Re: CHDK PTP interface
« Reply #860 on: 09 / September / 2012, 17:43:43 »
Advertisements
Quote from: srsa_4c on 09 / September / 2012, 16:46:29
Quote
- hook_raw_save_complete() is only called after all the chunks are downloaded, meaning the the raw hook will be blocked until the jpeg is complete. This seems like it might have unwanted impacts, perhaps depending on where the raw hook is on a specific camera.
I assumed the two hooks to never overlap. If they do, the port is IMHO broken (imagine what would happen if FileWriteTask's open stage found an open file). That was the reason I used the same variable and status codes for the two hooks.
OK, the current issue is probably a problem in my understanding of the old code and change then. filewrite now doesn't use the raw status variable at all (more clear, I think), so hook_raw_save_complete can probably be called when the last raw chunk is collected. I'm actually surprised it works the way I have it.

edit:
More misunderstanding on my part, I was thinking all the chunks could be read before the end case, but of course raw has to be finished before jpeg starts. hook_raw_save_complete will get called redundantly for non-raw chunks, but as you said, raw hook should not be running when jpeg or yuv chunks are being handled. Still need to look at state_shooting_progresss

edit:
You had a comment
Quote
hook_raw_size() is sometimes different than CAM_RAW_ROWS*CAM_RAW_ROWPIX*CAM_SENSOR_BITS_PER_PIXEL/8
Do you know which cameras have this ? It seems like it should not ever be true. DNG will probably be corrupt if this happens (more / less data than given in exif...)
« Last Edit: 09 / September / 2012, 23:50:34 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline srsa_4c

  • ******
  • 4451
Re: CHDK PTP interface
« Reply #861 on: 10 / September / 2012, 11:10:15 »
Quote from: reyalp on 09 / September / 2012, 17:43:43
Quote
hook_raw_size() is sometimes different than CAM_RAW_ROWS*CAM_RAW_ROWPIX*CAM_SENSOR_BITS_PER_PIXEL/8
Do you know which cameras have this ? It seems like it should not ever be true. DNG will probably be corrupt if this happens (more / less data than given in exif...)
A470, the difference is 6 lines. I haven't tested RAW shooting on it too much  ;)

Quote
raw has to be finished before jpeg starts
Now that I think of it... What happens in continuous mode? There has to be some caching somewhere. Could it be a filesystem cache (meaning Open(), Write(), Close() finish before the data actually ends up on the card)?
Logged
*

Offline reyalp

  • ******
  • 14079
Re: CHDK PTP interface
« Reply #862 on: 10 / September / 2012, 12:37:02 »
Quote from: srsa_4c on 10 / September / 2012, 11:10:15
A470, the difference is 6 lines. I haven't tested RAW shooting on it too much  ;)
OK, this should be investigated. It may be that someone thought it was a good idea to discard the blank lines at the bottom of the sensor, but the values should be consistent.

Quote
Now that I think of it... What happens in continuous mode? There has to be some caching somewhere. Could it be a filesystem cache (meaning Open(), Write(), Close() finish before the data actually ends up on the card)?
When we write raw in continuous mode, I'm pretty certain it blocks until the write is finished, and very little if any caching is done with write().
Logged
Don't forget what the H stands for.
*

Offline srsa_4c

  • ******
  • 4451
Re: CHDK PTP interface
« Reply #863 on: 10 / September / 2012, 15:03:52 »
Quote from: reyalp on 10 / September / 2012, 12:37:02
Quote
Now that I think of it... What happens in continuous mode? There has to be some caching somewhere. Could it be a filesystem cache (meaning Open(), Write(), Close() finish before the data actually ends up on the card)?
When we write raw in continuous mode, I'm pretty certain it blocks until the write is finished, and very little if any caching is done with write().
:-[ Canon DSLRs do this sort of thing (and maybe compacts of some other manufacturers). My mistake. Haven't found any PowerShot with this feature (caching).

I have committed some YUV related code to the test branch. It will have to be improved:
- Either a new #define in camera.h will be needed for this ability, or the client has to handle the case where YUV data has 0 length.
- As discussed earlier, YUV data is not always available. Picture sizes with one pass JPEG creation include "L" and "W" (every picture size with full width).
- The review time should last longer than the time required for transfer.

A question:
Shouldn't these
Code: [Select]
void filewrite_set_discard_jpeg(int state);
void filewrite_get_jpeg_chunk(char **ardr,unsigned *size, unsigned n);declarations in core/remotecap.c be extern?

A470:
the values found by sigfinder are good.

About SHOOTING_PROGRESS_DONE:
core/action_stack.c
one of the last actions of AS_SHOOT is AS_WAIT_SAVE
AS_WAIT_SAVE will not finish until (state_shooting_progress == SHOOTING_PROGRESS_DONE)
state_shooting_progress normally gets this value in core/main.c, which is not happening when remote shooting is active.

It's true that
Code: [Select]
state_shooting_progress=SHOOTING_PROGRESS_DONE;in remotecap_get_data_chunk() is in an unfortunate place though...
« Last Edit: 10 / September / 2012, 17:38:46 by srsa_4c »
Logged
*

Offline reyalp

  • ******
  • 14079
Re: CHDK PTP interface
« Reply #864 on: 10 / September / 2012, 21:58:25 »
Quote from: srsa_4c on 10 / September / 2012, 15:03:52
A question:
Shouldn't these
Code: [Select]
void filewrite_set_discard_jpeg(int state);
void filewrite_get_jpeg_chunk(char **ardr,unsigned *size, unsigned n);declarations in core/remotecap.c be extern?
For functions, it doesn't make any difference, but I guess we mostly use extern elsewhere (including in the headers), so it would be more consistent.

Quote
state_shooting_progress normally gets this value in core/main.c, which is not happening when remote shooting is active.

It's true that
Code: [Select]
state_shooting_progress=SHOOTING_PROGRESS_DONE;in remotecap_get_data_chunk() is in an unfortunate place though...
That makes sense, and I agree that it's not ideal at the moment. Especially in the case where it could get set at an arbitrary time to clear hooks.

It may be wroth tracking what stage we are in  (waiting for raw to be read, waiting for jpeg/yuv) and only having the appropriate once canceled. Something like state_remotecap_stage = IDLE | RAW | FILEWRITE
Logged
Don't forget what the H stands for.
*

Offline srsa_4c

  • ******
  • 4451
Re: CHDK PTP interface
« Reply #865 on: 12 / September / 2012, 15:02:11 »
Still experimenting with state_shooting_progress. Also inspected core/main.c again. Unlike what I wrote above, some shooting related conditional parts of spytask are effective even in remote target mode. Many - raw related - parts of CHDK set state_shooting_progress to SHOOTING_PROGRESS_PROCESSING. Doing this in remotecap.c (or at the start of the raw hook in generic/capt_seq.c) works, with one drawback: shoot() won't finish until review time is over (issue observed on the A410, and is probably unrelated to these experiments). The block is caused by PROPCASE_SHOOTING, see shooting_in_progress(). This doesn't prevent another rs from executing, but other scripts will not run until PROPCASE_SHOOTING becomes 0 again.

#1
Code: (diff) [Select]
Index: core/remotecap.c
===================================================================
--- core/remotecap.c   (revision 2141)
+++ core/remotecap.c   (working copy)
@@ -212,7 +212,7 @@
         // allow raw hook to continue
         // TODO could do like filewrite wait
         hook_raw_save_complete();
-        state_shooting_progress=SHOOTING_PROGRESS_DONE; //shoot() needs this... TODO
+        state_shooting_progress=SHOOTING_PROGRESS_PROCESSING;
     }
 }
or
#2
Code: (diff) [Select]
Index: platform/generic/capt_seq.c
===================================================================
--- platform/generic/capt_seq.c   (revision 2141)
+++ platform/generic/capt_seq.c   (working copy)
@@ -50,10 +50,12 @@
     }
     else if ( (remotecap_get_target() & 2) > 0 ) //chdk raw requested
     {
+        state_shooting_progress=SHOOTING_PROGRESS_PROCESSING;
         remotecap_raw_available();
     }
     else
     {
+        state_shooting_progress=SHOOTING_PROGRESS_PROCESSING;
         raw_save_stage = RAWDATA_SAVED;
     }
 #else
Quote from: reyalp on 09 / September / 2012, 16:31:54
- should the remote capture selection only apply to the next shot, like exposure overrides, or should you need to explicitly cancel it ?
My initial code used the latter (rs sets it up at start and resets it when it has finished). Probably both approach should deal with the possibility of PTP connection problems.
Quote
If it's left on after the PTP connection goes away, that could confuse users. We don't explicitly know whether there is a PTP connection, but I guess we could check USB power is present (and clear remotecap if it's not found ?).
Could be good enough, until somebody decides to allow usb remote and ptp at the same time if that's possible at all (physw bit override or eventprocs like ConnectUSBCable, etc.)
Quote
Setting it once per shot shouldn't be much of a burden if you are using script to shoot, but I guess you could potentially set it once and have the user manually shooting with the shutter ?
Maybe. There are also some G series cams with proper remote control socket.
Committed my changes (changeset 2144), chose #1 from above.
The client (the code I know) was already prepared, so it will continue to work. RemoteCaptureGetData's Param2 returned parameter has slightly changed in its interpretation: it no longer shows the transferred chunk's type. I chose to increment PTP_CHDK_VERSION_MINOR to 104 (the hundreds shall reflect test revisions :) )
Tried and failed miserably to split the code part marked with //TODO turn this into a function in core/remotecap.c, remotecap_get_data_chunk(). With that code in a separate function (6 params), called by the raw and yuv cases, the asm code size almost doubled. Leaving it as it is, it's ugly but saves space...
« Last Edit: 15 / September / 2012, 21:17:53 by srsa_4c »
Logged
*

Offline reyalp

  • ******
  • 14079
Re: CHDK PTP interface
« Reply #866 on: 16 / September / 2012, 19:26:50 »
In chdkptp r301, I've started making a lua-based remoteshoot command. It's pretty messy at the moment, but it seems to work. This uses remotecap_init() on the camera to set up.

I understand the "script is already running" problem a bit a better now, of course the 'shoot()' command doesn't finish until the remote capture is done, so you can't cancel with script. The jpeg timeout works at least ;) In the new command, I get around this by using button presses instead of shoot, so the script can end as soon as shoot_full has been clicked.

Eventually, the rs2 command should be rolled into options for the regular shoot command, and the supporting code should be moved into re-usable functions in one of the lua modules.
Logged
Don't forget what the H stands for.
*

Offline srsa_4c

  • ******
  • 4451
Re: CHDK PTP interface
« Reply #867 on: 17 / September / 2012, 16:36:27 »
Quote from: reyalp on 16 / September / 2012, 19:26:50
In chdkptp r301, I've started making a lua-based remoteshoot command. It's pretty messy at the moment, but it seems to work. This uses remotecap_init() on the camera to set up.
Will try it soon.
Quote
I understand the "script is already running" problem a bit a better now, of course the 'shoot()' command doesn't finish until the remote capture is done, so you can't cancel with script. The jpeg timeout works at least ;) In the new command, I get around this by using button presses instead of shoot, so the script can end as soon as shoot_full has been clicked.
If this approach is the way to go, can we get rid of setting state_shooting_progress?

I plan to commit a few changes soon (raw hook, consistent file number request), if testing confirms that they work.

There may be a new issue: right now it's assumed that there is only one filewritetask activity after shooting. Cameras with Canon RAW are usually capable of storing a separate jpeg beside the native RAW (when the camera is set up to do so). In that case, only the first Canon file (my guess: RAW) will be retrieved and/or prevented from being written. Should we ignore this or support it? I don't have access to such camera, so can't try myself.
Changes committed (changeset 2163). rs2 works well if it encounters no problems.
I'm considering returning some useful data for debug use (chunk's memory address, could provide useful info about the jpeg or native raw buffers).
« Last Edit: 18 / September / 2012, 17:30:06 by srsa_4c »
Logged
*

Offline FREE Spirit

  • *
  • 21
Re: CHDK PTP interface
« Reply #868 on: 24 / September / 2012, 12:23:02 »
Hi
I have sx40hs and I installed the latest CHDK version: sx40hs-100i-1.2.0-2171-full_BETA
I tried both (ptpCamGui2.0.131) and (chdkptp-r291-win32)
in CHDK PTP, everything seems to be fine, even live view. But unfortunately, there are 2 problems:

1) when I press "shoot" to capture a picture, the shot is taken but the camera freezes and the viewfinder on PC becomes white noise (pic attached). The only thing can be done is to shut the camera off manually.
Same thing occurs in PTP Cam, except of course, there's no viewfinder.

2) I can't view files under the files tab. I tried copying the contents and got the following error message:
Code: [Select]
...hy\CHDK\LiveCapture\chdkptp-r291-win32\lua\chdku.lua:162: attempt to index local 'opts' (a nil value)
stack traceback:
...hy\CHDK\LiveCapture\chdkptp-r291-win32\lua\chdku.lua:162: in function 'mdownload'
...CHDK\LiveCapture\chdkptp-r291-win32\lua\gui_tree.lua:110: in function 'do_dir_download_dialog'
...CHDK\LiveCapture\chdkptp-r291-win32\lua\gui_tree.lua:273: in function <...CHDK\LiveCapture\chdkptp-r291-win32\lua\gui_tree.lua:272>
(tail call): ?
[C]: in function 'Popup'
menu.lua:15: in function 'popup'
...CHDK\LiveCapture\chdkptp-r291-win32\lua\gui_tree.lua:288: in function <...CHDK\LiveCapture\chdkptp-r291-win32\lua\gui_tree.lua:241>
(tail call): ?
[C]: in function 'MainLoop'
...aphy\CHDK\LiveCapture\chdkptp-r291-win32\lua\gui.lua:673: in function <...aphy\CHDK\LiveCapture\chdkptp-r291-win32\lua\gui.lua:659>
(tail call): ?
...phy\CHDK\LiveCapture\chdkptp-r291-win32\lua\main.lua:226: in main chunk
[C]: in function 'require'
[string "require('main')"]:1: in main chunkHowever, on PTP Cam, I can copy the files


any solution?
Logged
Beauty is in the eye of the beholder

my eye: Canon PowerShot SX40 HS :)
*

Offline reyalp

  • ******
  • 14079
Re: CHDK PTP interface
« Reply #869 on: 24 / September / 2012, 16:36:05 »
Quote from: FREE Spirit on 24 / September / 2012, 12:23:02
1) when I press "shoot" to capture a picture, the shot is taken but the camera freezes and the viewfinder on PC becomes white noise (pic attached). The only thing can be done is to shut the camera off manually.
Same thing occurs in PTP Cam, except of course, there's no viewfinder.
Do you have review mode set to "hold" on the camera ? Or a long time ?
Quote
2) I can't view files under the files tab. I tried copying the contents and got the following error message:
Code: [Select]
...hy\CHDK\LiveCapture\chdkptp-r291-win32\lua\chdku.lua:162: attempt to index local 'opts' (a nil value)
stack traceback:
This bug is fixed in the latest chdkptp svn. If you replace lua/chdku.lua with the one found here http://trac.assembla.com/chdkptp/browser/trunk/lua/chdku.lua?rev=293 it should be fixed.

I haven't put up another snapshot because I'm in the middle of some messy changes for remotecapture...
« Last Edit: 14 / October / 2012, 22:18:32 by reyalp »
Logged
Don't forget what the H stands for.
Pages: 1 ... 82 83 84 85 86 [87] 88 89 90 91 92 ... 125   Go Up
« previous next »
 

Related Topics