[Gphoto-user] Canon 1300D: can only capture one image; second capture fails

[Oliver Bendig]

Hi,

I'm facing the issue that my new EOS 1300D cannot capture more then one image
with gphoto. The camera is detected and the first call to gphoto successfully
takes an image. If I request to capture an image again, the camera gets stuck
somehow and no shutter noise is done at all. If I push a button on the camera
directly, it shows busy on the display. If I switch the camera off and on again,
I can take one image again. But only one ;-)

AF is switched off, Sleep mode is deactivated.
ghoto&libgphoto were compiled manually. gphoto2 is the latest 2.5.11, libgphoto
is the latest 2.5.12, Ubuntu 12.10; kernel 3.5.0-31
I tested my installation successfully with my 5DMark3 and my 100D. My self
written program that directly calls libgphoto.so has the same issue.


I created 3 debug files:

This is the debug from the first capture with the successful image capture:
http://bit.ly/2kSxIu5

This is a debug from a second capture where the camera gets stuck somehow for a
long time until I send Ctrl+C. No image was taken, no shutter noise
http://bit.ly/2krEtCy

This is a debug from a second capture where the camera seems to run into a
timeout. No image was taken, no shutter noise
http://bit.ly/2jZox9J


Thank you very much and kind regards, Oliver

[Dr. Volker Jaenisch]

Hi Oliver!

Post by Oliver Bendig
I'm facing the issue that my new EOS 1300D cannot capture more then
one image with gphoto. The camera is detected and the first call to
gphoto successfully takes an image. If I request to capture an image
again, the camera gets stuck somehow and no shutter noise is done at
all. If I push a button on the camera directly, it shows busy on the
display. If I switch the camera off and on again, I can take one image
again. But only one ;-)

I have a similiar issue with a 1200D. 2 out of 10 fotos are not taken
and the camera locks up afters a while completly.

In gphoto2 debug-mode however the camera works better but not allways
reliable. My canon 6D in comparison runs like a charm with the same
lines of code. No droppings no locks.

Utilizing "ptpy" an experimental python implementation of the PTP
Protocol I have debugged a bit. Seems that the canon 1200D does not send
events if a foto was taken. So the software has to antipicate the right
time to load down the image from the camera. And again the 6D sends
absolutly reliable events when a foto was taken.

The problem here is not gphoto2 it is Canon. It seems that Canon has no
interest in following standards (The PTP ISO norm) - at least for cheap
cameras. OK standards may constrict innovation so I understand that
extending a well defined protocol can be a good thing. But if one
extends a protocol then it would be nice if this extension is documented
and published.

The gphoto2 community does a great job to deal with that s**t that comes
out of the Canon cameras.

My current project is to build software for 70 high-End Camera-Webcam
for the Alps. We started with canon but if we find another camera with
better reliability we will trash Canon as soon as possible. Sorry to say
that since I am a Canon photographer for ages.

May be it is time to build Open Hardware/Software Cameras.

Cheers,

Volker

[Oliver Bendig]

Hi Volker,

thanks for sharing your findings!

I didn't thought that there will be such a problem with the 1300D. I had the
1100D in my photo booth for years now until the USB connection of the camera was
not recognized anymore. My photo booth software that I wrote years ago worked
perfectly for thousands of photos with libgphoto and the 1100D.

But okay, if the camera isn't compliant with PTP anymore and breaks with gphoto
(and reliability) then I will return the camera and get something else.

Thank you very much,
Olli

[Dr. Volker Jaenisch]

Hi Oliver!

Post by Oliver Bendig
I didn't thought that there will be such a problem with the 1300D. I
had the 1100D in my photo booth for years now until the USB connection
of the camera was not recognized anymore. My photo booth software that
I wrote years ago worked perfectly for thousands of photos with
libgphoto and the 1100D.

Yep.The 1100D is used by lots of people without problems. Lots of
Foto-Webcam in the Alps run the 1100D.

Post by Oliver Bendig
But okay, if the camera isn't compliant with PTP anymore and breaks
with gphoto (and reliability) then I will return the camera and get
something else.

I am not the authority here, but I assume that even the 1100D was not
complying with PTP.

Please do not throw away the 1300D. It is a lovely camera.

Use it to support the others here in the community to craft better
software.

* Provide some debug logs
* If you like I can give you some instructions with ptpy to debug your
camera from python.

Maybe there is a simple solution to find.

Cheers,

Volker

[Marcus Meissner]

Hi,

Post by Dr. Volker Jaenisch
Hi Oliver!

Post by Oliver Bendig
I didn't thought that there will be such a problem with the 1300D. I
had the 1100D in my photo booth for years now until the USB connection
of the camera was not recognized anymore. My photo booth software that
I wrote years ago worked perfectly for thousands of photos with
libgphoto and the 1100D.

Yep.The 1100D is used by lots of people without problems. Lots of
Foto-Webcam in the Alps run the 1100D.

Post by Oliver Bendig
But okay, if the camera isn't compliant with PTP anymore and breaks
with gphoto (and reliability) then I will return the camera and get
something else.

I am not the authority here, but I assume that even the 1100D was not
complying with PTP.
Please do not throw away the 1300D. It is a lovely camera.
Use it to support the others here in the community to craft better
software.
* Provide some debug logs
* If you like I can give you some instructions with ptpy to debug your
camera from python.
Maybe there is a simple solution to find.

They all talk PTP, but use mostly "vendor extension" commands, which
we do not have documentation or description for.

So we mostly guess how to use them right, or do USB sniffing to
try it out.

What I think might be missing here is a bit of waiting between
the full shutter press and full shutter release.

If you are curious to try something... This basically executes the
shutter commands the capture function does, plus some additional
waiting bettween "Press 2" and "Release 2".

export LANG=C
gphoto2 --wait-event=1s --set-config eosremoterelease="Press 1" --wait-event=1s --set-config eosremoterelease="Press 2" --wait-event=100ms --set-config eosremoterelease="Release 2" --set-config eosremoterelease="Release 1" --wait-event-and-download=5s

Ciao, Marcus

[Oliver Bendig]

Hi Marcus, Hi Volker,

Post by Marcus Meissner
What I think might be missing here is a bit of waiting between
the full shutter press and full shutter release.
If you are curious to try something... This basically executes the
shutter commands the capture function does, plus some additional
waiting bettween "Press 2" and "Release 2".
export LANG=C
gphoto2 --wait-event=1s --set-config eosremoterelease="Press 1"
--wait-event=1s --set-config eosremoterelease="Press 2" --wait-event=100ms
--set-config eosremoterelease="Release 2" --set-config
eosremoterelease="Release 1" --wait-event-and-download=5s

I played a little with the timings. The first wait-event has to be larger then
270ms to make the camera release the shutter.

working:
-----------
gphoto2 --wait-event=270ms --set-config eosremoterelease="Press 1"
--wait-event=80ms --set-config eosremoterelease="Press 2" --wait-event=80ms
--set-config eosremoterelease="Release 2" +--set-config
eosremoterelease="Release 1" --wait-event-and-download=5s

not working:
----------------
gphoto2 --wait-event=250ms --set-config eosremoterelease="Press 1"
--wait-event=80ms --set-config eosremoterelease="Press 2" --wait-event=80ms
--set-config eosremoterelease="Release 2" +--set-config
eosremoterelease="Release 1" --wait-event-and-download=5s

The shutter releases with every call. But after saving the file, gphoto get's an
error -1:
UNKNOWN PTP Property d11b changed
UNKNOWN Camera Status 1
UNKNOWN PTP Property d11b changed
Saving file as capt0000.jpg
UNKNOWN Camera Status 0
*** Error (-1: 'Unspecified error') ***

The jpg file was successfully written to disk and the file contains the correct
image.
The debug trace is here: http://bit.ly/2l0Bima

To test the reliability, I called gphoto in a for loop with 10 iterations. This
didn't work reliable with a wait of 270 like in "single step" when called
without any sleep between the iteration. I had to increase to 500ms to get the
camera release the shutter in every iteration. With a sleep of 1sec after each
iteration, I could decrease the wait to 360ms:

successfully captured 10 images:
for i in `echo 1 2 3 4 5 6 7 8 9 10`; do rm capt0000.jpg; gphoto2
--wait-event=360ms --set-config eosremoterelease="Press 1" --wait-event=80ms
--set-config eosremoterelease="Press 2" --wait-event=80ms --set-config
eosremoterelease="Release 2" +--set-config eosremoterelease="Release 1"
--wait-event-and-download=5s; sleep 1; done

In the for loop, the jpg always contains the first image that was taken in that
sequence. I moved the camera in between so that the image should differ. But it
was always the first image from that loop.

Best regards, Oliver

[Dr. Volker Jaenisch]

Hi Oliver!

Do you have your camera in autofocus or manual focus mode?

Volker

[Oliver Bendig]

Hi Volker,

the auto focus was set to AI servo so that it doesn't block the shutter to
release when no focus is possible. For the lens I think it was manual mode, but
I'm not 100% sure (only 99%). I have to prove that. AI servo and manual focus
are the settings that I used in my photo booth and that proved to be very
reliable with my 1100D before.

Regards, Oliver

Post by Dr. Volker Jaenisch
Hi Oliver!
Do you have your camera in autofocus or manual focus mode?
Volker
--
=========================================================
inqbus Scientific Computing Dr. Volker Jaenisch
Richard-Strauss-Straße 1 [phone]
86956 Schongau-West http://www.inqbus.de
=========================================================

[Marcus Meissner]

Post by Oliver Bendig
Hi Marcus, Hi Volker,

Post by Marcus Meissner
What I think might be missing here is a bit of waiting between
the full shutter press and full shutter release.
If you are curious to try something... This basically executes the
shutter commands the capture function does, plus some additional
waiting bettween "Press 2" and "Release 2".
export LANG=C
gphoto2 --wait-event=1s --set-config eosremoterelease="Press 1"
--wait-event=1s --set-config eosremoterelease="Press 2" --wait-event=100ms
--set-config eosremoterelease="Release 2" --set-config
eosremoterelease="Release 1" --wait-event-and-download=5s

I played a little with the timings. The first wait-event has to be larger then
270ms to make the camera release the shutter.
-----------
gphoto2 --wait-event=270ms --set-config eosremoterelease="Press 1"
--wait-event=80ms --set-config eosremoterelease="Press 2" --wait-event=80ms
--set-config eosremoterelease="Release 2" +--set-config
eosremoterelease="Release 1" --wait-event-and-download=5s
----------------
gphoto2 --wait-event=250ms --set-config eosremoterelease="Press 1"
--wait-event=80ms --set-config eosremoterelease="Press 2" --wait-event=80ms
--set-config eosremoterelease="Release 2" +--set-config
eosremoterelease="Release 1" --wait-event-and-download=5s
The shutter releases with every call. But after saving the file, gphoto get's an
UNKNOWN PTP Property d11b changed
UNKNOWN Camera Status 1
UNKNOWN PTP Property d11b changed
Saving file as capt0000.jpg
UNKNOWN Camera Status 0
*** Error (-1: 'Unspecified error') ***

You have a typo in the commandline ... "+--set-config" should be "--set-config"

Post by Oliver Bendig
The jpg file was successfully written to disk and the file contains the correct
image.
The debug trace is here: http://bit.ly/2l0Bima
To test the reliability, I called gphoto in a for loop with 10 iterations. This
didn't work reliable with a wait of 270 like in "single step" when called
without any sleep between the iteration. I had to increase to 500ms to get the
camera release the shutter in every iteration. With a sleep of 1sec after each
for i in `echo 1 2 3 4 5 6 7 8 9 10`; do rm capt0000.jpg; gphoto2
--wait-event=360ms --set-config eosremoterelease="Press 1" --wait-event=80ms
--set-config eosremoterelease="Press 2" --wait-event=80ms --set-config
eosremoterelease="Release 2" +--set-config eosremoterelease="Release 1"
--wait-event-and-download=5s; sleep 1; done
In the for loop, the jpg always contains the first image that was taken in that
sequence. I moved the camera in between so that the image should differ. But it
was always the first image from that loop.

I am also wondering if you can decrease or increase the wait after after the "Press 2",
which is the time we hold down the virtual shutter button.

I see you reduced it from 100ms to 80ms already.

(The gphoto capture code currently does not have a wait there, which is probably
the core issue.)

Ciao, Marcus

[Oliver Bendig]

Post by Marcus Meissner

Post by Oliver Bendig
The shutter releases with every call. But after saving the file, gphoto get's an
UNKNOWN PTP Property d11b changed
UNKNOWN Camera Status 1
UNKNOWN PTP Property d11b changed
Saving file as capt0000.jpg
UNKNOWN Camera Status 0
*** Error (-1: 'Unspecified error') ***

You have a typo in the commandline ... "+--set-config" should be "--set-config"

You're absolutely right. That fixed the issue. I saw the plus but thought it was
intentional. It was obviously generated by my mail client.

Post by Marcus Meissner
I am also wondering if you can decrease or increase the wait after after the "Press 2",
which is the time we hold down the virtual shutter button.
I see you reduced it from 100ms to 80ms already.
(The gphoto capture code currently does not have a wait there, which is probably
the core issue.)
From my tests only the first wait seems the has an impact. I reduced both waits

after Press 1 and 2 to 0 and iterated ten times without problem.

for i in `seq 9`; do rm capt0000.jpg; gphoto2 --wait-event=270ms --set-config
eosremoterelease="Press 1" --wait-event=0ms --set-config eosremoterelease="Press
2" --wait-event=0ms --set-config eosremoterelease="Release 2" --set-config
eosremoterelease="Release 1" --wait-event-and-download=2s; done

Post by Marcus Meissner

Post by Oliver Bendig
In the for loop, the jpg always contains the first image that was taken in that
sequence. I moved the camera in between so that the image should differ. But it
was always the first image from that loop.

The problem that always the same photo is written to disk still occurs. It
occurs even if I execute two single capture statements manually. I have to wait
some seconds between both calls and then the correct images were written to
disk.


Regards, Oliver

[Marcus Meissner]

Post by Oliver Bendig

Post by Marcus Meissner

Post by Oliver Bendig
The shutter releases with every call. But after saving the file, gphoto get's an
UNKNOWN PTP Property d11b changed
UNKNOWN Camera Status 1
UNKNOWN PTP Property d11b changed
Saving file as capt0000.jpg
UNKNOWN Camera Status 0
*** Error (-1: 'Unspecified error') ***

You have a typo in the commandline ... "+--set-config" should be "--set-config"

You're absolutely right. That fixed the issue. I saw the plus but thought it was
intentional. It was obviously generated by my mail client.

Post by Marcus Meissner
I am also wondering if you can decrease or increase the wait after after the "Press 2",
which is the time we hold down the virtual shutter button.
I see you reduced it from 100ms to 80ms already.
(The gphoto capture code currently does not have a wait there, which is probably
the core issue.)
From my tests only the first wait seems the has an impact. I reduced both waits

after Press 1 and 2 to 0 and iterated ten times without problem.
for i in `seq 9`; do rm capt0000.jpg; gphoto2 --wait-event=270ms --set-config
eosremoterelease="Press 1" --wait-event=0ms --set-config eosremoterelease="Press
2" --wait-event=0ms --set-config eosremoterelease="Release 2" --set-config
eosremoterelease="Release 1" --wait-event-and-download=2s; done

Post by Marcus Meissner

Post by Oliver Bendig
In the for loop, the jpg always contains the first image that was taken in that
sequence. I moved the camera in between so that the image should differ. But it
was always the first image from that loop.

The problem that always the same photo is written to disk still occurs. It
occurs even if I execute two single capture statements manually. I have to wait
some seconds between both calls and then the correct images were written to
disk.

Took some time to find some time to look into it.

For the initial startup issue .... I spotted a small pattern which we could
use for waiting. The 0xd11b property (Available images) is send twice
with a value, but we can only start after it is send for the second time.

Have to think how to implement this correctly.

The second problem where it always return the same image. This is new.
Can you capture debuginfo for two consecutive captures that show this problem?

Ciao, Marcus

[Oliver Bendig]

Post by Marcus Meissner
Took some time to find some time to look into it.
For the initial startup issue .... I spotted a small pattern which we could
use for waiting. The 0xd11b property (Available images) is send twice
with a value, but we can only start after it is send for the second time.
Have to think how to implement this correctly.

I played around with the camera and gphoto to reproduce my same-image-problem. I
got irritated by the LANG=C environment variable. I missed it to be set and when
I started to play with the camera, I wondered why there was not any capture at
all - even with the gphoto2 calls that proved to be working before. After I read
your mail again, realized that I missed to set LANG=C and set it accordingly,
everything worked again as before with the same timings as before. Now I can
tell: if LANG=de_DE.UTF-8, no capture is possible at all. But you probably knew
that before. ;-)

Post by Marcus Meissner
The second problem where it always return the same image. This is new.
Can you capture debuginfo for two consecutive captures that show this problem?

Hmm, it seems that this was my fault somehow. Luckily, it is not reproducible
anymore. Maybe I had an issue with my loop and the way it copied the images.
I rewrote my test script for taking many images in a loop and now it worked
correctly all the times. I can't explain anymore...

Thank you very much for all you patience with this issue!
Best regards, Oliver

[Marcus Meissner]

Post by Oliver Bendig

Post by Marcus Meissner
Took some time to find some time to look into it.
For the initial startup issue .... I spotted a small pattern which we could
use for waiting. The 0xd11b property (Available images) is send twice
with a value, but we can only start after it is send for the second time.
Have to think how to implement this correctly.

I played around with the camera and gphoto to reproduce my same-image-problem. I
got irritated by the LANG=C environment variable. I missed it to be set and when
I started to play with the camera, I wondered why there was not any capture at
all - even with the gphoto2 calls that proved to be working before. After I read
your mail again, realized that I missed to set LANG=C and set it accordingly,
everything worked again as before with the same timings as before. Now I can
tell: if LANG=de_DE.UTF-8, no capture is possible at all. But you probably knew
that before. ;-)

The configuration values are translated, thats why its needed to switch to english :)


As short cut, gphoto2 --wait-event=300ms --capture-image-and-download just might work
too (as we just need the initial wait).

Post by Oliver Bendig

Post by Marcus Meissner
The second problem where it always return the same image. This is new.
Can you capture debuginfo for two consecutive captures that show this problem?

Hmm, it seems that this was my fault somehow. Luckily, it is not reproducible
anymore. Maybe I had an issue with my loop and the way it copied the images.
I rewrote my test script for taking many images in a loop and now it worked
correctly all the times. I can't explain anymore...
Thank you very much for all you patience with this issue!
Best regards, Oliver

Ok, good to hear :)

Ciao, Marcus

[Oliver Bendig]

As short cut, gphoto2 --wait-event=300ms --capture-image-and-download just
might work
too (as we just need the initial wait).

Yes, that works reliable. As expected, the 300ms is the time to wait. My test
with 200ms failed for the second iteration.

CIao, Oliver

[Oliver Bendig]

Hi Volker,

Post by Dr. Volker Jaenisch
Please do not throw away the 1300D. It is a lovely camera.
Use it to support the others here in the community to craft better
software.
* Provide some debug logs
* If you like I can give you some instructions with ptpy to debug your
camera from python.
Maybe there is a simple solution to find.

Yes, that's a good idea. I already collected debug traces and attached
them to my first message. I had a look at them but I'm not deep enough
into gphoto internals to really have an idea what might be the issue or
what to look for.
I can of course collect more as long as I have the camera not returned. I
only need a short advise what would be interesting to collect data from.

Kind regards, Oliver