i should clarify that the pink star thing i was talking about is seen commonly when stars are overexposed, which happens frequently on some targets. that’s why i was suggesting shorter exposures. it sounds like you are having some kind of problem with the fits files being generated by (more recent?) versions of SGP?
what happens if you temporarily switch back to CR2 instead of fits? when SGP creates the fits it’s calling DCRAW in such a way that the data is “expanded” to fill a 16-bit integer space, so the data is not as it came from the camera anymore. however, that’s a linear transformation and it should not cause the files to be stretched. it might be worth shooting one or two CR2s just to rule this in or out. are you by any chance using CR2 bias/darks/flats with these fits files? that would mess things up as well.
Hi pfile,
I was only using 120s exposures. Definitely not overexposed. Yes the problem seems to be with the data going to Pixinsight from the newest version of SGP, since Pixinsight handles images from the same camera no problem that were taken by SGP last fall.
I will try shooting a few images in CR2 format. I am using SGP and FITS for all lights and calibration frames, as always. Whatever this is, it is new. I am very used to using the 6D with SGP and Pixinsight, and nothing in my processing or settings has changed that I can think of.
Okay I think I have sort of figured it out. What seems to be happening is that somehow the green of the comet is confusing something in the colour balance while debayering, resulting in the bright blue sky and pink stars. This is my first time processing a comet, and the first time I ever had a problem with colour balance and processing with Pixinsight and the 6D. I thought there might be a connection.
I actually AM able to stretch the image. When after debayering I saw the blue image on the left in the screenshot, I assumed it was already stretched somehow. In fact it is not…it is still linear. Stretching it using the STF gives the image on the right. Much better colour, though with lots of gradient caused by the almost full moon. So I will go ahead and finish processing it and then adjust the colour balance.
hm, the PI debayer process does not do any color balancing. if you use DCRAW to debayer the images then the WB in the camera metadata might be respected depending on settings. but clearly given the _c_d_r naming of your files, they came out of BPP and so DCRAW’s debayer was not used.
anyway, after DBE the background should be more neutral.
Hi pfile,
Yes I have Pixinsight set to not colour balance…so I am kind of grasping at straws as to what is making the linear images so out of balance. It’s almost like the green had been removed, leaving blue and pink as the dominant colours to the linear image.
Here is the rather crude final result. This is ten 2 minute exposures. Even 2 minutes was too long and blurred the comet. It was moving fast and was not very bright. And the moon was almost full as well, but it was a good excuse to play with my new mount.
yeah comets are hard. at least once i’ve had to guide on the comet’s head, and that was only possible because it was pretty bright. now that i’m using APCC i can probably more easily set a custom rate directly from the ephemeris (although now that i think about it, that might be an APCC Pro function and not available in APCC Standard)
Hi Rob,
I do have APCC Pro and once I am used to the software plan to image comets by doing a large pointing model and then using the custom rate downloaded from JPL to track it with the Tak at least. I use an OAG with both my Edge and Tak, so guiding on the comet isn’t an option for me. I’ve only had 2 nights with the Mach 1 since I got it, and I can only do so much learning indoors. Hoping for clear sky tomorrow night to play a bit with modelling.
yeah, true, that was before i was using an OAG. the horizons thing in APCC Pro should be very useful - i tried to do it once by calculating the multipliers from sidereal and mostly succeeded with just the driver but it was a real pain. have you tried the new feature in APCC to transmit the meridian limits to SGP?
Rob, I had not been aware of this feature to transmit meridian limits from APCC to SGP. I will check it out. I intend to use the meridian delay feature in APCC a lot and avoid flips as much as possible. I always use an OAG, and with the Edge 9.25 guide stars can be a enough of a hassle to find that I don’t want to have to look for a new one after flipping. Or messing around rotating the OAG.
G’day guys. Sorry haven’t replied sooner. Haven’t been imaging much lately, and just noticed replies to this thread of mine. I haven’t imaged with my 5DII and SGP since this post. Have been using APT if imaging with 5DII, and SGP with my QSI583. Still following thread with interest and will test if weather clears and I get the opportunity.
I recently used a 60Da with SGP for the first time. Two gotcha’s - make sure you capture the bias, dark, flat and lights using the same file format!!! (The other is the mirror lock up - make sure that if you have the mirror delay enabled in SGP, you enable MLU in the Canon too.)
I found the easiest way to get to something sensible in PI was to separate the RGB file into R, G and B and then linear fit them before recombining. That gives a very good approximation. The other thing that may be happening here is clipping on one channel - I found that at ISO800, my exposures were just 90 seconds.
@buzz this is a totally valid point. I would also add that this is not specific to the 60Da and should be followed, as a general rule, for all DSLR cameras.
