Add an option to apply specified calibration files to images in the image viewer

[Simon Kapadia]

Apparently this suggestion has been made a few times before but isn’t being tracked with an issue, so I thought it was worth-while creating one for it.

The ask is to allow for calibration files to be applied to images in the image viewer. This will make seeing what is actually in the image you are capturing easier, especially for those of us who have cameras with huge amp glow starbursts or dirty sensors! It could be an extra option on the Image Options in the Imaging tab, under Autostretch Factor. It doesn't have to be anything fancy -- just let folks provide a master flat and master dark and apply those to the image before stretching it.

[Dale Ghent]

Bug / Major is a misclassification of this.

I am not for this. NINA is implicitly not an image processing application, and I’m hesitant to see the typical trappings of one being introduced into it. If it’s flats and darks today, it’ll be white balance and RGB mixing tomorrow, and then requests for sharpening, contrast, and curves the day after. The point of NINA presenting images the way it currently does is to display what is coming right off the camera, and nothing more.

[Simon Kapadia]

Apologies for the misclassification, I didn’t change the defaults; certainly not a bug!

Question: would you ever want to do those kinds of things you mention on a single frame? It seems that those are things that you would do to a stack, in an imaging processing application. I agree, NINA is not an image processing application, nor is it a stacker, nor should it be. But the point of displaying the image, as you have rightly said, is to see what you have captured. The “auto stretch” exists specifically so that you can more easily see what you have captured on that single frame. Adding a master dark and master flat would likewise make it easier to see what has been captured on a single frame (and would be a major quality of life improvement for those without top end cooled perfect cameras — people just starting in AP, who we should surely be trying to encourage into the NINA family).

Summary: it is reasonable to add functionality which makes it easier to see what you have “right off the camera” for a single shot. If not, then we should remove autostretch, so you can just look at the truly “right off the camera” data . It is not reasonable to add other function which would typically be done to a stack.

[Jonathan MacCollum]

I don’t think the OP is suggesting NINA head in the direction of image processing by any means. Nothing in the request indicates moving in that direction and is on-par with other features available on the imaging screen (such as screen stretching, debayering and unlinked stretch), but I do share your opinion on not wanting the software to dive into post-processing.@Dale Ghent

I am for this request. I do think that allowing flats, dark and bias calibrate on image download (and even optionally saving a second copy of the calibrated image to disk for that matter) would be a significant improvement to the acquisition process itself. Additional benefit’s not stated by the OP:

• It informs the user whether or not the darks/flats taken before a session (via the flats wizard) correctly calibrate or really require additional flats to be taken after the session. This prevents a lot of back-and-forth with those new to astrophotography when they typically don’t calibrate until after they have taken down their equipment, and this can be worked through
• One additional benefit would be that it allows for a more informed information about the data coming from the camera where post-calibrated mean background levels can be beneficial.

‌

There is some complexity to work through with the enhancement proposed:

• Applying a different bias/flat/dark depending on the gain/offset/duration/filter of the light frame being applied. Perhaps assigning one to each row in a sequence or just allowing the imaging screen to “remember the last one set for this combination” (when the option is enabled.)

‌

‌

[Dale Ghent]

I do not agree with the assertion that calibration in NINA will inform the user of the results that calibration done in a dedicated post-processing application would produce, as there are many variables that can affect the calibrated output in those applications. Because of that, this feels too much like a rabbit hole which will easily accumulate baggage that distracts from NINA’s core mission. If a user wants to see what a single frame calibrates as, they should do it in their post-processing app of choice so that it can be done using the settings and algorithms they would normally use.

[Simon Kapadia]

For me this isn’t about seeing a final perfect image of a calibrated post-processed stack. It’s about seeing something usable without the inherent defects in less than perfect setups. I assume @Dale Ghent that you have a high end setup with a wonderful (expensive) camera and that your single subs are easy to view in the image window (once autostretch is complete). That just isn’t true for everyone…

I fail to see how this suggestion is so hurtful to you that you are arguing so passionately against it. Am I missing something here?

[Dale Ghent]

I strongly feel that it sets a bad president. If this were implemented, a separate person can come along in 3 months and say “HI, because you already let flats and darks be applied to an image, would be REALLY COOL if NINA could take the exposures from the separate R G B filters and combine them so I can see what the color image would look like.” Lines have to be drawn, and they’re best drawn early, not when you’ve got a Mr. Potato Head mishmash of things that clutter and distract.

I’m also a big believer that separate, dedicated tools do a better job in their specialized roles than one tool that tries to do it all. NINA’s raison d’etre is image planning and acquisition. It aims to do these things well, and should continue to implement features that directly contribute to and facilitate that mission. Live stacking, live calibration, and things of that nature are not necessary for that and begin a slippery slope towards an attempt to be a MaximDL.

[Simon Kapadia]

So with that rationale, would you advocate for removal of the autostretch algorithm? After all, you can just load your image into pixinsight if you want to see what it looks like stretched. It’s apparently the same algorithm, so there’s no place for it in NINA.

Seriously, I agree with your point, there should certainly be limits, and it’s rare for me to resort to reducto-ad-absurdum, but there’s a huge and very obvious difference between simply calibrating to make it easier to see what’s been captured in a single sub, to composing multiple subs into a single image as you describe. Nobody is asking for live stacking, or even live full calibration – just improvement of the visual to enable better decisions to be made during the raison d’etre of NINA – image planning and acquisition.

[Dale Ghent]

Autostretch is required unless you prefer looking at black rectangles. It’s not even on by default, does not require much in the way of screen real estate to exist, does not demand interlocking and interplaying options to configure, and does not require multiple algorithms to suit the user’s preferences. Calibration is not “simple” as you claim, and anyone who uses tools such as PI knows that “simple” calibration can still present a multitude of ways of accomplishing it. We could pick some static method of doing it with a few very coarse controls, but then someone will not want that and will demand it “be like PI” or whatever their favorite app is. The idea might be simple; the implementation of it is not. It begins the growth of NINA in an unwanted direction - that of an image processing application.

[Simon Kapadia]

Wow, someone might come and demand? That’s not really gonna get them much in an open source project, is it! I mean, everyone else can always say no . I guess if they really feel so strongly they can fork, and the community goes wherever the community goes. That’s open source for you! That said, I’m sure you’ll agree that this is an unlikely scenario; protecting against a hypothetical future demand is not a reason to not implement something.

Calibration of a single frame with a single master dark is a single operation (subtraction). Calibration of a single frame with a single master flat is a single operation (division). Creation of these frames is something you do in your image processing software. All of the other complications are irrelevant, as they are not the province of NINA.

[Dale Ghent]

It’s funny how someone with no contribution is trying to tell one of the contributors how open source works.

[Stefan B]

Guys this isn’t leading anywhere. Keep the discussion productive.

There are advantages to add dark substraction not only for visual but for example for improved star detection etc. So it could be interesting to implement. However some challenges, exist such as dark frames are not universally applicapble (gain, offset, exposure time yada yada) and while the dark substraction itself is trivial, a nice configuration of these is the real challenge. Furthermore it will impact performance and/or has a higher memory footprint etc.

‌

‌

[Simon Kapadia]

I hadn’t considered auto matching of frames – that seems like an extra layer of complexity; my thought was to simply allow the user to specify a master dark and it’s up to them to get that right for the images they’re taking. That said, I’d not thought about the wider implication for star detection (and for that matter for plate-solving – we’d be sending a significantly improved image to the platesolver; I recently convinced Han.K to add autocalibration during plate-solving to ASTAP and it has dramatically improved plate-solving for me). Of course you are right; if it’s going to be useful for more than just visual display, then it needs to be more robust than I originaly suggested. How about, as a first step, allowing for a calibration frame to be applied to a row in the sequence, or simply included in the imaging tab?

[Stefan B]

setting it to on-hold, as this is hard to set up properly and also a bit of feature creep for nina.