|
»
»
»
[gphoto-features] [ gphoto-Feature Requests-2881948 ] Fuji S5Pro remote control
|
View:
New views
1 Messages
—
Rating Filter:
Alert me
|
 |
[gphoto-features] [ gphoto-Feature Requests-2881948 ] Fuji S5Pro remote control
by SourceForge.net
::
Rate this Message:
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-29 10:52 Message: thanks! i will add the values to the config tree, might take a bit ---------------------------------------------------------------------- Comment By: albatros_la81 (albatros_la81) Date: 2009-10-28 22:52 Message: I have uploaded the device properties summary since the --summary option now works good (last time it was segfaulting...). Then there is the all_config_master.txt which reports the main features labels (for all the 0x500 address range and something more). Please feel free to add them to the code, since my #C skills are very poor, then I will eventually add the rest of the options to the next snapshot if I will manage to do that ;-) There is something more to be inquired about the aperture values and the shutter speed since it depends on the lens mounted. I see that it simply refers to a range of numbers, the lower one corresponding to the lower f/number but not numerically equal to it, and so on as far as the larger aperture; it is almost the same for the shutter speed. Looking at the config.c code, I guess there is something similar for Canon and Nikon devices. ---------------------------------------------------------------------- Comment By: Marcus Meissner (marcusmeissner) Date: 2009-10-28 21:22 Message: the other/ menu contains all the regular menus again (they are the 0x500 values). we would add them to camlibs/ptp2/config.c I have now added the FUJI detection to libgphoto2 so you can use PTP_VENDOR_FUJI codes in config.c either you can try or I can do it (or provide some samples code). refreshed libgphoto2 with this FUJI detection: http://www.lst.de/~mm/libgphoto2-2.4.7.2.tar.bz2 ---------------------------------------------------------------------- Comment By: albatros_la81 (albatros_la81) Date: 2009-10-28 20:51 Message: I have individuated a lot of features and re-labeled them. However, I see that there are a lot of duplicate queries (i.e. there are two configs about white balance with different "ptp addresses" but identical number of setting strings [as it should be, since they refer to the same setting]). In your experience, what does that mean? I guess that the "duplicate blocks" refer respectively to the in-camera menu and to the relative camera-hardware switch. Am I wrong? ---------------------------------------------------------------------- Comment By: albatros_la81 (albatros_la81) Date: 2009-10-26 19:34 Message: Yes, in fact I am currently working on that! I guess a lot of handlers refer to some input coming from the lens while some others are options stored into the camera menu. I will send you a patch or the updated "allconfig" file as soon as I finish the job ;-) ---------------------------------------------------------------------- Comment By: Marcus Meissner (marcusmeissner) Date: 2009-10-26 08:53 Message: there is some stuff to do :) if you look through the allconfig list you see a lot of "Unknown value 8001". these are settings we do not know the names of. so you can do for those ... Check the settings in the Camera against this list, change the settings on the camera and run e.g.: gphoto2 --get-config whitebalance to find which "unbknown value ...." matches which specific device name whitebalance , focusmode, focusmetermode, exposuremetermode, flashmode are the ones. This would help greatly and should not be hard to do as these are basic settings lots of people might use. second guess round: then, if you look through the "other" category, there are a lots of 0xdXXX values where we do not have names for. (The 0x5XXX are already listed by name) finding out the names / meanings of those 0xDXXX configuration entries and their values would help too. ---------------------------------------------------------------------- Comment By: albatros_la81 (albatros_la81) Date: 2009-10-23 23:13 Message: Let me know if you need something else, I will check this thread next days. It has been a really productive day, so thank you very much: you have been very kind and helpful! ---------------------------------------------------------------------- Comment By: albatros_la81 (albatros_la81) Date: 2009-10-23 22:21 Message: Outputs attached... and a quick test con setting the ISO values worked fine. ---------------------------------------------------------------------- Comment By: Marcus Meissner (marcusmeissner) Date: 2009-10-23 22:11 Message: not really useful with debugging information. what also might work already is: gphoto2 --list-config gphoto2 --get-config <entry from abovelist> gphoto2 --set-config entryname=newvalue Can you attach also: gphoto2 --summary --debug > summary.log 2>&1 gphoto2 --list-config | while read x do echo $x gphoto2 --get-config $x done > allconfig.txt ---------------------------------------------------------------------- Comment By: albatros_la81 (albatros_la81) Date: 2009-10-23 22:09 Message: (gdb) run --summary Starting program: /usr/bin/gphoto2 --summary [...] (no debugging symbols found)'/usr/lib/libgphoto2/... | \ 0.0% [...] (no debugging symbols found)'/usr/lib/libgphoto2/... |---------------------------------- | 96.6% 6s [...] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb7b716c0 (LWP 24432)] 0xb7afe1b4 in ?? () from /usr/lib/libgphoto2/2.4.7.2/ptp2.so (gdb) bt #0 0xb7afe1b4 in ?? () from /usr/lib/libgphoto2/2.4.7.2/ptp2.so #1 0xbfebf3a3 in ?? () #2 0x00007510 in ?? () #3 0xb7b24f8a in ?? () from /usr/lib/libgphoto2/2.4.7.2/ptp2.so #4 0x00000000 in ?? () And, last but not least... bash-3.1# gphoto2 --capture-image New file is in location /store_10000001/0DSC0001.raf on the camera It works! NICE! :-) ---------------------------------------------------------------------- Comment By: Marcus Meissner (marcusmeissner) Date: 2009-10-23 22:04 Message: so, for starters: gphoto2 --capture-image should take a picture now :) as for the segfault, can you run it in gdb? gdb gphoto2 ... run --summary ... crash ... bt ---------------------------------------------------------------------- Comment By: albatros_la81 (albatros_la81) Date: 2009-10-23 22:02 Message: gphoto2 --summary gives me a segmentation fault. However, the --autodetect gives me out this: Fuji S5 Pro usb: Fuji S5 Pro usb:002,01<N> in all the three modes, so yes: it detects the camera successfully! ---------------------------------------------------------------------- Comment By: Marcus Meissner (marcusmeissner) Date: 2009-10-23 21:52 Message: as there is no real change, gphoto2 --auto-detect should work even now in all modes. just gphoto2 --summary output for instance should/will change ---------------------------------------------------------------------- Comment By: albatros_la81 (albatros_la81) Date: 2009-10-23 21:47 Message: Ok, I go for it! ---------------------------------------------------------------------- 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 |
| Free embeddable forum powered by Nabble | Forum Help |
