Come join the friendliest, most engaging and inclusive astronomy forum geared for beginners and advanced telescope users, astrophotography devotees, plus check out our "Astro" goods vendors.
Come join the friendliest, most engaging and inclusive astronomy forum geared for beginners and advanced telescope users, astrophotography devotees, plus check out our "Astro" goods vendors.
I had my first test run (inside, no guiding, no platesolving) with NINA last night. It was pretty rudimentary, but I got some positives out of it, and some negatives. I am not sure if some of my negatives are a result of not being able to fully exercise the software, or possibly to do with the issues I had installing the program in the first place. Those issues were around my corrupted Visual C++ install, which to a very long time to figure out and find the fix for. Other potential issues are my poor understanding of what to expect.
First, the positives:
able to connect the Canon 60D
connected the Celestron ASGT
Connected PHD2
added sequences
Successful automatic meridian flip
slewing to different targets always set up the scope on the correct side of the mount
Negatives:
unable to add multiple targets to a sequence, when I added a new line to the sequence with a different object, that object replaced the object I had added on previous steps
Couldn't figure out where to view images as they rolled in
customizations not saved across NINA restarts (setting a directory and file name attributes was most annoying, latitude and longitude, scope FL were among others)
related to previous - couldn't figure out how to save customizations
unable to figure out the connection to Cartes du Ciel
Couldn't find anything that reports the sensor temp on the 60D - the Chip Temp field remained blank the whole night
First thing I may do is uninstall and do a clean install of the program, not sure if there are residuals from my c++ issues.
Finally, I think I am showing my age. I would love to be able to search a forum for issues that have been reported by others. I am not a big fan of the Discord chat support model. I don't know enough to know what questions to ask at this stage, I would just love to see a searchable site for troubleshooting purposes.
My long term interest in NINA is the native support it has for ZWO cameras, something I am thinking about acquiring someday. Also the ability to set up multi-object sequences so I can sleep at night sometimes.
Anyway, that was my experience, I wanted to get it out there before I forgot everything and just tried again in a few days. Oh yeah, I was running version 1.9 Beta002.
Thanks for this, Bob...
I too am trying to get NINA up and running.
I had my own sets of issues as it was so hot out, I was running everything through Teamviewer so I wouldn't have to go out into the Obsy.
I couldn't get an image to load either, but it was giving me an "access Denied" screen, so it may have to do with going over the network.
I'm going to try again from the machine in the Obsy tonight to see if it fixes the issues.
I was able to save the configuration, and once I get home after dinner, I'll put down what I did and where I put it.
good Luck!
JimMinCT wrote: ↑Wed Jul 10, 2019 4:04 pm
Thanks for this, Bob...
I too am trying to get NINA up and running.
I had my own sets of issues as it was so hot out, I was running everything through Teamviewer so I wouldn't have to go out into the Obsy.
I couldn't get an image to load either, but it was giving me an "access Denied" screen, so it may have to do with going over the network.
I'm going to try again from the machine in the Obsy tonight to see if it fixes the issues.
I was able to save the configuration, and once I get home after dinner, I'll put down what I did and where I put it.
good Luck!
Thanks, Jim. Anything you can recall is appreciated!
I uninstalled and reinstalled this evening. The install went clean and didn't trip over either c++ library. I fired up and changed a few parameters: scope focal length, camera pixel size, some meridian flip options. They all seem to come back after shutting down and starting back up. So some progress there. I will report on more stuff when I get a chance to connect everything up.
As a side note, I am now getting emails from Discord with tips about how to run certain games that I have no interest in. Great, more spam, just what I needed!
My PC wants to apply some Windows updates. I am going to start those downloads and go to bed :asleep:
Hey, Bob...
I had all kinds of issues last night. Not with NINA, with everything else.
I couldn't find any buttons labeled "save configuration", but all the settings are saved it seems automatically..
And then the haze got so bad, even the Moon wouldn't focus properly.
I packed everything up about 10PM and headed back in.
I need to get a new set of cables from hub on the mount, to the machine in the Obsy.
Intermittent glitches are driving me crazy.
Talk to you later...
I just watched one of the videos Yannick has posted on YouTube concerning NINA, where he explains how to set up multiple targets in a session. Once I saw it, it became a 'head-slap' moment for me, just clicking the + icon at the top right of the sequence screen and defining the next target in the new target window that becomes available.
Since I did the uninstall and re-install of NINA, my customizations are being saved across sessions, that was another big issue for me. Slowly making progress. Will set up another quick test run in the next few days to amke sure things work as expected in real-time. Now if it would display the sensor temp (I'll try the $$SENSORTEMP$$ variable in my filenames) and get it to connect to Cartes du Ciel, I might be ready to go out under the sky and give it a real test. I am also going to watch the other two videos Yannick posted to see what else I am missing.
I made some real progress this evening. Another inside test to see about some of the remaining issues. I am now running the 1.9 beta002 release ( I see beta003 is available now and will give it a try.
Tonight I was able to:
set up multiple targets in sequence and run through the sequence a couple of times.
get the images to show up as they were taken (lots of noise and hot pixels, as I had the scope cover on)
arrange for the images to drop into the proper file location
validate that customizations are kept across restarts
got the 'flats wizard' to p0int my scope at the zenith, which will be handy when I want to place the lightbox over the OTA
Two trouble areas remain. The first is that the camera doesn't stay connected if it is idle for a few minutes. This has always been an issue this the 60D and probably has something to do with power-saving mode on the camera. I will check those settings before panicking
Second, the sensor temp still doesn't show up on the camera screen, nor in the filename string I am trying to build. Camera screen shows NaN as the Chip temperature, and the string in the file name just displays 0.
My general feel is that NINA really caters to the dedicated astrocam group, and doesn't have as strong a presence for DSLR users. Lots of tweaking knobs for offsets and the like, nothing for setting the camera to AV priority to get some nice DSLR flats.
I had hoped to switch to it now in preparation for a cooled astrocam in the future, but I think I will have to do the two changes at the same time.
Oh, and I still can't figure out Discord to save my life. I am not sure where to post an issue, how to search for posts that are already out there, etc. it may be my "old-guy" status kicking in, I just can't get comfortable with it, and I have taken several looks.
Canon (and Nikon) cameras do not expose environmental information through their SDKs, so NINA's display of NaN (Not a Number) for that is actually a display bug more than anything else (internally, NaN is the default value for that statistic.) As for file naming, since there is no temperature, we will need to figure out what we want to do for the %%SENSORTEMPERATURE%% token for cameras that do not provide this information - probably inserting a fake temperature (such as 0C) and noting this in the documentation.
The project does tend to focus on dedicated astrocams because that's what the current contributors spend the most time using in our own astrophotography pursuits. I would like to find some time to focus on rounding out DSLR-specific features and quality of life improvement such as what you mention, but there needs to be input from people who use them regularly. The best way to do this is to author a reasonably-detailed bug report for each idea here so that these can be remembered and used to inform decisions.
Thanks, Dale, for the explanation about what I am seeing, and a process for reporting it. The bitbucket link is helpful in seeing what types of requests are out there. I will see if I can put something together for what I am looking for.
I will find out where the data is stored before opening an issue. I suspect it is contained in the exif data for the camera, although I am not sure just yet. I know that other programs pull it, for example BYE allows the information to be included in the file name, and it displays the current sensor temp on the imaging screen.
Overall NINA is a very interesting product and has a lot of the things I am looking for. When (and if) I ever get around to that astrocam, I know where I am going for imaging software!
I want to also add that last week I had a long conversation with a manager in Canon's SDK group and I made sure that he was aware of the general AP community's desire for camera environmentals, specifically sensor temperature, to be exposed through the SDK. While some Canon cameras (and maybe Nikon too? I'm not sure because I'm not a Nikon user) do insert a vendor-specifc temperature field into the EXIF information of the files they produce, it's not clearly documented what this is a temperature of exactly. It could be the it could be from somewhere inside the camera body, it could be read off the sensor... we don't know. I'm hesitant to call it "sensor temperature" without knowing the details because it could very well not be that, and thus it'd be misleading. My Canon bodies call the field "Camera Temperature" - a generalized designation that is too ambiguous for me to accept as sensor temperature.
I'd like to help you here, and I've aired these desires straight into Canon's ear; but without more technical info and work from Canon's side, sensor temperature is going to remain elusive I think. Other AP software might extract the temperature EXIF tag from the image files and present it as sensor temperature, but I'm not as comfortable in doing that due to its general ambiguity.
A couple of things, I’ve owned two different Canon cameras a T1i and a T3i. Both of these cameras record sensor temperature and post it in the exif data.
On another forum, we’ve been discussing sensor temperature and Canon cameras since about 2015. The general consensus is the temperature reading is more of a camera circuitry temperature, and not necessarily the sensor itself.
My current main imaging program is Astro Photography Tool (APT) and by default it includes this temperature value in the file title.
Thanks for the follow-up information, Dale. It is unfortunate that it is not clear what the Canon camera temperature represents.
From a practical perspective, that value is the best information available to us APers to match lights and darks for calibration purposes, at least until Canon provides definitive direction. Thank you for having the conversation with the Canon folks.
bobharmony wrote: ↑Fri Jul 19, 2019 10:19 am
Thanks for the follow-up information, Dale. It is unfortunate that it is not clear what the Canon camera temperature represents.
From a practical perspective, that value is the best information available to us APers to match lights and darks for calibration purposes, at least until Canon provides definitive direction. Thank you for having the conversation with the Canon folks.
Bob
I would think that, for AP purposes, whether or not the actual sensor is being measured is not as important as that the same temp is obtained for the set of exposures.
Regardless of whether it's the camera body, or sensor, I'd think that consistency is more important than the actual location of the temp probe.
Unless someone thinks the sensor value would be that far removed, (and different in relationship from), the camera body.
My 2¢ adjusted for inflation
For all we know, the sensor can be in the DIGIC chip itself, and could be a reflection of the work it is doing versus the work that the sensor is doing. I understand that other software is claiming it to be sensor temperature, but I personally feel that's far too much of an assumption and potentially too detached from the imaging sensor for it to have any accurate meaning in the way we want to rely on it.
On astro cams, if the imaging sensor itself does not have an integrated thermocouple, the camera designer usually places a thermal sensor component (usually a thermal diode) directly beneath it on the circuit board, with a small amount of compound to ensure that there is thermal conductivity between the two sensors. This gives one a direct and consistent reading of the imaging sensor's temperature. On Canons, we do not know where this sensor is, and it could very well reflect the temperature of a component other than the imaging sensor that has a thermal work profile that is completely unrelated to that of the imaging sensor's. This means that one cannot rely on that temperature data to match darks and other images because the imaging sensor's actual temperature may be quite different and varied from this reading, even if the value presented by this thermal sensor is the same across different imaging sessions.
That is the ambiguity I'm speaking of, and why I do not (from a technical standpoint) want to declare it as something that users will take for gospel, with potentially grossly misleading results. To that end, I believe that APT et al who present this value as sensor temperature have made a mistake (or, at the least, a big assumption) in doing so.
dghent wrote: ↑Fri Jul 19, 2019 3:36 pm
For all we know, the sensor can be in the DIGIC chip itself, and could be a reflection of the work it is doing versus the work that the sensor is doing. I understand that other software is claiming it to be sensor temperature, but I personally feel that's far too much of an assumption and potentially too detached from the imaging sensor for it to have any accurate meaning in the way we want to rely on it.
On astro cams, if the imaging sensor itself does not have an integrated thermocouple, the camera designer usually places a thermal sensor component (usually a thermal diode) directly beneath it on the circuit board, with a small amount of compound to ensure that there is thermal conductivity between the two sensors. This gives one a direct and consistent reading of the imaging sensor's temperature. On Canons, we do not know where this sensor is, and it could very well reflect the temperature of a component other than the imaging sensor that has a thermal work profile that is completely unrelated to that of the imaging sensor's. This means that one cannot rely on that temperature data to match darks and other images because the imaging sensor's actual temperature may be quite different and varied from this reading, even if the value presented by this thermal sensor is the same across different imaging sessions.
That is the ambiguity I'm speaking of, and why I do not (from a technical standpoint) want to declare it as something that users will take for gospel, with potentially grossly misleading results. To that end, I believe that APT et al who present this value as sensor temperature have made a mistake (or, at the least, a big assumption) in doing so.
Dale, I understand your concerns, and the reasoning is clear to me. Maybe that's why my images tend to be a bit noisy, because I am mismatching darks and lights as a result of a misplaced assumption that the value reported by the camera is not related in any way to the sensor temperature. It is, however, the only data point that could be useful as a starting point in trying to figure out the correct lights and darks to match. If the only way to get it is to look through the exif data with yet another program, I suppose I could do that, but I'd rather not. It is just one more step to add to an already complex process.
It would be a matter of experimentation to figure out which range of reported dark temperatures are best at cancelling out the noise of a set of lights which report a particular temperature. While I am not a big fan of having to do trial and error this way, if I don't have the data point in the first place, it makes doing that effort that much more difficult.
My experience over the past four years imaging with the Canon 60D show that on nights when I collect both darks and lights, the reported temperatures tend to run very close to one another, and vary more by time of night (reflecting changes in the ambient temperature over time) than by any noticeable difference between light and dark temperatures. If NINA were configured to provide the data point, and included any caveat that is appropriate about the risks of relying on that datum, I would be able to consider it for my current setup. As it stands, I will have to wait to enjoy the benefits of the software until such time as I am able to spend the cash on a dedicated astro cam.
I appreciate all the hard work you and others have put into making NINA the fine tool it is, and look forward to being able to take part in that journey when I have gear that is fully supported by the software. Keep up the good work, and I wish you well on the growth of the NINA community over time!
When I first started out doing astrophotography, I used a DSLR like many do. When it came to darks, I created them as a normal part of the session (usually in the middle of it) because that was the only time I could expect them to have reasonable temperature similarity with the preceding and subsequent light frames. This was on a ca. 2008 Canon Rebel XTi, which lacks any temperature readout, in a EXIF tag or otherwise. Even after I moved up to a 50D, and then a 5D2 (both of which do sport the temperature readout), I still did it that way because the readout seemed, as you point out, too consistent between vastly different lengths of exposures. For an uncooled chip, it did not seem to follow the logic that the longer it works, the hotter it will get (up to a point), and this seemed to be true whether the exposure length was 30 seconds or 2 minutes, or exposing immediately after being powered on from a cold slumber or tens of shots in. The temperature reported just does not seem to reflect what one would expect, therefore I completely doubt its utility in informing temperature-matched exposures.
Once I moved to cooled CCD and CMOS cameras, where sensor temperature is not only known, but could be actively managed, I could then build and use dark libraries - a luxury in time savings and precision that a DSLR just incapable of affording. I didn't need to do the middle-of-session dark generation anymore, thus increasing my time on target, or suffer the aggravations of forgetting to generate them or running out of time to do so. Heck, in the early days of CMOS DSLRs, a dark frame would be generated right after every light frame. It was just part of the process that way.
If you're trying to use dark libraries with DSLRs, I think you're trying to use something that is pretty much the domain of cameras that have managed cooling. Yeah, dark libraries are super attractive to have and use for the points I already mentioned. But I think it's misleading to rely on the DSLR temperature reporting in order to match dark libraries with lights simply because there does not seem to be an association of that temperature reading with the actual temperature of the imaging sensor at the time of the exposures, which is precisely what is wanted when doing this matching. This why the closest one can get to perfection here is to generate darks during and as a part of each session, like one would with flats.
I understand that this is not the answer you're looking for, but at the same time I have to point out that using dark libraries with DSLRs is likely a suboptimal position to begin with, and that the best accuracy is achieved by generating darks in-situ rather than attempting to approximate using unreliable information.
