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!

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.
I remember my disappointment when I finished my very first session with a camera many years ago. I was so excited and stayed long during night and the first thing I did in the morning was checking the results... But there was nothing there on the pictures, just a few stars and totally black background
Your light frames are taken with unmodified DSLR and each capture is 30 sec @ ISO 800 and 250/1200 newtonian (f/4., which is too low for M51. Just for comparison when imaging this object I was taking 300 sec exposures with dedicated CCD camera and f/4 newtonian, which is 20% "brighter".
All the best and lots of clear sky!

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 !!!!

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.

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"?

There is no difference... in case of square pixels i.e. Pixel size = Pixel size X = Pixel size Y (all in μm).
This is not the case for pixels, which are rectangular i.e. Pixel size X != Pixel size Y
However I don't know how Pixel size is handled in the latter case

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".

Yes it was me and it works for DSLR (been doing DSLR on Indi for over 2 yrs) and still no one has answered why it does work - I do not use UM in X and Y only in Pixel Size.

Still awaiting an answer from developers (e.g. @KNRO) - Yes Radek it does allow any floating point number - but it what you do with it and decide what the value is in coding that counts as you know

I will start a new thread!

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 groups.io 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.
groups.io/g/DeepSkyStacker/topic/73054745#23793

Sorry I missed this one...
I have taken another look at your flats. I was wrong. It's not that bad While looking at pixel values on your flats I was thinking of 16bit camera
Camera pixel depth is 12bit (ADU 0-4096), minimum on your flats is 318 and maximum is 1978, average 869 (21% of maximum). So you're placing histogram peak at 1/5 of depth range. It is quite ok, I would normally push it to 1/4 - 1/3. If they work ok you can leave them at 1/5 though.

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