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 - pfile

Pages: [1] 2 3 ... 265
1
did you have dark optimization turned on during calibration?

that can sometimes cause hot pixels to be overcorrected and leave you with these black pixels.

rob

2
General / Re: Introduced lines into debayered images.
« on: 2019 February 19 15:47:28 »
well, this shouldn't happen obviously. maybe the CC step has somehow messed up the images. worth omitting that to see what happens.

rob

3
General / Re: Introduced lines into debayered images.
« on: 2019 February 19 09:32:00 »
going to guess that these were registered and stacked and then debayered?

debayering needs to happen to each sub prior to registration.

rob

4
Bug Reports / Re: macosx file opening / searching problems
« on: 2019 February 18 20:36:18 »
so following up on this - i think it's likely to be just a bug in at least High Sierra's handling of spotlight on remote-mounted AFP volumes.

in the past i had found that just turning indexing on was not enough to keep the OS interested in updating the spotlight data of newly created files. i know apple have been adding more and more sophisticated file modification notification stuff to the kernel and i guess it's just broken for remote volumes. in order to keep the database up to date i've had to manually import my newly created subs every night.

just now i rebooted my machine to apply security updates and PI could not find any files on the remote volume; despite mdctl reporting that indexing was turned on for the volume, it apparently was not; doing mdctl -i on . at the root of the shared volume caused a flurry of activity and after a few minutes, PI was able to find files on the remote volume again. so it looks like the indexing state and/or index itself does not survive a reboot for remotely mounted volumes.

rob

5
General / Re: Stack RGB of moon
« on: 2019 February 18 17:21:57 »
the FFTRegistration script might be able to align them for you. just make sure to tell it to write out the registered images to disk so you can re-open them and do the RGB combine.

rob

6
General / Re: Introduced lines into debayered images.
« on: 2019 February 16 22:41:23 »
i think you need to stretch those and re-post them because they are so dark i can't see any of the artifacts you're talking about...

rob

7
Wish List / Re: Noise reduction like this would be nice!!!
« on: 2019 February 16 10:12:22 »
i mean??? ML/neural net algorithms are a hot topic and i don't really see why something new should not be considered for implementation in PI.

having said that these algorithms can be incredibly compute-intensive and most of them want to run on a graphics card, so that would be a new direction for PI.

rob

8
General / Re: Parameters of PSF functions in aperture photometry
« on: 2019 February 14 10:35:36 »
the source code for AperturePhotometry indicates that Moffat4 is the PSF fitting function used, as far as i can tell.

since it is hardcoded into the script, it would take a bit of work to make the function user selectable. not impossible, but it's probably something you'd have to try on your own and then submit to Juan and/or Andres del Pozo as an update. unless Andres is willing to implement this feature request.

rob

9
Bug Reports / Re: Crashing since Mojave update
« on: 2019 February 13 21:31:14 »
the only other mac crash i can think of (with the new version anyway) were those caused by bad thermal management, but that seems to plague only the 2018 MBPs as far as we've seen here.

hopefully the GPU switching thing fixes it...

rob

10
Bug Reports / Re: Crashing since Mojave update
« on: 2019 February 13 14:22:05 »
strange - i'm still running high sierra and am not having any problems.

what kind of mac is your machine? what kind of graphics?

rob

11
General / Re: Fix debayered saturated stars?
« on: 2019 February 13 09:56:24 »
i stopped processing OSC regularly images a long time ago, but i kind of hit this problem when working on DSLR images from the 2017 eclipse.

i wonder if all of this gets easier if you use Rescale to 'expand' the image so that the things that are saturated at 0.25 get remapped to 1.0. that way you don't have this funky "saturated but not saturated" data in your linear master. doing this may cause the repairHSV script to work a little better.

as to your actual question though, i think it is somewhat difficult. morphological transformation sort of does what you are asking about based on the mode, but i think you'd have to do a lot of masking and/or working on a duplicate image and then only copy back the pixels that correspond to the saturated pixels in the original image. not super helpful, sorry.

rob

12
General / Re: Debayered files suddenly deep red
« on: 2019 February 12 10:12:09 »
did you happen to change capture software or versions of capture software? the images do seem to be biased red after ABE (which approximates a background neutralization.)

one problem with the FITS format is that the 0th byte in the file does not map unambiguously to a particular corner of the image. for this reason the PI fits reader has the "up-bottom" and "bottom-up" settings. when dealing with color sensors, if the writer and reader directions are mismatched, the bayer matrix order changes from what the sensor manufacturer says the bayer pattern is.

so, you can either experiment with different debayer matrix patterns, or you can keep the same pattern you were using and try reversing the PI fits reader direction, and see if you get the expected resultas. as dhb2206 says almost every color camera has 2 green pixels in each bayer matrix, which for a variety of reasons usually gives you a green cast in your images.

rob

13
you can do this, though i think in the past juan has warned that L extraction from an RGB image is by default a "perceptual" L, meaning the channels have been weighted before summing into an L image to match the perception of the human eye. that is, green is over-weighted.

if i remember correctly, you need to set the RGBWS (RGB working space) luminance coefficents on the RGB image to 1,1,1 and set the gamma to 1.0 using the RGBWorkingSpace process before extracting L*. you should then undo the RGBWorkingSpace process on the RGB image and proceed from there (or just make a clone of the RGB that you modify the working space on, then extract L* from that.)

maybe others remember better. there might be a subtle difference between CIE L and L* here that i have forgotten.

rob

14
General / Re: DrizzleIntegration using the wrong source images?
« on: 2019 February 11 19:34:10 »
well i can think of two ways out of this:

first is that since you only have one image with the satellite, rather than trying to repair it, just overwrite the streak with 1.0 or 0.0 and then it can be very easily rejected by the normal pixel rejection techniques. the SNR under the streak will be a tad lower, but maybe not perceptible.

the other way would be to do exactly what you are doing, but register one of the good images to the bad image to use as source material for the streak. then just throw away the registered one, and start the whole process from there, as though your bad image was clean to begin with.

rob

15
General / Re: Apparent Image grid
« on: 2019 February 11 17:21:48 »
if this happens with mono images then it is likely a calibration problem - the sky background is so weak in a narrowband image, that dark subtraction sometimes leaves negative values (which get clamped to 0) in the calibrated frames.

you can try adding a pedestal of like 100DN in ImageCalibration and the problem should resolve itself.

rob

Pages: [1] 2 3 ... 265