Chris created a new topic ' Canon EOS 1000D - How to take flats?' in the forum. 3 years ago

I'm new to KStars and Ekos. I have recently installed Astroberry 2.0.1. I used Windows / ASCOM / EQASCOM before.

I'm trying to take some flats with my Canon EOS 1000D and I seem to have an issue with exposure time.
I have some old flats that show an exposure time of 1/4000sec. So I set up a plan in Ekos - Camera tab, set Type to Flat, duration to 0.000250, count 5, ISO 800.

Ekos proceeds to take the exposures, but when I open them they are completely white. The exposure time shown is 1sec (that would explain the white as they would be completely overexposed).
I've tried several values below 1sec for exposure time but I always seem to get 1sec exposures.

How can I get very short exposures for flats?

Could it be because the camera is set to M mode? I tried changing the camera to Av mode but then the capture fails and I get an error in Ekos Control Panel:
[WARNING] Camera auto exposure mode is not set to either BULB or MANUAL modes (AV). Please set mode to BULB for long exposures.



I'm working on motorising my roll-off observatory roof and ultimately I would like to control it from Ekos.

I understand this would fall under Dome control but I would only need the park / unpark (i.e. Roof close / open) functionality and not the dome rotation that follows the mount.

I'm fine with the mechanics and coding on the roof controller side (probably an Arduino).

The question is: is there an existing INDI dome driver that I could use where the communication with the controller is documented? I could then write the controller firmware according to that protocol.
I have done something similar with my DIY motor focuser where I found a project with Arduino code that simulates a Moonlite focuser ("myFocuserPro" - ) and modified the code slightly to fit my focuser.
I have Arduino and .NET coding experience, but no experience whatsoever with coding on Linux / INDI.

And I also want to build a motorised dust cap with flat frame light source later. I would have exact same question for that project.
I have found this page on the INDI website that talks about a DIY dust cover but this is not the way I want to do it (connecting to the RaspberryPi I/O pins directly. It would have to be over USB.



Thanks for taking the time to look at the flats again.
Do you think it is a big problem that they are very blue?


OK, I got the solution for the FITS issue. Posting it here in case someone reads this thread later.

I had also posted the question in the DSS group on and got a pretty good reply there.

The issue is that DSS does not know the real bit depth of FITS files. It *does* know it for RAW / CR2 files. So DSS scales the CR2 files automatically to 16bit (in my case from 12bit). But since it does not know the bit depth of FITS files it does not scale them which makes them look 16 times darker.

The solution is to set "Brightnes" in the DSS FITS settings from 1 to 16 (for a camera with 12bit sensor). This will multiply each pixel value by 16 which is the same as scaling 12bit to 16bit (i.e. left bit shift by 4 bits). For a 14 bit camera you would need to set it to 4.

Full topic here if anyone is interested. Not sure if this can be viewed without an account.


OK, hat's what I thought it was without reading up on it. ;-)
I was just a bit worried because someone here suggested to use the sensor size in mm for "Pixel Size X/Y".


Kaczorek wrote:

stash wrote: Radek , do you know why the Indi system,dealing with DSLR's, has Pixel size in UM but allows the X & Y in both MM and UM - which is correct? it seems both !!!!

I think pixel size just takes any float number. However it is assumed to be in um. At least it is my understanding

So what is the difference between "Pixel Size (um)" and "Pixel Size X/Y"?


Kaczorek wrote: I would say it's typical pitfall ;-) Exposed frames always look totally black before you shift histogram to right. No matter before or after stacking.

Yes, I know. ;-)
I've been imaging for a few years already, just on Windows, had a 4 year break (other priorities) and I'm now starting again with the whole observatory control moved to Astroberry / KStars.
I've never used FITS files before though, only CR2.

I know that light frames are usually very dark. But not completely black. ;-)
When I load a CR2 file with the same exposure and everything else the same into DSS, I see the image. It is very dark indeed, but I do see stars and a hint of the galaxy / nebula. When I load the FITS it is completely black. No stars. Not even hot pixels.
The same for flats. When I load a CR2 flat in DSS, I see a rather light image with the gradient. When I load a FITS flat, I get a completely black image.

But since you guys have shown that there is actual data in these FITS, I'll just put it down to a difference in how DSS displays CR2 and FITS in the preview. Or something like that. ;-)
And I'll probably stick with CR2 for now. ;-)

Thanks for all your help. I've definitely learned something here.


OK, so it's just me then. I didn't actually stack them.
What do you get when you just load the light frame in DSS (add to list) and then click on it to see the preview? Does that show data for you? This is where I see it completely black, including the flat.

Yes, they are only 30sec frames. I will ramp up exposure time once I get guiding working.

Thanks for testing this for me, guys! ;)


Does that mean it is also wrong for my QHY5?

Here I don't seem to have a way of changing it.


stash wrote: Your pixel size X,Y are wrong - surely they should be 22.2 and 14.8 ??????????

ah, is that supposed to be the sensor size in mm? "Pixel Size" is a bit confusing then...


Thanks, I have added one FITS and one CR2 light frame to the same folder.

I'm somewhat surprised by your comment about my flats. It was my understanding that it was best to let the camera choose the exposure when pointing at the flat panel (light source). When I do that, my camera selects 1/4000sec. I then selected that in Ekos.
The next higher exposure setting seems to be 1/100 (0.001sec). When I use that the flats are over exposed. When I open the CR2 flat it looks good to me (if a bit blue-ish), but I'm by no means an expert... ;)
Is my flat panel too bright? It's an old LED TV with the display removed and only the backlight left, which I made remote controllable. It is mounted on the wall in front of the telescope when it's parked.


Kaczorek wrote: An example file would be very helpful here ;-)

indeed. ;-)

there is one .cr2 and one FITS flat frame here:
I only changed the file format, all other settings were identical.


1. When you take an image does the Indi viewer show the image as black even when stretched ?
No, the viewer in Indi shows the correct image, as does the Ekos dashboard ("Settings" tab)

2. Double check your frame settings and pixel sizes in Indi settings - I suspect this is the problem
Do you mean these settings?

3. Check your DSS is up todate
It is the current 4.2.3 64bit. I upgraded a few days ago while investigating this issue.

4. If the Indi viewer is showing a non black image then your settings in DSS are wrong
see 1.

5. In your Indi settings what are your Format etc settings set to - screen print always help here :-)
Do you mean the settings above? If not, which settings do you mean exactly? (I'm quite new to Ekos)

>> Plus take note of the colour indicators in Indi Settings - they should be all green - are any RED indicating a problem.
All are green or white

6. Load one of he many FITS viewer's for Windows and see if the image
Yes, I have a FITS viewer and that shows data in the images.

>> DSS is quite able,as you no doubt already know , to handle FITS from Indi - I use it via Astrotoaster all the time and there is no problems - so long as your settings in Indi AND DSS are correct.
Yes, I thought so. This can't be a general problem or my search before posting would have come up with either a solution, or a long list of people reporting issues. ;-) I'm sure this is something on my side (either Ekos or DSS) but I'm not experienced enough to investigate further on my own.
These are the FITS settings in my DSS:


Not really, the only reason why I tried FITS was that FITS is a standard and CR2 is a Canon proprietary format. I thought it would make sense to save my data in a format that is a standard for astrophotography to be a little more future-proof.
If that doesn't work (though I still wonder why), then I have no problem saving my data in CR2 format.