Hi everyone,
Just want to share my experience using an x-trans-sensor-based Fujifilm camera with ekos. After being on the edge of throwing everything away, I succeeded in finding out the cause of some of the problems that others have also reported in previous threads (for instance Spencer in  this post by David). In particular re the slow "transfer" that several have experienced when trying to use the raw format.

The problem is kstars FITS image viewer, not the driver (nor gphotolib). In the raspberry pi, the viewer takes over a minute to deal with the x-trans color pattern in the RAF file. The behavior reported in the previous posts has NOTHING to do with storing the files locally or remotely. That is rather an apparent consequence of what the capture module in ekos does when storing images locally. I'll explain the cause of the confusion.

But first, to give some context, I'm using kstars 3.5.4, with the latest (1.9.3 ?) Indi library, on a raspberry pi 4 with 4 GB of ram. My camera is a Fujifilm x-pro2, 24 MP x-trans III sensor. All software runs on the raspberry. I either connect a monitor+keyboard+mouse to it, or connect remotely to it using VNC. The behavior I'll describe does not depend on how I access the pi.

As described in other posts, the camera has to be configured for "USB tether shooting auto", exposure set to "B", and, in my case, shutter mode set to "Mechanical + Electronic" (the x-pro2 cannot do longer than 1 second exposures in electronic shutter, unfortunately). The camera must be ON before plugging the cable that connects it to the raspberry. The driver can then connect properly. Once connected, no physical dial or button on the camera can be used (no response from the camera), and trying to use them seems to break the communication between the camera and the raspberry. 

I was using the Indi Fuji driver initially, but now I'm using the generic gphoto CCD driver; they behave the same. In the driver control panel, the sensor pixel count and size are set as per technical specs found on the web. The only other relevant setting is "Force bulb mode": OFF. As mentioned by others, the images are never stored on the camera SD card (regardless of the "SD Image" setting selected, i.e. SAVE or DELETE). This might be by Fujifilm design (seems to depend on camera model).

So, here is what I've learnt:

On the driver control panel, setting the parameter "Upload" to CLIENT sends the captured image to ekos to deal with it. Conversely, when setting it to LOCAL, the driver stores the image in the indicated folder. When set to CLIENT, ekos calls the FITS viewer to display the received image. For reasons unknown to me, the time it takes the FITS viewer to display the image is included in the image download time shown to the user. If the driver uploads the image in FITS or JPEG format, the viewer displays it fairly quickly. However, if the image is uploaded in RAF format, it takes the viewer running on the raspberry more than a minute to display it. This is despite the image being saved on the raspberry SD card within a second of finishing the exposure. Surprisingly, the whole of kstars hangs while the FITS viewer is processing the file (!).
 
I discovered this behavior looking at the contents of the folder where images were stored, while commanding exposures directly from the Main Control tab of the driver control panel. The image file is saved (and is readable) almost immediately after finishing the exposure, regardless of setting "Upload" to CLIENT or LOCAL.

The good news is: shooting RAF from ekos running on the raspberry pi can be as fast as shooting JPEG or FITS, if images are only stored in and not displayed by the raspberry. 

Now, when commanding exposures from ekos capture module, the behavior depends on the ekos "Upload" setting, which is not the same as the driver "Upload" setting. In ekos capture module, LOCAL means "ekos deals with the image", and REMOTELY means "ekos only saves it". So, to avoid ekos from displaying the images, ekos should be set to upload REMOTELY (which doesn't mean a local folder can't be specified anyway). (Note: I tried unchecking the "display DSLR images" box in kstars settings / ekos tab, but it didn't work, beats me...).

However - and this was for me the source of confusion - the behavior of ekos also changes if the image is acquired as a "preview" or in a sequence: Even if the driver is set to upload LOCAL and ekos is set to upload REMOTELY, when taking a "preview" exposure, ekos changes the driver setting to CLIENT to be able to display the image and then resets it to LOCAL. Conversely, when exposing a sequence, the Upload setting in the driver remains unchanged, and the whole sequence is acquired without delays (good!).

I think this explains why Dave experienced no delay when shooting raw as opposed to others (for instance Spencer in the referred thread ): When using the raspberry as an Indi server, there is no instance of ekos running on the raspberry and trying to display the uploaded images, so: no delay. AS described in the other thread, Dave was using ekos on a laptop, and selected Upload REMOTELY (so images remained on the pi). He and others attributed the delay when selecting LOCAL on the laptop to the ethernet transfer speed, but it might as well mean that also on the laptop the FITS viewer crawls when "debayering" the RAF files. 

Moving forward, even if these observations showed how to shoot raw from the raspberry without delay, the current conditions to achieve that are far from ideal. 

First, not being able to take previews is bad. Of course, one can select to upload the images as FITS, or shoot as JPEG initially and then switch to raw for the sequence... But then there is no way to check how the sequence is going (no HFR measurement, etc.).

Second, the camera being completely unresponsive after connecting it to the raspberry is also annoying. Combined with the slow display of RAF files, this means that either all framing and focus is done before connecting the camera, or afterwards but using jpeg/FITS initially and then switching to raw (this makes me think a shutter release might be a better option...but then there is no chance to do platesolving... argh). The camera body also seems to heat-up a lot during the tethered session (but I'll have to test this further).

Both these issues would be resolved if the FITS viewer would have a "quick and dirty" option for RAF debayering that works fast on the raspberry even if not producing the best output quality (could even treat it as a grayscale image, not important for practical use within ekos...). Please, please, please? 


Well, long post. I hope it helps other Fuji users out there. I'll try working with what's available for now and I'll report later.

I might post also about the FITS viewer stopping kstars in general. I'm surprised by that behavior, I wonder if it is not also the source of other problems (is that affecting guiding too? even when a big image from an astro-camera is being "downloaded"?).

Best regards and clear skies,
Ricardo
 

The behavior is the same with my Nikon D5500 DSLR.

Hi Ricardo,
Thanks for your excellent article.
It saved nearly my butt as I got almost frustrated if not capitulating with my setup.
The „download times“ - which were also misinterprated by me - of 70s were inacceptable.
But your solution made a lot of the Fuji-burdon acceptable.

Do you have any news regarding the FITS viewer issues?

Regards,
Greg