That is very interesting. I am using PI 1.8.7 and therefore a earlier version of the WBPP script and have never encountered this info pop up warning. Lenny, what version are you using?
You could be right that light leakage may be the problem. You should be able to spot this easily in your master dark by stretching the image.
I usually perform my darks in a more controlled environment and build up a library of master darks for all the usual exposure times that I use. I am consistent with the temperature that I use (-10) and always use the same gain and offset etc. So this makes a library of master darks pretty convenient and allows more time to concentrate on getting enough lights flats and dark flats etc. Using a cooled camera also makes this really easy.
I am not familiar with the scripts that you are using. Maybe my version of PI is a bit old .
I am always a bit cautious of scripts especially batch pre-processing as if something goes wrong it is difficult to track it down.
I think that the problem is likely related to mismatching between lights and darks (you don't mention if you are using flats as these can introduce problems too). As Wouter suggests things like offset values being different can create the problems that you are seeing.
I think that pedestals can be useful to prevent clipping but clipping often is caused by problems in calibration. I have never found using a pedestal to help much in my image processing.
You may need to give more info. Is this a new problem? e.g. related to a change in your workflow or related to a new piece of equipment e.g. your quad band filter. Or has the camera always been associated with these issues?
The supplied image certainly looks strange. This is a single calibrated light frame, yes? Let us know how you process your darks in terms of calibration, gain, offset and exposure (are these consistent with your light exposures?). Do your uncalibrated light frames show any of these issues?
If the camera is new and this has been a problem from the start check Cloudy Nights or Stargazers Lounge as there may be other users who have encountered these problems and have solutions.
My CEM40 used to park OK so not sure why this is no longer the case. However, while the go to home position works just as well, it doesn't interfere with my imaging sessions.
Thanks for all the hard work that you do in making KStars such a great imaging platform!
Interestingly I was testing my CEM40 tonight (I set the flip to occur at 0.2 HA past the meridian). The counterweight settings were as default (e.g. normal). The flip occurred as expected once the current exposure was finished. The flip went well and then alignment solving occurred then guiding and restarting of the exposure sequence as expected.
The only issue I have is that the park command no longer seems to cause the mount to park so I use the go to home position which then seems to be interpreted in EKOS that the mount is parked. I thought that this was related to older firmware but the behaviour persists even after upgrading the mount firmware to the latest.
However using the "home position" works just as well for me.
Hope this helps.
You put the pedestal value at the calibration of lights and make sure that the box to subtract this is ticked at integration ( I think) . However I think that it is unusual to need to use pedestals.
I would check that your darks have been integrated correctly. I have found that it is better to integrate darks uncalibrated and as these contain the bias signal there is no need to use a master bias in lights calibration. So try using uncalibrated darks and no bias and see if this makes the difference. I have never found that it is necessary to use a pedestal since I have been using uncalibrated darks.
Just a suggestion.
I came across these excellent videos outlining in detail how to set up EKOS/indi and Web Manager under Linux, Ubuntu and Windows. The videos can be accessed on Chris Kovacs webpages. They are great for beginners to help with set up and take a very slow hands on approach.
There are 5 videos in all. I think that they are a great resource for anyone thinking about using KStars etc. They were released in June this year. I could not find any reference to them on the forum so thought I would post this to make users aware of the resource.
Here is a link to the first in the series
I think that you are viewing your flats in the fits viewer in a stretched and automatically debayered form. If you open up "configure KStars" and open the "fits viewer" tab. There are a number of options. It is likely that you have auto debayer ticked. Uncheck this and you should be able to view the flats in mono, just auto stretched. This will give a better idea of what they look like. Remember that the flats are never used in a debayered form so the red cast is irrelevant. Just stacked into a master in undebayered form. Your vignetting will be dealt with in the calibration of the lights with the flats (and darks).
The fits viewer just views the images but does not change them so you don't need to worry that there is a problem. You can still use the flats that you have taken. I have never examined any of my images using the autodebayer in fits viewer as I find that it is not as helpful as a mono image in determining contrast and exposure.
All my final calibrated and integrated lights have a prominent red cast but this can be dealt with in histogram transformation. As I said, a quick way of fixing this in the final image is doing an autostretch using unlinked RGB channels. This largely removes much of the redness.
You may be able to attract more help in relation to the use of APP with this camera if you were to start a new thread with the specific problem in the heading. Using the sticky does not really address your specific problem. It may be worth posting a final image pointing out the issues you are concerned about.
I just can't help much with APP and how it handles calibration etc. Happy to advise about KStars related issues though.
I use a DIY electroluminescent panel and needed to use 6 sheets of white paper to reduce the levels to allow for a exposure of 3 secs approx. Any filters that you use in taking your lights should be used in the flats. As an example I tend to use a ZWO duo narrowband filter as I am in an inner city location.
All my darks and flats and flat darks are taken with 120 gain, 30 offset and 50/50 balance which are my default values for all my light frames. I seem to recall major problems when I used darks with different offset values to the lights. This did cause a red cast that I could not process out so I keep everything standard now and have not had any issues since.
I tried to use APP a year back and could not get it to work satisfactorily and if I recall I did have issues with the flats. In the end I gave trying to get it to work as I already was using Pixinsight and had spent some time getting over the steep learning curve of this software. I just did not have the time to invest in APP.
I have never needed to examine the individual colour balance of flats as all the calibration is done before debayering and it never seemed important. The resulting images after calibration and integration of light frames always have a prominent red cast but this is easily fixed in histogram transformation. You can check this by doing an auto stretch using unlinked RGB channels.
Have you tried processing your lights without using flats and do they look OK?
Hopefully someone using APP and familiar with how it works can help.
I found the tutorial by "Bulrichi" that I have referenced in the guide a great help in understanding the camera and how calibration works. However I had to read it a few times to really understand it fully.
What software are you using to process your images? If it is Pixinsight my guide covers most of the issues.
I usually use 25,000 ADU for my flats. I use a flat panel with a number of sheets of white paper to reduce the brightness to achieve an exposure time of around 3-4 sec. I also use a flat dark series taken at the same exposure as the flats to calibrate the flat (again this is in the guide). As the flats are always taken on the same session as the lights I never change the gain or offset (120 and 30 respectively). The white balance should be left at 50 for each setting in the indi gui panel.
The longer exposure is needed as the sensor response is far from linear at very short exposures.
You say that your flats have a red cast. This is a bit confusing as flats should not have any colour as you do not debayer the image. You just do a simple integration to create the master flat but do not do any other processing. If you view the resulting masterflat after stretching it should be easy to see variations in uniformity which relate to dust and errors in the light path which your processing will calibrate out of the light frames.
All the calibration of light frames using flats and darks are done before debayering the lights. Debayering is not done on flats or darks.
Let us know if this helps and let us know what processing software you are using. I only have experience with Pixinsight but there are other here that use other processing software.
There are a lot of issues currently with the latest nightly build in regard to other drivers (see the forum). Jasem is in the process of making the appropriate changes. Be aware that you may get problems related to this issue. Watch the forum and do a further upgrade of the nightly version once Jasem has uploaded the changes.
Now the likely issue is related to your version L firmware. See this link to info about the AP drivers
This suggests that the AP experimental driver will only work for versions V and above (Mine is V13). Unless you upgrade your firmware to the V version you should really be using one of the other versions.
I think that other versions do work but they don't have full functionality (I am not familiar with the changes but I think they relate to parking behaviour etc).
Updating the firmware is relatively simple
Here is the link to the AP site info.
Maybe one of the users of the GTOCTP3 could advise?
This post may contain the info you need although I think that Astroberry is more of a problem to update.
My system is KStars on Ubuntu Mate 20.10.
I am unfamiliar with Astroberry so can't help there. A quick look through the above post suggests it should be helpful.
Jerry Black (thanks Jerry!) has developed a script that automates setting up KStars and would be worth a look. Here is the link.
Here is the link to instructions for ubuntu and other Linux platforms-
I was unclear what platform you are using but if you look here
there are general instructions too.
I'm not sure that you need the gsc any more and the last time I used this command it did not work so if you have this problem omit gsc from the commands (see below). Just type these into terminal.
sudo apt-add-repository ppa:mutlaqja/indinightly
sudo apt-get update
sudo apt-get install indi-full kstars-bleeding gsc
This will lock in the ppa repository to be updated when you do a software update. The latest nightly build should show as Version 3.5.4 beta (find this in the "help" menu in "about KStars").
As the nightly build can introduce instabilities, once you find the setup works I would go into the "software update" settings in the Administration dropdowns and uncheck the indinightly updates and any stable updates in regard to KStars/indi. This is in the "other software tab." This will lock in the working version and avoid updating for a while until you gain confidence in the system.
I will send you my workflow that I tested a couple of days ago which worked well, I will have to send this from another computer.