-1- The histogram can support beyond 255 (8 bits).
-2- The ability to load some raw files () is also present in the FITS viewer but at the moment some are loaded only up to 255 bits. I am looking into this but am probably not able to fix it.
See:
const QStringList RAWFormats = { "cr2", "cr3", "crw", "nef", "raf", "dng", "arw", "orf" };Read More...
=1= Unfortunately, the feature 'Hide saturation Spike' is now gone in the current version 3.6.2. @jasem is it coming back?
=3= According to the manual, the viewer is capable of displaying float-based imagerey, that could include negative numbers.
"""
Support for 8, 16, 32, IEEE-32, and IEEE-64 bits formats.
"""
Read More...
No problemo, I don't want to mess with the CMYG debayering then. Thanks for the insight!
Read More...
Hi guys,
It's great to see my old device supported: Color Meade Deep Sky Imager I. I'm trying to get color info out of this 18 year-old device but only getting red. Reading here on the forum that there was an effort 6 years ago to support this device. I am just wondering if the debayering works?
Cheers,Jurgen
KStars reports:
2022-01-01T15:01:53: [INFO] Found a DSI Color!
lsusb reports:
Bus 002 Device 008: ID 156c:0101 156c EZ-USB FX2
Pixinsight reports an image as:
Reading FITS image: 16-bit integers, 1 channel(s), 508x488 pixels: doneHi guys,
Happy New Year!
It's great to see my old device supported: Color Meade Deep Sky Imager I. I'm trying to get color info out of this 18 year old device but only getting red. Reading here on the forum that there was an effort 6 years ago to support this device. I am just wondering if the debayering works?Cheers,Jurgen
KStars reports:
2022-01-01T15:01:53: [INFO] Found a DSI Color!
lsusb reports:
Bus 002 Device 008: ID 156c:0101 156c EZ-USB FX2
Pixinsight reports an image as:
Reading FITS image: 16-bit integers, 1 channel(s), 508x488 pixels: done
Read More...
I see that the below command line works fine:
./KStars.app/Contents/MacOS/kstars test.fit
It opens up KStar with the image shown.
Releasing a separate version of KStars just to get this to work seems silly 
On macOS the opening of files is related to the UTI of the file according to: en.wikipedia.org/wiki/Uniform_Type_Identifier#Looking_up_a_UTI
Below you can see that a file saved by KStars differs in the UTI from a file that is saved by another program: Siril. Note that the file name extensions also differ by the extra s in .fits in KStars vs .fit in Siril. Both are "FITS file" though.
[jd@Aok:Desktop]> mdls -name kMDItemContentType -name kMDItemContentTypeTree -name kMDItemKind test_saved_by_siril.fit
kMDItemContentType = "gov.nasa.gsfc.fits"
kMDItemContentTypeTree = (
"gov.nasa.gsfc.fits",
"public.image",
"public.data",
"public.item",
"public.content"
)
kMDItemKind = "FITS file"
[jd@Aok:Desktop]> mdls -name kMDItemContentType -name kMDItemContentTypeTree -name kMDItemKind test_saved_by_kstars.fits
kMDItemContentType = "dyn.ah62d4rv4ge80q4pysq"
kMDItemContentTypeTree = (
"public.item",
"dyn.ah62d4rv4ge80q4pysq",
"public.data"
)
kMDItemKind = "FITS file"
Read More...
Hi guys,
Many good affordable common Sony camera's (like my A7S) have a problem where the data gets filtered in-camera, eating up many tiny wanna-be stars. This only occurs in BULB mode. In manual mode this problem is absent. It's well-documented and in fact in the last four years about 10,000 signed this petition for Sony to address it (www.change.org/p/sony-remove-the-star-ea...-i-ii-and-a9-cameras) but it didn't happen.
I assume Sony will never fix it. It would be real nice if KStars could use the manual (M) mode instead of the BULB mode. Currently it is advised against it here: indilib.org/ccds/gphoto.html (section Exposure Modes). Indeed when I test with M mode and Ekos it behaves badly. Could somebody fix this? I would love to file the bug report, help test and debug. Unfortunately I don't develop in C myself.
I have tested with another program called AstroDSLR which shares some code with KStars. AstroDSLR is capable to use the M mode so I'm hoping KStars will do too.
Cheers,
Jurgen
I attach two pictures; without and with star-eating BULB modus. They open up nicely with e.g. PhotoShop. Can you tell them apart? I'll post the answer in a bit.
Read More...
I guess this would be a nice thread for posting on the "wish list" in this forum and as a feature request of the github issue tracker. Sorry for cross posting.
Read More...
Hi guys,
Many good affordable common Sony camera's (like my A7S) have a problem where the data gets filtered in-camera, eating up many tiny wanna-be stars. This only occurs in BULB mode. In manual mode this problem is absent. It's well-documented and in fact in the last four years about 10,000 signed this petition for Sony to address it (www.change.org/p/sony-remove-the-star-ea...-i-ii-and-a9-cameras) but it didn't happen.
I assume Sony will never fix it. It would be real nice if KStars could use the manual (M) mode instead of the BULB mode. Currently it is advised against it here: indilib.org/ccds/gphoto.html (section Exposure Modes). Indeed when I test with M mode and Ekos it behaves badly. Could somebody fix this? I would love to file the bug report, help test and debug. Unfortunately I don't develop in C myself.
I have tested with another program called AstroDSLR which shares some code with KStars. AstroDSLR is capable to use the M mode so I'm hoping KStars will do too.
Cheers,
Jurgen
Read More...
On the bitness: you correctly selected "Format: FITS" which currently gives 16 bit / channel .fit files from my Sony A7S mark i. I presume yours will be the same.
Go ahead and set "Bits per pixel" to 16 as well. This setting syncs with the Format option above. I have noted that when I set the Format to 'raw' the setting will default to 8 bits. This is then causing problems with Ekos truncating the 12-bit data to just 8 bit and the view can show clipped data that in truth is not clipped. Not all is lost though because the saved .arw file still contains the 12-bit data and is nice and small because losslessly compressed. It's just something to consider when estimating your best exposure time and such.
Bye now, J.
Read More...