DJScotty was kind enough to send me the Ha and Oiii masters for his first mosaic panel on the Rosette. He had some interesting registration issues due to changes in the optical train:
Quote:
Originally Posted by DJScotty
I have figured out what the issue is with the alignment of stars.
In between shooting the OIII and Ha data, I disassembled the imaging train after a little mishap in the observatory (part of the roof falling on the camera and knocking the focuser out of whack!) as a result, after reassembling, the focal plane was different (slightly tilted differently, resulting in slightly different picture "shape").
I tried using CCDStack2 and PI to re-register the images. Scott also had some success with DSS so I grabbed his final image as well. The results are attached. The four images are a small crop of the worst area of the whole FOV:
Registered with CCDStack FFT (CCDIS alignment failed)
Registered with DSS
Registered with PI StarAlignment
Registered with PI StarAlignment with distortion correction
Ignore the variation in colours and background. I didn't attempt to equalize them. This is only a single test so not definitive proof of anything but I do have to say that the results I can squeeze out of PI, sometimes with a bit of extra work, have always been damn fine
Interesting stuff Rick, thanks for posting - good to see DSS do a good job. If Scottie/you are ok with me having a go i can run it through RegiStar to add to the comparo.
Interesting stuff Rick, thanks for posting - good to see DSS do a good job. If Scottie/you are ok with me having a go i can run it through RegiStar to add to the comparo.
Fine with me if Scotty doesn't mind, Russ! I have Registar as well but don't use it much because it only works with integer FITS files (and because it always takes me an hour to figure out how to drive it because I haven't done it for ages!)
Rick - I understand that only stacking of 2 master subs have been compared here. If that's the case, then I am almost certain that also registering individual subs with PI star alignment with distortion correction would yield even better result.
I foun d similar results as you know - I had an issue with CCDStack and PI wanting to only register the hot and cold pixels and ignore the stars - the big issue for me is, because I use OSC and MUST debayer peior to registration, of course the algorithms are going to like saturated colour pixels more than white.
Anyway, I found a way in CCDStack to now get a result as TIGHT as PI, and in far less time. I had to register and then register the lanzcos/sinc36 twice in CCDStack until there was NO discernable image shift on blink.
PI did the same in the end for me too, but the process takes a LOT longer for the same end result (there is NO star size difference in the end when you overlay each stack on each other).
So, I am still undecided if to use PI or CCDStack despite my PI victory last week
PI REALLY needs to get more friendly with their output scripts too - they need to have an EASILY found "Save Scaled Data" function, not squirreled away in technospeak . PS REAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAALY hates PI's TIFFS - the level histogram is impossible to work with
Rick - I understand that only stacking of 2 master subs have been compared here. If that's the case, then I am almost certain that also registering individual subs with PI star alignment with distortion correction would yield even better result.
I think all the packages would probably produce better results registering individual subs but it's a tricky problem and simple transformation, rotation and scaling isn't enough to do a good registration in this case.
Quote:
Originally Posted by LewisM
I foun d similar results as you know - I had an issue with CCDStack and PI wanting to only register the hot and cold pixels and ignore the stars - the big issue for me is, because I use OSC and MUST debayer peior to registration, of course the algorithms are going to like saturated colour pixels more than white.
Anyway, I found a way in CCDStack to now get a result as TIGHT as PI, and in far less time. I had to register and then register the lanzcos/sinc36 twice in CCDStack until there was NO discernable image shift on blink.
PI did the same in the end for me too, but the process takes a LOT longer for the same end result (there is NO star size difference in the end when you overlay each stack on each other).
So, I am still undecided if to use PI or CCDStack despite my PI victory last week
PI REALLY needs to get more friendly with their output scripts too - they need to have an EASILY found "Save Scaled Data" function, not squirreled away in technospeak . PS REAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAALY hates PI's TIFFS - the level histogram is impossible to work with
If you want to compare star sizes use the FWHMEccentricity script. It will do a much better job of figuring out FWHM than you'll ever do by eye. It will also show how the FWHM varies over the FOV.
I'm sure I've written 32-bit TIFF files that were OK in PS. Don't remember offhand what options I used, though.
I'm sure I've written 32-bit TIFF files that were OK in PS. Don't remember offhand what options I used, though.
Cheers,
Rick.
That's the problem - figuring out HOW to make the scaled image and be readily readable elsewhere is an issue with PI - I think PI assumes the user has a PHD in Pixel Math
It is there, but it is NOT intuitive to use - but then again, what IS in PI?
PI REALLY needs to get more friendly with their output scripts too - they need to have an EASILY found "Save Scaled Data" function, not squirreled away in technospeak . PS REAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAALY hates PI's TIFFS - the level histogram is impossible to work with [/QUOTE]
Are you sure? I have often taken a PS TIFF into PI for DBE and then back again with no issues. PS may not like 32 bit TIFFs and many tool menu items will be greyed out if you are using a 32 bit TIFF.
I am using PS CC 2015 and the latest updated PI.
Impressive example of PI superior registration tools there Rick. I have occasionally (rarely really) had something like that happen where a red or green master does not align properly. Its an image wrecker.
That's the problem - figuring out HOW to make the scaled image and be readily readable elsewhere is an issue with PI
No, it's an issue with file formats like TIFF and FITS that have lots of options and programs which sometimes break the rules. PI takes the approach of offering you the ability to tweak every available parameter. This adds complexity but also functionality.
Here's an example: the FITS format doesn't specify the valid range of floating point data values. PI assumes it is 0..1. CCDStack assumes it is 0..65536. Neither option is more correct than the other. PI gives you the option to read and write CCDStack compatible FITS files but you have to know what you are doing. CCDStack can only read and write its own format.
I know which behaviour and philosophy I prefer. You may prefer something different. That's cool and why there are different products successfully competing in the same niche. I don't know why we have to waste time arguing about whether strawberry is better than chocolate
Quote:
Originally Posted by LewisM
I think PI assumes the user has a PHD in Pixel Math
Yes, and I think it is a deliberate choice on the part of the developers. It isn't possible to build a product that everybody will find intuitive, so they've identified their target audience (which is geeks like them) and they cater for that audience very well. Others not so much
Some people love PI, some suffer it reluctantly and some just find it unusable. IMHO, this doesn't reflect a major deficiency in PI itself. It's not intended to appeal to everyone and I'm not offended if someone dislikes it.
However, I do find folks that clutter threads with off topic "I didn't like it so it must suck" comments tiresome. Perhaps we need an official PI hate thread (and a Windows hate thread and a Mac hate thread and...)
It looks like when optics are not fully corrected and thus subs are affected by optical aberrations, PI's star registration with distortion correction appears to be a tool of choice, as it seems to attempt to locally adapt registration to account for various degrees of star distortions across the entire image.
Maybe for the benefit of all, we could create a list of other platforms that can do a similar type of registration (not simply rotating/shifting/uniformly scaling the entire image)
Maybe for the benefit of all, we could create a list of other platforms that can do a similar type of registration (not simply rotating/shifting/uniformly scaling the entire image)
Registar can deal with geometric distortions. And I see that after 11 years there was finally an update to it earlier this year! Must see if I get a free download. Looks like it still only works with 8 and 16 bit data though.
Apologies as this is OT. But, as I try to adjust to the Pix world I do find "comfort" in being able to retreat sometimes to the program I know (or think I know) better. Would you please explain how to write a fits file in Pix that can be understood by CCDStack. Much appreciated!
Apologies as this is OT. But, as I try to adjust to the Pix world I do find "comfort" in being able to retreat sometimes to the program I know (or think I know) better. Would you please explain how to write a fits file in Pix that can be understood by CCDStack. Much appreciated!
Peter
I know that when I want to open something in MaxIM DL from PixInsight I just save it as a 16-bit unsigned integer.
Apologies as this is OT. But, as I try to adjust to the Pix world I do find "comfort" in being able to retreat sometimes to the program I know (or think I know) better. Would you please explain how to write a fits file in Pix that can be understood by CCDStack. Much appreciated!
Peter
My bad, Peter. There are a couple of options for reading foreign floating point FITS files (Format Explorer>FITS>Edit Preferences or input hints "low-range" and "upper-range") but no ability to write them yet. A 32-bit integer FITS file would be the best interchange format. As Colin mentioned, a 16-bit integer file would also work if the dynamic range of the data is small enough.