gphoto2 icon indicating copy to clipboard operation
gphoto2 copied to clipboard

Fuji X-T2 Camera Command Line Control

Open sdw427 opened this issue 2 years ago • 7 comments

Hello all. I was recommended to submit a new issue here in response to issue 264 I had raised on the Pibooth project here.

I am trying to use Pibooth to control my Fujifilm X-T2 using gphoto2. Within Pibooth, I am only able to capture 1 image before the system crashes. @anxuae has been assisting with the below suggestions.

In a shell I ran various combinations of the two below commands to try and find the issue.

    gphoto2 --capture-image

and

    gphoto2 --capture-preview 

I was able to run as many gphoto2 --capture-image times as I wanted without crashing doing this:

    #!/bin/bash
    
    gphoto2 --capture-image
    gphoto2 --capture-image
    gphoto2 --capture-image
    gphoto2 --capture-image
    gphoto2 --capture-image
    gphoto2 --capture-image

As soon as I introduce capture preview, things fail.

    #!/bin/bash
    
    gphoto2 --capture-image
    gphoto2 --capture-preview
    gphoto2 --capture-image
    gphoto2 --capture-preview

Here is the error it spits out: Capturepreview.error.txt Here is the result of running gphoto2 --debug: immediately after the above error. gphoto.debug.txt

Digging into it a bit more, I can run gphoto2 --capture-preview indefinitely without failing however as soon as I run gphoto2 --capture-image, I cannot run gphoto2 --capture-preview again without an error message. The camera indefinitely flashes the status LED (reg/green..) . Unplugging and resetting the camera fixes this.

I do not see an option anywhere to select where to store an image on my camera (SDRAM vs card etc)

Additional camera info / settings

  • Raspberry Pi 4
  • Camera connected to Pi with a USB 3 cable (2x USBA connectors into the PI, 1x USB micro-B into camera)
  • ghptoto2 version - 2.5.27
  • libgphoto2 version - 2.5.22
  • libgphoto2_port - 0.12.0
  • USB Tether Mode - AUTO
  • Manual focus
  • Auto ISO (camera minimum is 200)
  • Auto shutter speed

Thanks again, any help would be fantastic.

Thanks.

sdw427 avatar Jul 29 '21 20:07 sdw427

libgphoto2 version - 2.5.22

it should be 2.5.27 ... libgphoto2 contains the ptp driver with the fuji support and has seem quiet some improvements since 2.5.22.

msmeissn avatar Aug 06 '21 15:08 msmeissn

@msmeissn Thanks for your response. I installed everything using this guide - https://pibooth.readthedocs.io/en/latest/sources/install.html#install

When installing using ./gphoto2-updater.sh I selected the latest stable version which was given as 2.5.27. However when I run gphoto2 --version I still see the libgphoto version as 2.5.22

How should I update libgphotot to the latest version?

edit - running this: sudo apt-get remove gphoto2 libgphoto2-6 libgphoto2-dev libgphoto2-l10n libgphoto2-port12 causes gphoto2 --version to give the right 2.5.27 result. However my issues still persist. Thanks

sdw427 avatar Aug 07 '21 21:08 sdw427

I'm seeing the same issue on my Fuji XT-2 - I'm using : gphoto2 2.5.28 libgphoto2 2.5.29 libgphoto2_port 0.12.0

USB Tether Mode - AUTO

Additionally, I am able to retrieve the image from the buffer or card with both preview and regular capture commands. So it seems like the camera gets stuck in I/O mode indefinitely after gphoto2 --capture-image.

One other thing of note - I am not able to set exposure properties etc via --set-config unless I have executed at least one --image-capture (i.e. I have to be in the "indefinite I/O mode"). Executing --capture-preview does not have the same effect.

Any suggestions appreciated!

mypuppynow avatar Apr 11 '22 20:04 mypuppynow

I'm having similar problem with my XT-4. All of the images are writing to /store_10000001/. This is the memory buffer. That seems to cause the red/green flashing light on the back. If I delete the image from the buffer after capture then all seems to be well.

The main problem is that it doesn't seem like gphoto2 can see or manage the memory card storage. It only sees the 2 buffers.

dlin128 avatar Sep 22 '22 00:09 dlin128

I currently have no Fuji XT at home, will need to rent it again for testing.

I think it might only support capture to SDRAM (the virtual 10000001 device) and so require immediate download. but --capture-image should be doing that.

its likely either a camera limitation or we have not yet found out how to capture to sd card.

msmeissn avatar Oct 01 '22 10:10 msmeissn

its likely either a camera limitation or we have not yet found out how to capture to sd card.

Sorry to bump an old thread, but I spent the last couple hours seeing how to remote capture to SD card on my X-S20 (using the same settings as if it's an X-S10). I found via sniffing the USB packets using the XAcquire app while adjusting some settings that the following was being set:

/main/other/d20c
Label: MediaRecord
Readonly: 0
Type: MENU
Current: 4
Choice: 0 1
Choice: 1 2
Choice: 2 3
Choice: 3 4
END

...and sure enough (at least on my X-S20) this controls what, if anything, is sent to the SD card. MediaRecord suddenly makes sense.

1 = JPG + RAW
2 = RAW only
3 = JPG only
4 = No images captured on SD card

of note is that the camera still expects handling of the imagery in SDRAM (either download or delete), and in every case both the RAW and JPG images were in SDRAM. My camera was in RAW + JPG mode, so that's probably it.

Hope this helps someone. I'm just passing by, but if I can help at all with testing on the X-S20 or can provide any info, feel free to ping me.

jdalrym2 avatar Mar 17 '24 21:03 jdalrym2

@jdalrym2 thank you for your comment - that was extremely helpful.

I have an X-T2 and had the same issue with pibooth. It's not instability per se, the problem seems to be that the camera will not capture a preview when there's an image in the SDRAM. Pibooth's 4 photo mode does a loop of preview, taking a capture, and then just storing the file paths from gphoto. Once it's done taking the 4 photos, it then loops over the paths doing file_get. This breaks on the X-T2 because it's not downloading and deleting the file from the SDRAM first before getting the preview.

I patched the issue in pibooth by making it download the capture from SDRAM and delete it before each photo in the series, rather than waiting until the end. I don't think this is really a gphoto2 bug and can probably be closed - rather it's a mismatch between a limitation of the X-T2 and how Pibooth expects cameras to work.

blutack avatar Apr 28 '24 16:04 blutack