@Joaquin: Thank you for the good explanation. You hit the nail on the head.
The
indi_pylibcamera issue #65
is closed. Prof Huster got raw Bayer images. The tool he used interpreted the data as monochrome. That was also the reason for the checkerboard pattern in the lighter regions of his image.
The header of the FITS image has an attribute "BAYERPAT" which tells the color order in the Bayer pattern. A monochrome FITS image does not has this attribute. As far as I know this makes the difference between monochrome and raw Bayer images in FITS format.
KStars has a setting to enable debayering before showing FITS images on the screen. That allows to see colored images in the preview window. It does not affect the stored image data. Likely CCDCiel has a similar feature.
For my opinion using raw Bayer images is preferred over RGB images. All color cameras I know use Bayer filter. The RBG images are generated in an image signal processor which does the debayering. But this image signal processor usually calculates with integer numbers which leads to loss of information. This is not critical for good exposed images. But in astrophotography the interesting parts of the images are extremely underexposes: the faint nebulas between bright stars are often hidden by the camera noise. Only a special processing makes these details visible:
Hello Prof Huster,
please open an issue in github.com/scriptorron/indi_pylibcamera/issues
It would help me a lot when you add one of your FITS images to the issue.
Best Regards,
Ronald
Read More...
Hello Mat,
Sorry for the late answer. You give me hope and I will do more experiments with my Star Discovery mount.
Last week I could prove that the issue is not caused by my guiding camera, PHD2 installation or mechanical setup. I used my optics with an equatorial mount and could successfully guide. Before that I was not fully sure if the camera is good enough for guiding (a Raspberry Pi HQ camera with my self made driver github.com/scriptorron/indi_pylibcamera). Attached is a picture of my equipment after a frosty observation night. The guiding scope is a Svbony with 190mm focal length, the main OTA is a Newtonian with 750mm focal length. Both have their own Pi with HQ camera. The Pi on the guiding scope operates the guiding camera, runs PHD2 and sends the guiding commands over WIFI to the Pi on the main OTA. The Pi on the main OTA runs KStars, operates the main camera and drives the mount. That setup sounds strange but it was the only which avoids sending camera pictures from one Pi to the other (that would be too slow). Controlled is everything using remote desktop (xrdp) from a Linux laptop in the same WIFI. I can do this from the couch and do not stay connected all the time.
As mentioned guiding works with the same optics, same cameras and same Pis on my equatorial mount but not on the StarDiscovery mount (www.astroshop.de/azimutal-mit-goto/skywa...an-wifi-goto/p,57362). The only differences on the StarDiscovery setup are:
Hello Mat,
Happy New Year!
Amazing! The diagram of the RA/DEC errors shows immediate reactions on guiding pulses. In my setup the errors continuously increase. It makes no difference if I enable or disable the guiding pulses in PHD2.
Do I understand right: you did this with
Hi Mat,
Short answer: I did not have success and I gave it up.
Long answer:
I tried different INDI driver:
@Anjo
Am I right that you mean the 'indi_pylibcamera' driver when you speak about the Python driver? If so, please open an issue in github.com/scriptorron/indi_pylibcamera and provide more details for debugging.
Thank you.
Read More...
In my post I stated that guiding worked with the indi_synscanlegacy_telescope driver. I can not reproduce this with a real camera. Likely I did something wrong during my first test. Maybe the guiding interface of the indi_simulator_ccd driver was used.
Asking the Sky-Watcher support regarding guiding interface of the SynScan App was not helpful.
Next days I will have a deeper look in the code of the indi_synscan_telescope driver.
Read More...
Simon is friends with Ronald Schreiber
I observe a very strange behavior when trying guiding (internal guider and PHD2) my SkyWatcher “Star Discovery AZ SynScan WiFi GoTo” mount. After wasting many nights I did some experiments at daytime with the CCD simulator. My setup for this test was:
Hi Denis,
First, congratulation to your great software! Really good!
I developed the indi_pylibcamera driver. It is a new project and certainly not free of bugs. I still try to improve it. When reading this discussion I got some questions:
1. What is POLLING_PERIOD used for? I saw this in the indi_simulator_ccd driver but I could not find out what it does. When searching internet I found something related to a focuser. But most of the cameras do not have a focuser. Is POLLING_PERIOD an importent attribute for a camera?
2. In the comment above you wrote, your program expects "len" instead of "size" in oneBLOB. I have all my half knowledge from github.com/indilib/docs and from analyzing network traffic. As far as I know github.com/indilib/docs/blob/master/protocol/INDI.pdf specifies "size". Is that outdated and should I change it to "len"?
Regards,
Ronald
Read More...
@SigvaldS:
I opened an issue github.com/scriptorron/indi_pylibcamera/issues/15 in my GitHub project. Can we move the discussion there? It would be boring for the other people here.
When you open the link you will find on the right side a button "Subscribe". When you press this you will get an email every time when someone (me) writes a comment for this issue.
Read More...
@SigvaldS: There is nothing behind "Raw sensor modes:"? This is strange. It means, the libcamera (and kernel driver) do not provide raw data for this camera. I can't belive that. Maybe it is too new and still not fully supported. Do you use the latest Raspberry Pi OS Bullseye and have you done "sudo update; sudo upgrade" to get the newest versions of libcamera and kernel? Can you make pictures with "libcamera-raw" (see www.raspberrypi.com/documentation/comput...e.html#libcamera-raw)?
My focus for "indi_pylibcamera" was on raw images. And I am still convinced that raw images will better perform for astro photography than processed RGB images. But I will try to extend the driver for cameras which provide processed frames only. Please give me some days.
Read More...