CHDKPTP File Downloading

reyalp

13938

Re: CHDKPTP File Downloading

« Reply #80 on: 18 / April / 2018, 14:52:02 »

Advertisements

Quote from: andrew.stephens.754365 on 18 / April / 2018, 05:44:09

Is there something similar to this to set the standard Canon UI shutter (e.g. 1/125)?

If you mean set using the units shown in the UI, no.

If you mean set a propcase equivalent to the manual controls in the Canon firmware, this is what USER_TV and USER_AV are. They are only effective in modes where the Canon firmware allows manual control of the corresponding exposure parameter.

On cameras without M or Tv, you can use USER_TV in "long shutter" mode.

Logged

Don't forget what the H stands for.

andrew.stephens.754365

461

Re: CHDKPTP File Downloading

« Reply #81 on: 18 / April / 2018, 15:11:03 »

Thanks.

Logged

jdstech

52

Re: CHDKPTP File Downloading

« Reply #82 on: 28 / June / 2018, 15:15:03 »

Hey guys, it's been a while.

Quote

Excellent - are you able to supply any test results?

Sorry for the lack of test results, I've been trying to take a shot of me throwing something in the air to check sync but I haven't been working with the scanner lately, I'll try to get something soon.

So in the interest of getting better models, I'm about to start working on implementation of some fixed pattern projectors. These will let me shine a pattern onto the person being scanned, which will be used in mesh recreation, then take a second shot without the pattern to use for texturing (I'm sure most of you already know about this procedure). However in order to pull this off I need to be able to take 2 consecutive shots very close together, as well as turn off the projectors after the first shot. For projector control I plan on switching over to rasberry pi, but since I haven't set up the projectors yet I'm putting this on the back burner. I can however get the coding for chdkptp out of the way. I've tried using:

Code: [Select]

mc:shoot({usb_pwr_sync=true, shots=2}) and this works, but in order to take the second shot I have to re-press the trigger button, and I have to wait a few seconds in between shots to get it to work. Is there any way to make it so that I press the trigger once and both shots are taken really quickly?

Another weird thing I'm having trouble with is downloading the images. I'm using

Code: [Select]

${shotseq} to make the separate directories for each shot, but for some reason I always end up with a single image being offset from the rest. So for instance, if I take two shots with three cameras, and the images they produce are name A, B, and C, I'll get a directory called 001, containing only image A, directory 002 containing A, B, and C, and directory 003 containing B and C. For some reason the shot sequence of one of the cameras is 1 ahead of all the others.

I'll attach the modified multicam.lua I'm using in case you wanna look at the code.

edit: I just realized I misspelled "multidl" under jmod.val. This wasn't a problem since I was using the gui and spelled it right there, but since I haven't attached the modified gui.lua it won't work for you guys. All you have to do is add a "t", currently it's spelled mulidl. If you guys are interested in playing around with the gui just let me know and I'll send the gui file.

multicam.lua (45.6 kB - downloaded 9 times.)

« Last Edit: 28 / June / 2018, 15:28:16 by jdstech »

Logged

reyalp

13938

Re: CHDKPTP File Downloading

« Reply #83 on: 29 / June / 2018, 00:33:02 »

Quote from: jdstech on 28 / June / 2018, 15:15:03

I've tried using:
Code: [Select]
mc:shoot({usb_pwr_sync=true, shots=2}) and this works, but in order to take the second shot I have to re-press the trigger button, and I have to wait a few seconds in between shots to get it to work. Is there any way to make it so that I press the trigger once and both shots are taken really quickly?

If you want hardware precision sync for the second shot, it needs to be triggered by the remote.

If you can tolerate the second shot being off by up to ~20ms, it would be possible to only trigger the first shot with the remote, and then have all the cameras wait a fixed amount of time before the second one.

In theory, you could arrange a higher precision interval (after the initial, hardware synced shot) using https://chdk.setepontos.com/index.php?topic=11342.0 but it would require C code.

Quote

For some reason the shot sequence of one of the cameras is 1 ahead of all the others.

Thanks. That's a bug.

Should be fixed in https://app.assembla.com/spaces/chdkptp/subversion/commits/839
You should be able to safely update just that line in your modified file.

Logged

Don't forget what the H stands for.

andrew.stephens.754365

461

Re: CHDKPTP File Downloading

« Reply #84 on: 04 / July / 2018, 08:16:40 »

Quote from: reyalp on 29 / June / 2018, 00:33:02

If you want hardware precision sync for the second shot, it needs to be triggered by the remote.

Most of my recent, synced single shot, testing has concentrated on setting things up with multicam.lua then enabling the remote and subsequently turning off script and closing the ptp connection. Having taken the single shot (one or twopush), restart connection, restart script and download (aim being, hopefully, increased reliability).

A requirement to take two, synced, shots, in quick succession, on all cameras had mostly escaped me. With respect to that, the following is loosely described as I only vaguely understand what is or could be possible.

If I am reading correctly (shots=2), multicam.lua function mc:shoot(opts) first causes cameraside preshoot (halfpress) followed by cameraside function cmds.shoot_burst_usb_pwr() which provides maintenance of halfpress until after end of 2nd shot. That is not available in any two stage combination onepush/twopush remote operation (both contain an autofocus/autoexposure stage). Further, the cameraside hook_raw.wait_ready will cause any 5V->0V transistions (after the first) to be ignored until "after shot_histogram has built the raw histogram and DNG exif has been captured, but before any raw or DNG file has been written: http://chdk.wikia.com/wiki/Script_Shooting_Hooks". Only after the first hook_raw.continue() does the second press('shoot_full_only') / usb_sync_wait(true) occur. Of course, none of that is available in the remote one/twopush combination I have referred to.

However, what I do vaguely wonder is, without ptp connection or script running, if I first executed a remote onepush shot would I still need to wait (some maximum microcontoller provided fixed time) until "after shot_histogram has built the raw histogram and DNG exif has been captured, but before any raw or DNG file has been written" before executing the first rising/falling edge of a subsequent twopush remote shot?

The aim being (if that wait, or some of it, was not required):
to have the autofocus / autoexposure (not relevant to me in M mode) associated with the second shot being worked on (or completed) while the camera is also doing "stuff" related to the first exposure in order that the second pulse of the second twopush can occur as quickly as possible after the end of the 5v->0V transistion of the first shot (whose exposure starts in a tight band around 132ms - 4 std periods - after that falling edge).

Hope that, sort of, makes sense?

fmi:

Quote from: waterwingz on 07 / February / 2015, 11:31:05

But with one push/normal/sync, the sequence is :
CHDK detects the 0V - 5V transistion on the USB power pin
CHDK sets the bit the makes the camera think that the shutter button has been pressed half way.
CHDK waits for the camera to indicate the focus & exposure have been set.
CHDK sets the bit the makes the camera think that the shutter button has been pressed fully.
CHDK waits for the USB 5V line to change back to 0V
CHDK detects the 5V - 0V transistion on the USB power pin
CHDK clear sets the bits that makes the camera think that the shutter button has been half & fully pressed.
In this process, the actual shot is released at step 4 but pauses waiting for the USB 5V to go to 0V. It then occurs as quickly as the Canon firmware can do so.

So in the one push/normal/sync, there is no "half press" state that you can hold & maintain - CHDK goes from nothing to half press to full press as quickly as it can. AND IT FOCUSES AND SETS EXPOSURE DURING THE HALF PRESS JUST LIKE YOU OBSERVED.

« Last Edit: 04 / July / 2018, 11:28:02 by andrew.stephens.754365 »

Logged

reyalp

13938

Re: CHDKPTP File Downloading

« Reply #85 on: 04 / July / 2018, 18:01:26 »

Quote from: andrew.stephens.754365 on 04 / July / 2018, 08:16:40

Most of my recent, synced single shot, testing has concentrated on setting things up with multicam.lua then enabling the remote and subsequently turning off script and closing the ptp connection. Having taken the single shot (one or twopush), restart connection, restart script and download (aim being, hopefully, increased reliability).

This seems unnecessary convoluted. Does multicam with usb_pwr_sync not work?

If available, using one of the new alternate remote inputs avoid USB related stability issues, though not the fact that the hard loop waiting for remote may cause USB timeouts. These should be easy to add on any camera with the required hardware.

Quote

A requirement to take two, synced, shots, in quick succession, on all cameras had mostly escaped me. With respect to that, the following is loosely described as I only vaguely understand what is or could be possible.

If you use script with usb_sync_wait (as multicam usb_pwr_sync does), the onepush/twopush shouldn't matter, you just need to ensure that the remote goes from on to off (+5v present to absent if using USB) when you want to shoot.

The only restriction on when it comes back on are that it must happen after the shot is triggered and before the camera starts waiting for the next shot. The pulse should be recognized within tens of ms (probably much less), and the camera shouldn't be ready to shoot again for at least several hundred ms.

With the current code, the shooting rate will be limited by the fact that there's no programmatic to way to tell when the shots are done. So you need to measure the the shot time of your cameras and add some reasonable margin.

I verified this works as expected with the HDMI HPD remote, using a switch that connects the +5v and HPD pins when pressed:
1) press switch
2) execute
!mc:shoot({usb_pwr_sync=true,shots=2})
3) briefly release switch
4) wait for shot to complete
5) release switch again

Logged

Don't forget what the H stands for.

reyalp

13938

Re: CHDKPTP File Downloading

« Reply #86 on: 05 / July / 2018, 01:10:31 »

Quote from: reyalp on 04 / July / 2018, 18:01:26

...though not the fact that the hard loop waiting for remote may cause USB timeouts.

Thinking about this more, I realized there is a fairly simple workaround. Script hook_shoot blocks just before the remote busy loop. So script can wait with sleep until the remote comes on, and then pass to remote code which waits for it to go off.

This means if you use a single short pulse, the time in the busy loop is low enough not to hurt the USB connection, but the final trigger is still done with full precision.

I added code to support this in chdkptp r841, with an option called remote_on_wait, which specifies how many milliseconds the script should wait for the remote to come on. If the time passes, the camera will just continue on to the regular remote code, which will see the signal is already off, and shoot anyway.

I also fixed some issues with timeouts that would have made multiple shots produce confusing errors.

You can use this like

Code: [Select]

!mc:shoot({remote_sync=true,remote_on_wait=30000,shots=2})

(I renamed usb_pwr_sync to remote_sync)

Shooting as fast as possible under program control needs one more piece: Instead of sending status after all the shots are done, shoot_burst_usb_pwr needs an option to send a message each time it's ready. This should be relatively simple to do.

Logged

Don't forget what the H stands for.

andrew.stephens.754365

461

Re: CHDKPTP File Downloading

« Reply #87 on: 05 / July / 2018, 06:41:12 »

Quote from: reyalp on 05 / July / 2018, 01:10:31

This means if you use a single short pulse, the time in the busy loop is low enough not to hurt the USB connection, but the final trigger is still done with full precision.

I added code to support this in chdkptp r841

I see that - very neat!

Quote from: reyalp on 05 / July / 2018, 01:10:31

Shooting as fast as possible under program control needs one more piece: Instead of sending status after all the shots are done, shoot_burst_usb_pwr needs an option to send a message each time it's ready. This should be relatively simple to do.

Understood.

Quote from: reyalp on 04 / July / 2018, 18:01:26

This seems unnecessary convoluted. Does multicam with usb_pwr_sync not work?

If available, using one of the new alternate remote inputs avoid USB related stability issues, though not the fact that the hard loop waiting for remote may cause USB timeouts. These should be easy to add on any camera with the required hardware.

It's actually very straightforward. I've now mostly pulled the 16 camera rig apart in readiness for microcontroller switching addition and design to (flexibly) add further 16 camera units. On last testing, throughout the course of an entire day, while shooting, using a precision sync build and the very tight loops it contains, without script or ptp connected and then reconnecting/starting script/download for each shot I only had a single camera crash.

The previous day, with a non precision sync build, and ptp/script continuously active system stability was a nightmare with multiple crashes. Did I tweak a transformer output between the two sessions - I can't remember but I currently "feel" the less in the way of script/ptp the better (even though the closed loop functionality you refer to is lost).
On hardware - to add a switch wire to the usb adapters that Hardware Hacker identified (https://chdk.setepontos.com/index.php?topic=13294.msg136643#msg136643) is a 10-15 minute job (I was lucky enough to buy a large batch at 20 pence each). I don't necessarily see greater reliability with the 10/11 pin usb/av connector and it seems a comparitively tedious route (sx150is doesn't have hdmi).

Lots still to think about though.

Anyway, using the remote (rather than multicam) for shooting, it seems there is no way to minimise the extra autofocus time for the second shot.

Thanks for your comments (and great code).

Edit:
I just remembered that in the unstable testing referred to above, with script and ptp active, I had been using the following multicam.lua cameraside code to shoot:
https://chdk.setepontos.com/index.php?topic=12368.msg134302#msg134302

Code: [Select]

function cmds.usb_sync_wait()                            --e.g. to run !return mc:cmdwait('usb_sync_wait')                              usb_sync_wait(1)
    press('shoot_full')
    write_status(true)
    sleep(9000) --> drop from 5V to 0V in here
    release('shoot_full')
end

So I was in the hard loop waiting for the remote for long periods. Little wonder, perhaps, that I had experienced such instability.

fmi:

Quote from: andrew.stephens.754365 on 27 / September / 2017, 11:16:48

From this, the minimum prefocus period was 680ms, the maximum 770ms

« Last Edit: 05 / July / 2018, 08:42:47 by andrew.stephens.754365 »

Logged

jdstech

52

Re: CHDKPTP File Downloading

« Reply #88 on: 03 / August / 2018, 12:30:40 »

So is the time you have to wait between taking shots just the time it takes for the camera to process the picture? Apparently if you're using fixed pattern projectors in your camera array the time between the first shot (where the projectors are on) and the second shot (without the projectors) should be as little as a few dozen ms, which is a bit of a problem. Since I'm using power sync I'm guessing I could just wire up a timer that cuts the power a second time after x amount of milliseconds so the second shot is synced, but unless I can get the interval between shots down I'm not sure if that would do me any good.

Logged

reyalp

13938

Re: CHDKPTP File Downloading

« Reply #89 on: 03 / August / 2018, 13:48:53 »

Quote from: jdstech on 03 / August / 2018, 12:30:40

So is the time you have to wait between taking shots just the time it takes for the camera to process the picture?

The time it takes the slowest camera to process the picture, plus communication overhead if you are relying on program control to know when they are ready.

Quote

Apparently if you're using fixed pattern projectors in your camera array the time between the first shot (where the projectors are on) and the second shot (without the projectors) should be as little as a few dozen ms, which is a bit of a problem.

You definitely won't get this on low end powershots, the maximum continuous rate tends to be ~1 FPS.
Some higher end cameras have modes that take a burst of shots before processing (for HDR and other special effects), but significant work would likely be required to make them usable in CHDK.

Logged

Don't forget what the H stands for.