Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - jeffweiss9

Pages: [1] 2 3 ... 22
Just to increase the statistics, I am also getting this occasionally on Windows 10 which is a new installation from March this year.

Bug Reports / Re: Star Alignment Bug?
« on: 2018 March 31 13:40:49 »
Thanks, Mike-
I did have all my astro image  files on a second internal J: drive that survived the computer crash.  But shifting to my laptop and backup drive, I couldn't maintain the same structure if I had wanted to, I don't believe.  My new computer will have a similar second drive which I also will name J:,  where I will continue to keep all my astro image data on a separate drive.  I should be back to the original directory locations for both new (ML16200) and old (ML8300) files.  So I think in the future, once this is setup, I'll only have to change the Star Alignment /Star Matching option  from the default "pentagons" to "triangle similarity" in order to handle the mirror problem and process them together without further problems.  Yeah.   

Bug Reports / Re: Star Alignment Bug?
« on: 2018 March 30 09:58:23 »
    That worked great on my laptop with Replace-All in Wordpad done on each of the 52 Lum .xdrz files! DrizzleIntegration happily ran.  A little tedius and now onto the R,G,B and Ha files but it did save the situation.   

    With my new desktop computer and different disk drives, I'm going to face this again every time that I try to process a new image and want to combine it with old data that I have on the same image.  Since I'm sure I'm not the only person with disk crashes or who wants to occasionally combine with old recovered data, I still think it would be better if PixInsight offered a Browse option every time it can't find a file its looking for so the user could enter the new location just once (until the next unfound file).

Thanks all.

Bug Reports / Re: Star Alignment Bug?
« on: 2018 March 29 07:02:56 »
Great idea.  I didn't realize they were just text files.  Thanks.

Bug Reports / Re: Star Alignment Bug?
« on: 2018 March 28 21:58:01 »
     Thanks. I got excited because that seemed to be the answer, except it only allows entry of one directory.  In combining old and new data from different cameras (that I expect to be doing a lot which is why I need to keep persisting to make this work), the c_cc.xisf files and  .xdrz files are scattered over 4 different directories on 2 different disk drives.  This would be a drag to have to copy them all into one directory some place just to make Drizzle Integration work.
     Like many other programs, PI should just give you a Browse option any time that it can't find files so you can fill in where to find those particular files until it can't find some other files, etc.   

Bug Reports / Re: Star Alignment Bug?
« on: 2018 March 28 07:17:44 »
Yes, I regenerated the .xdrz files but they are in a different location from the original c_cc.xisf files.

Bug Reports / Re: Star Alignment Bug?
« on: 2018 March 27 22:10:43 »
Thanks.  That makes sense. But then my actual problem then is that PI 1.8.05 is asking for the cc.c.xisf files on the wrong disk drive because they are no longer on the drive where they were created - since it crashed.  PI doesn't seem to offer the user to browse to find those original files.    This is all part of this problem of reregistering old files from one camera to another reference from a new camera.  I think PI should offer a browse option if it doesn't find the files it is looking for where they were when the files were generated in 2015.  With the help of folks above, I have reregistered with StarAlignment the original cc.c.xisf files (now on a different drive) to the new reference and successfully processed through Integration.  It is only this last step of DrizzleIntegration that I haven't overcome.

Bug Reports / Re: Star Alignment Bug?
« on: 2018 March 27 12:48:19 »
Any suggestions on why DizzleIntegration is asking for unregistered cc_c.xisf files instead of registered cc_c_r.xisf files?
This is happening in trying to combine the old ML8300 images with the new ML16200 images.  Standard Integration worked fine, only DrizzleIntegration is doing this.

Bug Reports / Re: Star Alignment Bug?
« on: 2018 March 18 21:48:53 »
Hi Jeff,

Your 2) and 3) images are horizontally mirrored with respect to 1). This is not supported by the default star matching device used by StarAlignment, which is based on polygon descriptors. To align these files:

- Open the StarAlignment tool.

- Open the Star Matching section.

- Select triangle similarity as the descriptor type parameter. Please read the tool tip information given for this parameter, where you'll find detailed information.

The BatchPreprocessing script forces triangle similarity by default to ensure that these problems are always avoided. However, polygon descriptors are used by default in SA because they are much better in terms of distortion modeling and robustness under difficult conditions. Their lack of support for mirrored images is of marginal importance in most practical applications.

Besides these restrictions, I see no bug in the StarAlignment process that can be identified with these images.

Juan-         REVISED
   Thanks very much.  Finally was able to get back to this. You are indeed correct that changing the default 'pentagon' descriptor to 'triangle similarity' enabled StarAlignment to handle the horizontal mirroring of my old images just fine.   That is not any bug.

   However, going beyond StarAlignment, Local Normalization and ImageIntegration, I find that DrizzleIntegration then has some kind of quirky behavior.  For some reason, DrizzleIntegration wants to use the unregistered c_cc.xisf files rather than (or in addition to?) the c_cc_r.xisf files. This seems strange to me because I can't understand why it is trying to integrate unregistered files.  That doesn't sound correct.
   To compound the problem,  it is asking for c_cc.xisf files on the wrong disk (from an old machine as this work had to be spread across two machines), while the correct c_cc.xisf files (still unregistered) are found in the same directory as the c_cc_r.xisf and c_cc_r.drz files.  I have no idea where the memory of the original disk drive (written by BatchPreProcessing script) is coming from (couldn't find it in the headers).  Is it correct that DrizzleIntegration needs the unregistered c_cc files for something and, if so, is there any way that I can specify the drive and directory where they are found -- replacing the wrong locations that DrizzleIntegration is coming up with? 

Bug Reports / Re: Star Alignment Bug?
« on: 2018 February 26 21:56:42 »
Thanks, Rob, Bernd-

I've uploaded the three files listed previously to Google Mydrive with the links indicated here:

1) the new reference image:  ...45_c_cc_r.xisf

2) an old raw FITS file:

3) image 2) after its original calibration and cosmetic correction:  ...048_c_cc.xisf

No, I have checked that the old camera's FITS [file 2) above] and the old calibrated c_cc.xisf file are not mirrored but the same orientation.

Be good to know if this behavior is reproducible; i.e., that with File 1) as Reference in StarAlignment,  the FITS file 2) will register correctly, but the calibrated file 3) is vertically mirrored.


Actually, having uploaded these files, I retested and find a different behavior.  StarAlignment now simply fails with BOTH files 2) and 3), but works correctly if I apply a horizontal mirror to both files 2) and 3) before running StarAlignment.   I have no idea what changed but I still have a StarAlignment problem only now it is different than how it was described above. 

Bug Reports / Re: Star Alignment Bug?
« on: 2018 February 22 21:05:12 »
      Some further experimentation with StarAlignment showed that it works fine to register the old camera's raw FITS files to the new camera's reference c_cc_r.xisf file, but the vertical mirror reflection occurs when I use StarAlignment (same settings, doesn't matter if distortion correction or drizzle generation are on/off) on either the old or new camera's unregistered but calibrated c_cc.xisf files.  It seems that StarAlignment introduces this vertical mirror reflection whenever it tries to register c_cc.xisf files, in general, although it works fine on the same files when they are raw FITS.   

     The same thing happens when you try to register _c.xisf files so the conclusion seems to be that StarAlignment won't register the calibrated c.xisf frames, new or old without introducing the vertical mirror reflection, but does fine on the same images as uncalibrated FITS files, new or old.   This seems to be a bug in StarAlignment.

     I tried to attach 3 files to see if other people can reproduce this wierd behavior of StarAlignment but they are much too large to post:
1) the new reference image:  ...45_c_cc_r.xisf
2) an old raw FITS file:
3) image 2) after its original calibration and cosmetic correction:  ...048_c_cc.xisf


Bug Reports / Re: Star Alignment Bug?
« on: 2018 February 21 20:30:07 »
Back home and discovered that the old (ML8300) and new (ML16200) raw FITS images are related by a 180 degree rotation (= vertical mirror + horizontal mirror) to get the old FITS image to match the new FITS image (which matches the TSX star chart), not just a vertical mirror.  That leaves me further confused but I guess I can use a process container with the FastRotation process and an image container to reorient all the old FITS files (or maybe the _c_cc.xisf files, preferably).  Or I can just process the new data and composite the old and new finished images although that has got to be less optimal.  My confusion is: why didn't StarAlignment simply apply that same 180 deg rotation to the old images to match the new reference?  Instead it produced a set of images that still needed a vertical mirror to match the new images, so when the old and new images were stacked in ImageIntegration, the galaxy target (NGC2403) came out looking like a bow tie, instead of a galaxy.


Here is the actual text of the error report in the Process Console.  Drive D: is the backup drive; Drive J: is on the machine that was hosed (replacement coming).  The same c_cc.xisf files that it is asking for on Drive J: exist in a different directory on Drive D:.  I've looked at image headers and don't see anything containing information about drive J:

DrizzleIntegration: Global context

* Parsing drizzle data file 1 of 53:
D:/Vacation/New NGC2303/Batch/registered/Luminosity/ingc2403-Luminosity600.000secs-29.94C00000091_c_cc_r.xdrz
Reference dimensions : w=4500 h=3600 n=1
Input geometry       : x0=715 y0=660 w=3035 h=2370
Drizzle geometry     : x0=1430 y0=1320 w=6070 h=4740

D:/Vacation/New NGC2303/Normalized 031818/ingc2403-Luminosity600.000secs-29.94C00000091_c_cc_r.xnml
Loading image:
J:/ML16200/ngc2403/February 10 2018/Batch/calibrated/light/cosmetized/ingc2403-Luminosity600.000secs-29.94C00000091_c_cc.xisf
*** Error: J:/ML16200/ngc2403/February 10 2018/Batch/calibrated/light/cosmetized/ingc2403-Luminosity600.000secs-29.94C00000091_c_cc.xisf: No such file.

* Applying error policy: Continue on error.

General / Re: Documentation on Process Containers
« on: 2018 February 19 17:29:28 »
Fantastic.  That definitely will do the trick.  "FastRotation" didn't come up on the pull-down menu but it is in the Process Explorer. I guess most, if not all, PI actions are actually processes that can be automated way.  At least I'll eventually be trying that.

General / Re: Documentation on Process Containers
« on: 2018 February 19 15:35:38 »
Thanks, Mike, Bonzo-,
That looks really useful, although unfortunately I was looking to automate Image/Geometry/Vertical Mirror which is not, apparently an actual process.  I was going to try automating modification of 107 old images that need Vertical Mirror in order for Star Alignment to work properly on them so the registered images then match images from my newer camera.

Bug Reports / Re: Star Alignment Bug?
« on: 2018 February 19 15:15:57 »

I sold my old camera after buying the new one two years ago, but, as in this first try, occasionally I plan to use some of the old cameras "raw" data to improve SNR for a repeat target. I did use the old camera's data successfully once before, but in that case I just composited the galaxies in the old finished image with a wider-field view of the same galaxies in a finished image made with data from the new camera.


Pages: [1] 2 3 ... 22