OSC image stacked resulting mono
Stacking program, astrometric (plate) solver, fits file viewer
Brought to you by:
han59
Menu
▾
▴
Hi, It's my first few try using ASTAP stacking for the mosaic panels. The results look good except they are all mono instead of OSC images I shoot. How and why did this happen? I saw from the stacking live log a step calling "invert to mono" during the process. Why did it do invert to mono? I did check the "Force processing as OSC images" option. Is that the reason the result became mono? Please help resolving this issue before stitching the mosaic. Thanks
Update: The fourth panel was stacked with "Force processing as OSC images" unchecked. Still yielded a mono master fit.
Last edit: Koa Wu 2025-11-02
Hi Koa Wu,
The log mentions converting for mono only for detecting stars for alignment. The images stay in colour.
The image stitching routine should create a colour mosaic. But the different tiles should be in colour before you start using the image stitching routine.
Can you share two of your tiles, so I can check the ASTAP image stitching process?
Han
Hi Han,
Thanks for replying. I haven't run mosaic stitch yet. Right now, I only have 4 panel (you call tile?) images. None of them is processed (I thought I should run mosaic stitch with linear fits, right?) However, I did run statistical stretch on one of them (with SAS). It still looked as a mono. I checked their sizes and surprisingly three of them are 100.9MB, but one of them is 33.6MB only. With such big files, how do I share them? Can I do scale down then attach? Sorry, first time posting here. Don't know how to do it. Please advise.
Panels or tiles are the same. So the images to stitch together.
The tiles/panels should be in colour and unstretched so linear fits files. So the files which come out of the stacking or calibrating. Stitching takes a lot of processing time and is not very fast.
Easiest way to share them by dropping them as one zip file at https://ufile.io/ and give me the link. This should be fine for 5gbyte at least. As one zip is easier for me because I have to ignore the spam from that webpage.
I zipped all 4 tiles and clicked the ufile.io link to upload. But after saving the zip, the website didn't give me a link or anything. The website window is empty! I have no idea what's going on?
You should get something like below. Can you retry?
This is very confusing! Every time I go to ufile.io, a pop-up window asking me to save a .ts file to... I think it's download, not upload. There is no upload box any where, thw website page is empty. I didn't get anything like you attached!
Ok, I changed the browser and it worked. Here is the link: [https://ufile.io/fknmvx4j] Let me know if you get "Myfile.zip"
Something went wrong with your file. I is only 187.1 KB and not a zip file. Can you retry?
Don't know what went wrong. I am uploading archive.zip (264.1 MB) right now (slow). Will send the link.
Ok, done. Here's the link: Archive.zip
Let me know when you get it. Thanks
Last edit: Koa Wu 2025-11-02
I have the four files. The FITS files are in colour format but have no colour except some vague hints. The header says the following:
COMMENT D=master_dark_1x15s_at_23C_2025-10-27.fit
COMMENT F=master_flat_corrected_with_flat_darks_Nebula_1xF_1xFD_0.00992213se
HISTORY 1 Stacking method SIGMA CLIP AVERAGE
HISTORY 2 ** Processed as gray scale images. **
SET-TEMP= 18 / Average set temperature used for luminance.
LUM_EXP = 15 / Average luminance exposure time.
LUM_CNT = 182 / Luminance images combined.
LUM_DARK= 1 / Darks used for luminance.
LUM_FLAT= 1 / Flats used for luminance.
So they are stacked in gray level only. That is the problem. The individual image have to be de-bayered to colour for each frame during stacking. Normally that goes automatically if there is a Bayer pattern in the image header. I can see there is Bayer pattern defined in the header:
BAYERPAT= 'RGGB '
So this de-bayering should have gone automatically. So this is difficult to understand why it did not work.
You should restack the individual frames of of each tile/section. If the result is not colour, then force processing as OSC (DSLR) by option. See red marked option in the attached screenshot. Once you have the tiles/panels in colour then go to next step the mosaic.
Han
Hi Han,
I did stack these four tiles except P5 with "Force processing as OSC" checked. The P5 was stacked with the option unchecked for a test. The test had proven that the option needs to be checked, by the file size (33.6MB instead of 100.9MB). I have re-stacked P5 with the option checked, and it turned out the same 100.9MB as other 3 tiles. So now, how do I go next?
I wonder before stacking, how do I adjust "color level"? The only option is to check "Auto levels", which I did. Also, do I need to change "Color smooth" default settings? What settings are appropriate for my case (My raw lights and calibration frames were captured from Celestron Origin smart scope).
What will happen, if I go ahead to stitch the 4 panels?
Really appreciate your help/input.
That read like your making progress.
That should not happen. Can you share one original image so I can check why it is not done automatically?
Yes triple size is normal. The mosaic will also take a relative long time. Be patient.
Colour smooth should be on. Are the new stacks in colour? If so then you can proceed to the mosaic/image stitching.
The adjustment of color level have only to be used/set after the mosaic is created. They never effect the fits file. They only effect the display and any any saved jpeg file.
Contrary to your finding, I took a view of P3, P4, P5 fits and they all show "History 2 De-mosaic bayer pattern used RGGB" (see attached). Your finding of "HISTORY 2 ** Processed as gray scale images. ** must be from P5 header I sent you, as I unchecked the option of "Force processing as OSC" for a test. So now would you confirm all tiles are color? (they still look like mono)
In your new message, what is the "original image" you requested? Is it a raw light frame from any panel? Thanks
No the screenshot indicates it is just mono/grayscale. I assume the images are binned and the red, green, green and blue sensitive pixels are binned together. This will destroy all colour information. What is the camera max resolution (width x height in pixels)? You should only take images at full camera resolution to able to convert them later to colour.
It is here bed time. Tomorrow I'm available again.
Sony 678c camera: pixel size=2.0 micro meter*2,
8.4 MP = 3856x2180
sensor size=7.7mm x 4.3mm
How the images are binned and the RGB pixels are binned together? Can I un-bin the images?
AW, I went ahead stitching the tiles. It came out fine except still mono!
Here is an original light frame file.
When I debayer your raw light to colour (keeping the auto level off) then the image is reddish. See attached. The star colours are all white which is difficult to understand.
Then I tried to force a different debayer algorithm. In the header is specified RGGB but when I force it to use GBRG to image looks normal.
So specified was
RG
GB
but it should be
GB
RG
So the image is vertical mirrored somewhere in the process. No problem, use pattern GBRG (and auto levels on) and then all colours should be good. See attached2 GBRG
Han
Pardon me for being a new ASTAP user that don't know much about any thing to use it. So how do you debayer law lights with ASTAP? I guess first you open the file in ASTAP, and then ??? But I'll re-stack all 4 tiles with GBRG tomorrow and see what comes up (we are close to bed time now here in California. Where are you?) There is one thing I haven't notified you that my master flat looks pink, and when I stacked the tiles, the log indicates error: flat has too many color difference; will apply compensation... I wonder if the flat color had messed up stacking (calibration) process? I had hard time to capture flat frames (after-sunset sky). Thanks
To de-bayer, load an raw image in the viewer and use the one of the menus as attached.
That the master flat looks pink after debayer that could happen. The sun-set sky is very blue.
The warning "has too many color difference" is just a warning that the light source is not very white. Normally you will not notice the difference. Just assure that the flat is not saturated by measuring the pixels values in the viewer. You could use a t-shirt to cover the telescope to allow a brighter sky for flat taking. More ideal is electro-luminance panel but sunset sky will do.
Last edit: han.k 2025-11-04
I'm in the Netherlands, Europe.
Hi Han,
As you instructed, I forced bayerpat to GBRG and re-stacked. It all came out colored! Definitely, the smart scope had messed up wildly. I checked the json file of the panel sessions, it indicates "StackedInfo: bayer=gbrg". So now the stacked tiles are colored with GBRG. I ran mosaic stitching with them, but it came out misaligned! See attached: 1. stitching log, 2. stitchedMaster RGGB, 3. stitchedMaster GBRG. The only difference between stitchedRGGB and stitched GBRG is: I left calibration files (dark, flat, bias) in their tabs when running GBRG stitching. Is that the cause for misalignment? Please advise. Thanks
Ok, I reviewed my stitching process and made some changes: 1. remove all calibration files from their tabs, 2. plate solved each tile before stitching. Ran mosaic stitching again, and it came out colored and aligned. Still suffered losing lot of border space though, especially the bottom area. Any idea/advice? Is it due to Telescopius' mosaic plan?
Thank you for your help, so far.