Filroden

I could drop to unity but I doubt my mount would be happy much above 60s, particularly in this wind so I'll stick to the higher gain and lower exposure. I've just checked more frames and the cores of more stars are over exposed in L but only just. Hoping that the RGB filters will do enough to bring it back within range. It's useful to test these things and know about them for future projects. And I just found SGPro has a frame grading tool so I can drop really bad frames even before copying them over to PixInsight!

At 300 gain the 4 brightest stars are overexposed in L so should be fine in RGB. And I think 3 of them fall outside my crop area anyway  Looks like 45s / 300 gain is my limit.

I think 400 gain is too high for LRGB. Probably fine for narrowband. Even at 15s it was looking overexposed and I did not relish the though if tripling my image count so I'm dropping back to 45s at 300 gain and no offset.

I just wondered how you spotted you had a bad one. I never check bias/dark subs and just assume the linear fit algorithm will weed out the bad data.

Now I've hit a snag. Even 30s at 400 gain is over exposing my image. Hopefully its because there is still 20 mins until astro dark but I may have to drop back to 300 gain.

Are you visually inspecting the darks?

It's by no means certain. Large clouds passing over all the time but as it cools I think it will clear (and the wind is picking up). I'm amazed by the cooling on the camera. From an ambient of about 8C it went down to -30C and says it's only using 44% power!

I'm giving -30C and 400 gain / 10 offset a try tonight to add to my NGC1333 project. If all else fails I can go back to -20C and 300/0. I'm assuming I only need new darks and not bias for any changes I make given how short the bias exposures are?

Yes, no discernible difference. I wonder if it's just a combination of you having it scaled on screen at 1:6 then converted and reduced in resolution for the forum making it look like a flat grey background when in fact there might be fixed pattern noise there, but just not visible to me. Anyway, all you can do is use them in the integration process and see the results!

I wonder if that's too short even though technically it's within the specification of the camera? Your darks show what appears to be fixed vertical patterns which I'd expect to be calibrated out with the bias but that same pattern is not visible in the bias.

What exposure are you using?

That's a lot of gin!

6 minutes ago, Gina said:

My lights are with gains of 440 and 500 - a lot more than yours and the offset I've been using is 10.  Could you tell me the reason for using an offset of 50, please?  And have you done tests at various gains - is 300 better that 440 or 500?  I'm still experimenting and learning and very interested in other people's settings and why.

No reason other than it was the default given by the driver for that gain. I've since dropped my offset to zero as, at a gain of 300, my histograms are all clearing the right side, even blue. I have yet to try any other gain but have been watching your and other results at various gains to see what difference it might make. I think 300 is where the read noise starts to bottom out but still leaves more dynamic range than higher settings. I had considered testing unity at some stage but 300 seems to give me results and if it isn't broke I haven't fixed it

That looks very different to my own. Here's my master bias based on 256 subs at a 300 gain and 50 offset. This is taken with the standard auto-stretch applied. I'm not sure how clear it is but there are very feint variations, particularly vertical (which is where I would expect them).

Most recently, 128, all in xsif  format which is double the original size direct from camera. Previously I've integrated just under 200 lights and 300 bias. Again, all in xsif.

Looks similar to mine though I leave the file cache on. I also used 65 but I went to 10240 on stack size.

That's good to know. Although bias subs are only done once, I'm integrating around 200-300 lights now for some of my projects. 30s and 45s subs quickly add up. Mine ran just under 200 lights with 65Mb and 10Gb in a single integration, though it was still relatively slow suggesting it might have been calling to hard disk cache. I might just leave it at default settings too.

I wonder what is stopping it using more of your RAM. Maybe it needs to reserve RAM for every image in its buffer as well as for stacking - so you can only use half of what you might expect would be available?

Are you aware you can change buffer sizes in the ImageIntegration process that could improve performance?

Here's a quote from the reference documentation - the options mentioned are found under the Image Intergration section of the process. I believe that buffer size needs to be at least as large as your working image size (so over 64Mb for the ZWO 1600MM saved in xsif format) and the stack size should be lower than your total available RAM (leaving enough RAM for your operating system, etc to work). I have 16Gb of RAM so set this to 10Gb.

Quote

 

Buffer size

Size of a pixel row buffer in mebibytes (MiB). This parameter defines the size of the working buffers used to read pixel rows. There is an independent buffer per input image. A reasonably large buffer size will improve performance by minimizing disk reading operations. The default value of 16 MiB is usually quite appropriate. Decrease this parameter if you experience out-of-memory errors during integration. This may be necessary for integration of large image sets on systems with low memory resources, especially on 32-bit operating systems. The minimum value is zero, which will force ImageIntegration to use a single row of pixels per input image.

Stack size

This is the size of the working integration stack structure in MiB. In general, the larger this parameter, the better the performance, especially on multiprocessor and multicore systems. The best performance is achieved when the whole set of integrated pixels can be loaded at once in the integration stack. For this to happen, the following conditions must hold:

Buffer size (see above) must be large enough as to allow loading an input file (in 32-bit floating point format) completely in a single file reading operation.
Stack size must be larger than or equal to W×H×(12×N + 4), where W and H are the image width and height in pixels, respectively, and N is the number of integrated images. For linear fit clipping rejection, replace 4 with 8 in the above equation. Note that this may require a large amount of RAM available for relatively large image sets. As an example, the default stack size of 1024 (1 GiB) is sufficient to integrate 20 2048×2048 monochrome images optimally with the default buffer size of 16 MiB. With a stack size of 4 GiB and a buffer size of 64 MiB you could integrate 20 4K×4K monochrome images with optimum performance on a 64-bit version of PixInsight.

Use file cache

By default, ImageIntegration uses a dynamic cache of working image parameters, including pixel statistics and normalization data. This cache greatly improves performance when the same images are being integrated several times, for example to find optimal pixel rejection parameters. Disable this option if for some reason you don't want to use the cache. This will force recalculation of all statistical data required for normalization, which involves loading all integrated image files from disk. The file cache can also be persistent across PixInsight Core executions. The persistent cache and its options can be controlled with the Cache Preferences dialog.

 

2 hours ago, Nigel G said:

I wonder if the increase in star size is due to mount errors,  the star moves around a tiny bit more. 

 

I'm not sure. I'd just assumed it was the brighter stars' photons spilling over into adjacent wells. The longer the exposure, the more chance they extend. But given they are not saturated, I'm now not so sure why I see larger stars in longer exposures.

2 minutes ago, Nigel G said:

That's quite an improvement Ken, the dark areas much more visible.

Do you think adding 45s instead of increasing the amount of 30s made a difference?  Personally I think it does with the fainter details. 

Hope you get your mount sorted out.

Cheers

Nige. 

 

I'm not convinced. I'm capturing the same number of stars but the 45s exposures increase their size. It probably does help with the fainter stuff and it's certainly easier to process. My camera has such a low read noise I think both e postures are effective. 

Well, I got two short runs at NGC1333 over the last couple of nights before the moon rose (and I had mount troubles). Here's the capture data for all four versions (1 & 2 used the same data but were processed differently). I've actually captured many more subs but for this v4 I was much more selective on which ones I used for the integration.

30s subs were captured at -20C at a gain of 300 and an offset of 50

45s subs were captured at -20C at a gain of 300 and an offset of 0

All captured on the Evo mount using the Skywatcher Esprit 80 and the ZWO ASI1600MM-C, and processed in PixInsight with a final boost in Photoshop.

Here's all four versions for comparison:

Version 1

Version 2

Version 3

Version 4

13 hours ago, Gina said:

I shall need to read the Calibration and Integration section again to take it all in.  So far I've gathered that several hundred bias frames are required and I've just read the suggestion of twice as many darks as lights.  Now one of my sets of lights amount to 250 frames which would indicate 500 darks.  500 x 1m darks is over 8 hours - this is getting ridiculous!  Maybe the 250 lights want pruning to select the very best.  I gather that adding extra poorer quality lights can degrade rather than improve the result - so fewer really good lights should be better.

Seems PixInsight works rather differently from DSS et al and uses different ideas to obtain improved results.  This is all very interesting and encouraging but I have an awful lot to learn!!  Good job I like learning

I think he assumes you're taking few, long exposure lights so double darks could be right. For many short lights I wouldn't go more than about 30-50 darks.

5 minutes ago, parallaxerr said:

Like the sound of that Ken, especially the user defined areas. More functions than I realised. 

Dear Santa......

It's worth taking a look at the manual http://www.celestron.com/media/1317936/94005_starsense_autoalign_manual_february2016.pdf

9 minutes ago, parallaxerr said:

How does the starsense cope with an alt limitation? Despite getting good alignments, I've been fancying one for the plate solving, but I thought I may get a mount conflict if it's free to slew where it wants.

I can set slew limits plus I use it manually as I have limited views. You can save your three manual areas as a user defined program so you can reuse it if you set up in the same spot each time.

its one downside is that you do lose alignment a little each time you remove it from the mount as you can't put it back in the view finder slot quite the same each time. But my target is still in the centre of the frame and a small manual slew gets it where I want it.

1 hour ago, parallaxerr said:

Made a few changes to my set up last night as a result of the discussion above. 

The WO OTA has an L bracket attached which has a vixen dovetail form. It's neat but doesn't allow me much adjustment. I dug out a 7" dovetail and eventually found some bolts to fit as the two required are different threads!!! One bolt goes through the dovetail and attaches to the L bracket photo tripod adapter which is 1/4-20UNC and the other goes through the dovetail and L bracket and screws into the OTA, think its a UNF thread.

I had to remove the plastic trim around the dovetail clamp as the focus knobs inerfered, but now I have full freedom to slide the scope fore and aft.

The result is that I'm now balanced slightly objective heavy. Hopefully this means the Alt gear is always under load and driving the scope up instead of allowing it up, as it was when tail heavy, if you see what I mean? Also, I now have no Alt restriction 

The clutch was also a tad loose. Whilst there was some friction between the plates, there was barely any torque on the nut so that's been tweaked up. Hopefully less binned subs next session.

Oh to be back in the spot where I was not alt limited! My SCT with DSLR easily clears the base but the refractor and the much longer camera train now are far too long. I also only have a short dovetail and it is very tail heavy. I may have to see if I can do something similar.

Hopefully your tracking will be spot on now.

I'm going to check my mount over. I'd forgotten how cold it was last night so it might just be the changing temperatures?