Paul,

Just a quick note saying after a week using 1.3.4 and 3 days using 2.0.0 I am seeking alot of crash reports.

Basically I am opening 10 raw images, dark subtracting and I have added Stars used, Collimation and Curvature to the columns in the main menu view. When I press the measure all - its processes for about 10 secs - asks for the pixel size (I enter 0.645) then after 10 secs more it stops responding and a crash report screen comes up.

If I take the dark subtract off it normally works. If it still crashes I take off the col and curve fields.

* * * Just downloaded 2.0.1 - no crash on the above error on a Quad Core 2 GB RAM desktop, but

Secondly if I load nine images - say shots of 47 Tuc RAW images of duration in seconds 1, 2, 4, 8, 16, 32, 64, 128, 256 and one by one select them and look at the curvature maps the FWHM and TILT the numbers on the curvature viewer screen they go off the screen - they are like over 60 digits long (buffer overrun?)



I select the 1 second image of 47 Tuc select Analysis - Curvature Map. The screen shots show a white centre to the second ring around the cross hairs a small fringe of aqua, a ring of light blue then all dark blue with numbers:

Min FWHM: 79942794381896397000000000000000000000000000000000000000000000000000000
Max FWHM: 961040492835404600000000000000000000000000000000000000000000000000000
Curvature 12.6%
Tilt in X: +159856184333696660000000000000000000000000000000000000000
Tilt in Y: +309216455559067350000000000000000000000000000000000000000000000000000000000
Total Tilt: 0%
Collimation: 0.0"
Stars Used: 3275

Which is distracting!

Third issue - Tilt amount and direction on curvature map varies wildly on short consecutive shots of same target.

I do the same for first the 2 second, then the four second shot and then the 8 second shot - all nine shots where done consecutively in my astrolab over the course of a few minutes on a dark, still night.

On the 2 second shot the Collimation is a huge number, Curvature is 20.2% and Total tilt reads 2% @ 41 degrees, but on the 4 second shot it reads 7% @ 111 degrees, curvature is 30.5%! Try the same with the 8 second shot, Curvature 41.3%, total Tilt 1% @139 degrees

The processed shots look great - excellent focus, pin point stars (FWHM around 1.24") flat field, no coma).

If it helps my gear is a C9.25 on Losmandy Dovetails, Vixen Atlux mount on a large permanent pier, with a Meade motor focuser, starlight feather touch 10:1 micro focuser, Lumicon OAG into a Canon 400D


But even with these errata I am learning and seeing the power of this piece of software. Help this feedback helps - happy to be more specific on what it takes to cause a crash if you need it!

Matthew

This message has been edited. Last edited by: g__day,

Hi Matthew,

2.0.1 fixed a crash caused by stars overlapping the image frame.

Try setting Settings->Noise Threshold to medium or high. The reason is that DSLR frames are much noisier than CCD and CCDInspector can get overwhelmed by too many noise clusters looking like stars. As the result, you are probably measuring noise distribution in the image instead of actual stars, with obviously incorrect results.


Let me know how it goes. If you find that this doesn't help, email me an image that produces this type of huge numbers, and I'll check into it: paul [at] pk.darkhorizons.org

Regards,

-Paul

This message has been edited. Last edited by: Paul Kanevsky,

Paul,

Thanks - I realised that 47 Tuc may be confusing things. Setting the thresholds high didn't change results so happy to mail you the file.

Can that address handle one 9.8MB CR2 file (RAW image) or should I reduce it, see that it still produces the error - then e-mail send that file to you? I have Photoshop CS2 - so can manipulate the image into pretty much any format and size you'd find easiest to use.

Thanks,

Matthew

Matthew,

Go ahead and email the file. You can winzip it, if connection speed is a problem. Send the original raw image, don't process it in PS, as that will change the characteristics of the image.

One more thought: did you set a default pixel scale for your image? Go to Settings->Default Image Properties and set the imager scale to a reasonable value. I've had previous reports where this was set to an incorrect value and caused the measurements to appear huge.

Alternatively, turn off the "In Arcsecs" setting on the main screen of CCDI and see if the numbers still come out this large.

Regards,

-Paul

I just compressed it to a 370kb tif lzv compression - opened okay - you still see the large numbers - so I can send that easily - if you like can send either or both in the next few minutes.

Matt

PS

Yes Pixel size was 0.645 - came from PEMPRO v2 the other night- measuring a 20 second star trail with the RA motor halted.

PPS

Image on its way to you - erg No - mail server says its too big to send as a single e-mail (I guess a 8.7 mb file gets mime encoded above a 10mb server limit).

erg - compressed it to a LVW tif - 2mb is the size now - hopefully this will get thru!

This message has been edited. Last edited by: g__day,

Matthew,

I sent you a private email, but also want to follow it up here for the benefit of others.

1. For proper measurement, pick well-populated star fields, not globulars. Your image contains a lot of stars in the center of the image, all very close to each other, and nearly no stars in the other 75% of the image. That's a really bad star distribution for CCDI to measure curvature from, and it will display a warning to this effect.

2. The issue with the large numbers was caused by the TIFF reader finding (incorrectly) meta-data information in the image that it then used as the image scale. With build 2.0.1, you can turn off the In Arcsecs setting to see the correct values expressed in pixels, or wait for the next maintenance release, 2.0.2, that will have safeguards put in to ignore bad scale values from TIFF images and use the default image scale instead.

Regards,

-Paul

Paul,

Thanks - do you think that a better selection of CCDI target will also address the tilt direction and total % tilt switching around wildly - or is that a different issue to consider based on Tuc 47 being a poor target to begin with?

Matthew

This message has been edited. Last edited by: g__day,

47_Tuc_064_secs_PS6_small.jpg (124 Kb, 8 downloads)

Hi Matthew,

Yes, a better target will produce a more repeatable result. Note that at your image scale, a 7% tilt is equivalent to a difference in FWHM of just 0.1 of a pixel across the whole image frame (equivalent to 0.6 micron).

That's well below noise level caused by tracking, seeing, and readout noise in a DSLR. For all practical purposes, this tilt is not visible, and will not be the cause of any issues in the resulting image.

Regards,

-Paul

Paul,

Delighted - you're a champion!

Matthew