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 - Greg Schwimer

Pages: [1] 2 3 ... 13
Bug Reports / Re: HDRMT does not change image
« on: 2019 June 14 19:19:00 »
Ah, I see. Makes sense. Thanks much for having a look!


Good information. This has me wondering - will running PCC a second time end up with the same correct result as if it was run with adequate stars the first time. Put another way, is the result of the second PCC run influenced at all by the first run? I'm thinking not but it would be good to understand.

- Greg

Bug Reports / Re: HDRMT does not change image
« on: 2019 June 14 08:46:57 »
Hi Juan,

Thanks for taking a look at this. Here is a sample image:

For HDRMT settings, I reset to default, enable "median transform". The rest is at defaults.

I ran a few scenarios and may have found something interesting. These are relative to the example I posted above (see attached for preview sizes):

 - Applying to full image - NO CHANGE
 - Applying to small preview #1 - WORKS
 - Applying to medium preview #1 - WORKS
 - Applying to large preview #3 - NO CHANGE
 - Applying to full-size preview - NO CHANGE

Noting that the problem seems to occur with the larger sized images, I cloned the full size image and resampled it to 50%. In this case HDRMT WORKS.

Everything works with median transform disabled, no matter the image size.

I ran these tests on Linux, build 1475. I saw similar behavior on OSX build 1457 as well, but didn't get to running this particular flow of tests.

- Greg

Bug Reports / HDRMT does not change image
« on: 2019 June 13 22:02:22 »
Saw this post:

I'm having the same problem. I can reproduce it on both OSX build 1456 and Linux build 1475. The key to reproducing it seems to be to enable median transform in HDRMT.

Update: The problem seems to occur with mono images. It otherwise operates on RGB and such.

Image Processing Challenges / Re: hdrmt not working
« on: 2019 June 13 21:53:36 »
Seems to be related to Median Transform. Try unchecking that and running it again.

Also, try running it on a multichannel image (RGB, SHO, etc). It seems to work on those.

I opened a bug thread on this.

Image Processing Challenges / Re: hdrmt
« on: 2019 June 13 21:29:35 »
Funny - I just ran into this same thing. This is with the build 1475 on Linux. I've yet to troubleshoot it.

Update: Same thing on OSX build 1457. (number not transposed).

You can solve the green problem by using SCNR at default settings while still linear.

Image Processing Challenges / Re: Flats Correction on M81
« on: 2019 June 13 11:34:23 »
I'm happy to help. Astrophotography is indeed a journey and the learning curve is always present.

Dark optimization usually "just works" but sometimes it doesn't as you're finding. The best solution is to use exposure and temperature matched darks so you don't even need it. Looking at the fits headers it seems that you have this. If you're seen a noise difference between when it is used and not used it may need adjustment. In this case you'll need to try adjusting the settings in ImageCalibration re: dark optimization. I've not done this before - perhaps someone else has something to add on this point.

Before you mess with those settings you can try calibrating the flats w/ just the bias or use darks specific to the flats to match temp/exposure. If the flats are short enough using a master bias to calibrate them may be all you need. It depends on the camera. I'd say give it a try and see what you get.

You might also try using the CosmeticCorrection tool with a master dark as a reference. This will help clean up lots of things in the lights like hot/cold pixels and bad columns/rows. I do see some dark columns in your lights so it may be worth investigating this as a part of your process.

I've had raised donuts myself. Unfortunately not the tasty kind. ;)   In most cases this is caused by a shift in the projection of the dust on the sensor, whether by just movement of the dust, inaccuracies in the filter wheel, rotator, difference in focus, etc. The CloneStamp tool may come in handy here. Some people use clever formulae in PixelMath.

Share the final when you're happy with it!

- Greg

Image Processing Challenges / Re: Flats Correction on M81
« on: 2019 June 12 14:04:02 »
Hi Matthew,

I've seen the "inverted flats" look before, usually when something goes wrong with the darks during calibration.

In taking a look at your data I found a few things of interest:

 - the binning between your L flats and lights is different. These will need to be the same geometry in order to work. You *could* fudge it and up/down scale if you wanted but to get the best outcome they should be the same.

 - Your darks appear to have an object in them at the center (possibly M81 core?). I would think maybe this is RBI ghosting, but blinking through them the object moves, almost as if it is dithered. How did you capture them? I'm curious if your camera uses an electronic shutter?

 - Your bias master does not have this ghosting so that's good

 - I ran everything through BatchPreProcessing (BPP) using defaults and got a similar result to you.

 - Ran BPP again without the master bias - same result

 - Ran BPP again with 'Optimze dark frames' disabled <- this seems to fix your problem

So, give the calibration routine you're following at try with dark optimization disabled and see how that works for you. If dark optimzation doesn't work for you maybe consider building a master dark library for each temp/exposure you might image at.

Result below (RGB only).

- Greg

Image Processing Challenges / Re: Image Distortion
« on: 2019 May 25 23:59:00 »
Hi Mike,

I don't really have an answer but am curious as to what optics you are using.

Are you able to share the raw frames? That will help others see if they can find a way to align it.

Image Processing Challenges / Re: Strange background noise
« on: 2019 May 08 07:49:34 »
This is likely due to not dithering or inadequate dithering. I think it is called walking noise. If you blink through the images in the sequence they were taken do you see evidence of drift in the direction of the noise?

I must be missing something. Below are two screen captures:

 - Using the settings Mike did with ImageSolve script. It fails every time.
 - Using the same settings with "Show Stars" checked under Advanced settings in ImageSolve. On the left is the screen shot from the first post, on right is the xisf file.

In the case of the show stars output, the difference is interesting.

Mike - you adjusted the pixel size to 5 in ImageSolver and it worked? I get a fail using that. It's saying it only found 2 stars. Were there any other changes?

Hmm. I can't use ImageSolver on that image - same result. Yet, I can solve it in TheSkyX using AllSky:

Center RA (2000.0): 12h 36m 20.58s
Center Dec (2000.0): +25° 59' 33.8"
Scale: 1.33 arcseconds/pixel
Size (pixels): 765 x 510
Angular Size: 0° 16' 57" x 0° 11' 18"
Position Angle: 183° 10' from north through east
Mirror Image: No
RMS: 1.01 (X: 0.79 Y: 0.63)
Number of Stars Used in Solution: 21 (100%)
FWHM: 2.87 pixels, 3.82 arcseconds

1.33 seems pretty close to what you should get with a f/l of 1370 w/ 9um pixels.

I'm not sure what to say. Probably some tweaking is in order.

OK, sometimes I read to fast. Apologies - I missed the xisf file you linked too above.

Interesting! PCC does not work on the .xisf file, but it *does* work on the screen capture you provided above. Same settings for both (defaults).

Looking at the logs there are clearly differences in what is going on with each. I'm afraid I don't have a quick fix for you.

By the way, I noticed your xisf file has no fits header info that I can see. Maybe there's something off about the file?

Log files are attached for each attempt.

Pages: [1] 2 3 ... 13