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 ... 14
1
Update installed and fix is confirmed. Thanks for the speedy response on this!

- Greg

2
Running 1.8.7 on both OSX and Linux (mint). I'm seeing that the statistics process misreads an image cropped with dynamic crop. I can reproduce this across my two systems, but not on a 3rd system running previous build 1457 on OSX.

Steps to reproduce:

 - open an image - I'm using a dark sub
 - open statistics, select the check at the lower right - things look OK
 - crop the image - I use dynamic crop, reset the settings, set a width, height of 100,100 and apply with the check
 - statistics show the count of the pixels count unchanged (should be 10000). Pixel % changes to an unlikely number.
 - none of the other statistics change as you might expect
 - open pixelmath, select "create new image", and use $T as the expression to copy the above cropped pixels to a new image
 - statistics for the new image appear to be correct

Closing and re-opening the statistics process does not fix this. Saving the cropped original and re-opening it does.

Anyone else see this?

3
Further searching reveals this thread:

https://www.cloudynights.com/topic/562025-pixinsight-integration-and-pedestal/

So it appears this may be a known issue in cases where the PEDESTAL keyword is negative.

4
Kind of a guy check request here and maybe a discussion for adding this feature to BPP.

When creating a master bias or dark with BPP with frames that all have the PEDESTAL keyword, the master frames are saved without carrying forward the PEDESTAL value to the created files.  Use of these masters results in misapplication of them against light frames due to the missing PEDESTAL keywords. In my case this was causing overcorrection of flats against the lights.

I solved the problem by adding the keywords into the BPP created bias and dark masters.

Anyone else run into this?

Perhaps a future update of BPP can carry forward the PEDESTAL values from the subs and be added to the resulting masters?

5
Image Processing Challenges / Re: Non Linear PostProcessing
« on: 2019 August 13 13:53:33 »
Hi Marc,

Results seem similar. I went ahead and ran through it again, this time pushing the color and contrast a bit more in a similar way to how I did it previously. It's possible this is just how your camera presents the data and that's not a bad thing. From there it's mostly art. Someone else may indeed have a different spin on it than me.

The data does look pretty good overall. One think I noticed is some artifacts from satellites or similar radiating from the upper left corner. That can be fixed during integration or just by leaving the subs contributing the artifacts out altogether.

I added a process container below showing how I went about it. You can unzip it and load it into PI and run the individual processes to see what I did. For the masks I used the color mask script and an L mask which I created by extracting the L channel. The ~ before the mask in the process container means the mask was inverted when I applied the process. Explaining just in case and for others that are learning.

Le Tour was interesting this year. Alaphillipe was so close...

- Greg

6
Image Processing Challenges / Re: Non Linear PostProcessing
« on: 2019 August 13 11:25:04 »
What I'm mean is that the channels all seem fairly equal, so the color is coming across as mostly greys. It's possible I got to this result because I ran PCC over the top of what you already did but I don't think that's really it. Could be the nature of your camera, could just be that region looks that way. Could be I would get a different result if I had the unprocessed master. Hard to say. If you want to put a copy of that (from right after integration w/ no other changes) I'm happy to take a peek.

When I adjusted it I was going for the typical "milky way" look of reddish brown. To get this I found the best result by using a red mask (color mask script) and reducing the greens and blues ever so slightly.

Believe it or not I haven't imaged that area so I can't say for sure what it would look like with my camera.

7
Image Processing Challenges / Re: Non Linear PostProcessing
« on: 2019 August 12 16:40:48 »
Hi Marc,

I took a quick look. Seems that you had already run photometric color calibration on the image, but possibly without background neutralization enabled. Step back and give it a try with that enabled. Without it, on my screen the initial screen stretch (linked) has a magenta cast. I ran PCC again with background neutralization and that helped. Next I ran SCNR with the defaults to clean up the green.

Taking through an STF_based stretch and then pushing the saturation with curves I don't see a lot going on in terms of color. I attempted to draw some color out using the Color Mask script (under utilities) to create a red mask. I applied this mask, inverted it, and used CurvesTransformation to reduc the green and blue channels slightly, then worked the contrast a little. The caveat with this approach is that the stars are also going to have this applied, which you may not want. You can get around that by adjusting the mask to protect the stars, etc.

Results are below. The version on the left is post stretch with none of the curves work I mentioned.


8
Image Processing Challenges / Re: Western Veil Nebula Challenge
« on: 2019 August 06 21:36:27 »
I did a quick run through:

https://youtu.be/Vp9mwTPrlCs

Short version:

  - needs better focus
  - dithering would help a lot
  - get better at calibration to remove artifacts like hot pixels
  - don't oversaturate anything if you can help it, or build an HDR strategy

- Greg

9
Excellent! I'm glad we figured that out.

10
When I took my darks and bias frames I did not use the Ha filter because I didn't think it would matter since it was a "dark".

This is true.

Quote
However, I just hooked my computer up to my rig and this time set the Ha filter and took some bias and dark frames.  The median value came down to 200 from the 750 range which puts it lower than the light frames.

Verify all of the settings are the same as before the filter change. Also, if your camera does not have a physical shutter I'm guessing this could impact it. Not sure though.

Quote
My offset may have been set differently by mistake. It may have been at 15 for my lights and then 50 for my original darks and bias. It should have been at 50 for my lights. Does the offset have to be the same for darks, bias and lights?

I'm not sure. I don't know the details of how your camera works but I think you may be on to solving the problem. For calibration frames to do the best job they must accurately match the light frames. That is, all camera settings (binning, exposure, temperature, etc, etc) should be identical. This is the same as with a DSLR - if you change ISO, you need new calibration frames. An allowable difference may be with darks where they can be scaled from different exposures, but that doesn't always work as well as the "real thing".


11
I'm happy to help. I used pixelmath as a quick way to try out calibrating with the dark & bias. Normally you'd just use the usual suspects to get the job done. I checked the median values with Statistics.

I don't think there is a way to add a pedestal in BatchPreProcessing but maybe its hidden somewhere in the settings. You can do it using the ImageCalibration tool by adjusting the output pedestal. I've not used it myself but it may do the trick for you.

As to the dark and bias frame median being higher than the light frame, normally I'd expect to see a light frame median that is at least a little bit higher than an uncalibrated dark, as the light frame would contain the bias signal, the dark signal, plus the background of the image. In narrowband it can be less of a difference than LRGB due to the lower amount of background light getting through.

The difference I see in your frames makes me think maybe something changed with the camera settings between capturing the bias & dark and the actual light frame exposure, or the lights were already calibrated possibly. At least it begs the question why a dark or bias frame w/ no light might be brighter than a frame that was exposed to light.

12
Hi Pat,

I didn't do a deep analysis but I did notice that both your master bias and master dark have a higher median signal than the light frame I looked at:

Using 16-bit counters:

  Bias median: 772.230
  Dark median: 821.895
  Light median: 368.0

My guess is this explains your problem. Did you use a different setting on the camera for these lights relative to what you captured the dark and bias with?

You can add a pedestal to increase the median of the light frames so you don't end up with pixels with negative values. I tried 0.02 and ran pixelmath to remove the dark and bias signals. Looks pretty good.

How I did this with pixelmath (EDITED FOR ORDER):

Add pedestal to light: $T + 0.02
Remove bias from dark: $T - bias
Remove bias from light: $T - bias
Remove dark from light: $T - dark

I'd find out why the values are less than the bias and dark. They should be *at least* as bright, and ideally a bit brighter so you overcome the noise in the frames.

 -Greg


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!

14
Juan,

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

15
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:

https://www.dropbox.com/s/rg4222co1nhw6ak/example.xisf?dl=0

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

Pages: [1] 2 3 ... 14