[gphoto-features] [ gphoto-Feature Requests-2881948 ] Fuji S5Pro remote control

[SourceForge.net]

Feature Requests item #2881948, was opened at 2009-10-19 20:05
Message generated for change (Comment added) made by marcusmeissner
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=358874&aid=2881948&group_id=8874

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: camera support
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: albatros_la81 (albatros_la81)
Assigned to: Marcus Meissner (marcusmeissner)
Summary: Fuji S5Pro remote control

Initial Comment:
I would like to ask if there is a way to give the team an hand in order to develop the remote control features for Fuji S5Pro. Currently I am able to retrieve image files from the camera and delete them through PTP/MTP protocol. I see that all the Nikon DSLRs are supported from this point of view, I hope the remote controlling of the S5Pro to be not so different from the D200 since both cameras share the same body and perhaps something about the internal electronics (despite the software and the sensors actually being different). Any suggestion about the way to proceed is truly appreciated!

Thanks

P.S. The camera is currently recognized as a generic ptp/mtp camera. I think it is just a matter of "eye-candy" to add the correct name, however the following is the descriptor ID coming from the USB bus when attaching the camera: ID 04cb:01c3 Fuji Photo Film Co., Ltd. Just in case you want to add it to the list of the supported cameras.

----------------------------------------------------------------------

>Comment By: Marcus Meissner (marcusmeissner)
Date: 2009-10-23 21:43

Message:
and gphoto2 --auto-detect  does not show any devices?


ok, perhaps we need to list the ID explicitly. I have built a temporary
libgphoto2 tarball,

It is at:

http://www.lst.de/~mm/libgphoto2-2.4.7.2.tar.bz2

can you check that please, if gphoto2 --auto-detect does not see it?

----------------------------------------------------------------------

Comment By: albatros_la81 (albatros_la81)
Date: 2009-10-23 21:40

Message:
I apologize... Now I have updated the three lsusb -v outputs: the
attachment is the same. I do not see any change in the ID, there seems to
be changes in wMaxPacketSize and bInterval.

----------------------------------------------------------------------

Comment By: Marcus Meissner (marcusmeissner)
Date: 2009-10-23 21:27

Message:
with  -v please ("lsusb -v") to get the details ... the usb id is still
there :/

----------------------------------------------------------------------

Comment By: albatros_la81 (albatros_la81)
Date: 2009-10-23 21:16

Message:
So, the last two modes give the exact same result. I have attached the
three lsusb, one per each of the three modes. When in window$, connecting
the camera in the second mode, I obtain both memory card access to the
camera and camera remote control via HS-v3, while in the first mode I get
the memory card access only. I have not tried yet, but I suppose that in
the third mode I will get the remote control only.

----------------------------------------------------------------------

Comment By: Marcus Meissner (marcusmeissner)
Date: 2009-10-23 20:58

Message:
so we need to be in those "Shutter *" modes

can you run lsusb -v for  the latter two?

----------------------------------------------------------------------

Comment By: albatros_la81 (albatros_la81)
Date: 2009-10-23 20:52

Message:
Ok, understood! So yes: the camera is able to work in three different
modes, configurable through the in-camera setup. The first one is the one I
have used so far to transfer the files with gphoto2, and it is labeled as
"MTP/PTP", the second one is the "Shutter Auto PC", the third one is the
"Shutter PC Only". The last two ones are mandatory if I want HS-v3 to work.
I have just tried to make gphoto2 recognize the camera with these settings,
but it does not find it.

----------------------------------------------------------------------

Comment By: Marcus Meissner (marcusmeissner)
Date: 2009-10-23 20:04

Message:
no, did you need to switch anything on the camera to make it work in the
windows app?

beause the base settings are different from what the gphoto logfile
contains :(

----------------------------------------------------------------------

Comment By: Marcus Meissner (marcusmeissner)
Date: 2009-10-23 19:57

Message:
if you can capture a full trace between  pluggin the camera in and starting
the app .it would also be helpfuil, since it could contain the magic that
switches the ptp modes

----------------------------------------------------------------------

Comment By: albatros_la81 (albatros_la81)
Date: 2009-10-23 19:51

Message:
I have attached the output of lsusb -v. Maybe I have changed something
about aperture and or mode between a couple of trunks of the sniff
(honestly, I do not remember exactly). There is the chance to change the
whole settings of the camera, so there are a lot of things which can be
triggered. Do you suggest to change only one thing at a time or to make a
whole range of settings per each trigger (for example, change among all the
aperture values in one unique sniff, and so on with all the switches)?

----------------------------------------------------------------------

Comment By: Marcus Meissner (marcusmeissner)
Date: 2009-10-23 19:41

Message:
the traces are helpful.

they show way more stuff reported as by the original --summary run.

did you change any setting on the camera before running the tool?

could you also run "lsusb -v" and attach the part of the camera itself?

----------------------------------------------------------------------

Comment By: albatros_la81 (albatros_la81)
Date: 2009-10-23 19:05

Message:
The tar.bz2 archive contains some xml coming frome the sniffer. They have
been done sequentially, so you can track the genesis of the commands by
taking a look at the dimension of the files (the second one contains also
the first one, the third contains the first and the second and so on til
the last one which contains the whole sniff: a diff will isolate the single
trunks, I have left them as they are to let you do as you want). There are
pauses between each executed command in order not to track down all the
un-useful stuff. The filenames are self-explanatory, or I hope so!

Do not hesitate to ask if you think I have done something wrong or if I
can do this into a manner more suitable to your needs!

P.S. I forgot to switch the shutter speed command when in "S" mode, but
for now let's see if you manage to understand something by these inputs.

----------------------------------------------------------------------

Comment By: Marcus Meissner (marcusmeissner)
Date: 2009-10-22 20:07

Message:
can you export those to XML from SNoopyPro and attach here? Perhaps I can
already make sense of it

----------------------------------------------------------------------

Comment By: albatros_la81 (albatros_la81)
Date: 2009-10-22 19:15

Message:
Good news: I have complete access to a window$ machine with HS-v3 installed
on it. I have tried to sniff the usb bus communications with snoopypro and
I get a lot of information (hopefully useful!) as expected. Now since I am
new to the reverse engineering thing, I ask you if there is a more
effective way to proceed in order to track down the useful data. The more
obvious technique is to start sniffing the bus just before changing a
parameter, than stopping it a moment after, and proceed that way for each
switch... am I right? The thing I have noticed is that a huge amount of
data is constantly transferred, maybe because there is some real-time data
shown on HS-v3, generally related to the exposimeter, so I understand that
it is not a simple task to isolate the meaningful part of the stream. Any
suggestion is really welcome, then I will try to do as much as possible by
myself!

----------------------------------------------------------------------

Comment By: albatros_la81 (albatros_la81)
Date: 2009-10-21 19:27

Message:
I understand. Unluckily I do not have Fuji's HS-v3, but maybe I can get in
contact with some persons who are currently using it; so I will try to
retrieve as much as information as possible from them. I will keep you
informed. Thank you for your help!

----------------------------------------------------------------------

Comment By: Marcus Meissner (marcusmeissner)
Date: 2009-10-21 18:51

Message:
i do not see known opcode or nikon like opcodes in the trace.

there are 3 unknown opcodes:
  0x900c
  0x900d
  0x901d


As the HS-V3 software seems capable, it probably is possible somehow.
Without knowledge how this is difficult.

USB traces or documentation of how-to-capture would be helpful.

until then we can not do much more :/

----------------------------------------------------------------------

Comment By: albatros_la81 (albatros_la81)
Date: 2009-10-21 06:07

Message:
Here it is!

----------------------------------------------------------------------

Comment By: Marcus Meissner (marcusmeissner)
Date: 2009-10-20 06:34

Message:
hmm,

can  you run:

gphoto2 --summary --debug > logfile 2>&1  

and attach it here please?



----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=358874&aid=2881948&group_id=8874

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
gphoto-features mailing list
gphoto-features@...
https://lists.sourceforge.net/lists/listinfo/gphoto-features