×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Standard capture and transfer format properties?

Currently INDI camera drivers transfer their images in FITS format. The only exception is the DSLR driver which can also send images in their native captured format.

I was thinking of expanding this to a standard property so other driver can make use of it. For this, I believe we need two standard properties.

1. CCD_CAPTURE_FORMAT
2. CCD_TRANSFER_FORMAT

For the CCD_CAPTURE_FORMAT, it selects what file format the image should be captured in natively from the device. For DSLR cameras, this can be JPG/CR2/...etc (whatever format natively supported by the camera). For CCD/CMos cameras, this can include RAW-8/RAW-16/RGB/etc..

Now the CCD_TRANSFER_FORMAT simply designates the format which INDI clients receive the captured blob as. These can be:

1. RAW (as is, native)
2. FITS (default)
3. XISF (future implementation perhaps)
4. ..etc

This is already realized in the DSLR driver. That is, you can captured a JPEG image and transfer it as FITS or as RAW, or capture RAW CR2 and transfer it as FITS..etc. So what is suggested here is to standardize this further and make it available for other driver to implement in a standard consistent way.
The following user(s) said Thank You: Alfred
4 years 5 months ago #44677

Please Log in or Create an account to join the conversation.

  • Posts: 1029
  • Thank you received: 301
My comments:
- From what I understand from your generalization, this pushes each capture driver to offer conversion services between CCD_CAPTURE_FORMAT and CCD_TRANSFER_FORMAT? Right now, most offer a single one (exception is the DSLR driver, any other examples).
- How many drivers would be ready to provide such services? Will they be able to use standard library functions to run those conversions?
- CCD_TRANSFER_FORMAT might be overlapping the current compressed/uncompressed flag?
- XISF is obviously a great addition, but the list of available features is probably not that much relevant for a "simple" capture device. However, XISF offers an interesting integrity and authorship features as soon as capture frames leave the observatory system.
My worry is that these two properties might somehow break driver compatibility at some point. Other than that, they're neat.
-Eric
4 years 5 months ago #44789

Please Log in or Create an account to join the conversation.

  • Posts: 447
  • Thank you received: 30
This item was confusing for many users.(in Japan)

The wonderful feature of the INDI driver is that it can be remotely controlled by the server and the client.

Please consider it as a proposal.

・ Capture format items
Used for setting the native items of DSLR and CCD cameras. In the driver, items that each camera supports are listed.

・ Transfer items
It becomes the item of transfer method between server and client.
This item is not necessary.
(It would be nice if the user was transferred quickly.)

This completes the driver settings.

When saving an image to the client, it is saved in the format specified in the capture format.

Add conversion items when saving to Ekos image viewer.
(I would be happy if batch processing such as Raw, Fits, Jpeg, Tiff, BMP etc. could be done.)

In this way, once the user sets the camera-native capture items, the remote client can operate in the same format.

If image conversion items are enhanced with an image viewer such as Ekos, users can convert image files arbitrarily.

At present, conversion items are mixed in the capture and transfer formats. (Fits etc.)
Some people misunderstand transfer raw as camera raw file.

I think that it is less misunderstood if the items are kept as simple as possible to match the user's flow.
(Although it is in Japanese, it is also featured on the blog.)
tstudioastronomy.blog.fc2.com/blog-entry-175.html
4 years 5 months ago #44801

Please Log in or Create an account to join the conversation.

  • Posts: 447
  • Thank you received: 30
I would be happy if there was a preview image setting item as an additional option.

Users using StellarMate with an astronomical camera are not happy with the speed at which images are transferred.

The preview and solver do not require large image files, so if you use a lightweight image and increase the transfer speed, you will be comfortable.
4 years 5 months ago #44802

Please Log in or Create an account to join the conversation.

Time to create page: 0.225 seconds