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.


Topics - macnmotion

Pages: [1]
1
Hello,

For the first time, we're having trouble with flats. We recently tried using sky flats. We don't have a convenient way to shoot illuminated flats for our 600mm scope, so we thought we'd try sky flats. It isn't easy to capture sky flats at our location (13.7N), the sky brightness changes very quickly. We are able to capture 5 or 6 flats only in the 23000-30000 ADU range.

Our system:

OS RiLA 600mm f/5.0
FLI ML16200

I can't get the flats to work at all. On one previous image this season using the flats, I was able to add a .20 pedestal to the master flat and it worked well enough. But in our latest images the flats aren't working. In fact, playing with various pedestal values, I can reach a point where I have dust motes both over and under corrected at the same time.

I've placed a subset of our data online  (flats, bias, darks, L). Can anyone take a look and tell me if there is some technical problem with any of the calibration frames?

https://drive.google.com/drive/folders/1Ha59JOn_sZOV_mWcco32XYKi1OaRASdd?usp=sharing

Thanks. Andy

2
General / A few ProcessContainer and Scripting questions
« on: 2019 January 17 20:37:58 »
Hi. I'm trying to automate/simplify the following process.

1) I have an initial image open in PI workspace
2) Apply pixelmath to the original image - create result in new image
3) Change imageIdentifier of this new image
4) Save this new image to disk (ideally with the imageIdentifier name)
5) Close this new image

So far I have done this:

1) Process icon with PixelMath settings
2) Process icon with imageIdentifier settings

When I run the first process on the original file, it creates the new image and the new image is now the image window in focus. I can then run the second process on the new image. So far so good.

3) ProcessContainer containing the Pixelmath process and the imageIdentifier process

When I run the ProcessContainer on the original image, it creates a new image (PixelMath), but it doesn't switch focus to that new image. The imageIdentifier process is applied to the original image, not the new image.

4) I can not find any way to save a file automatically using the current imageIdentifier name.

Questions:

1) In the ProcessContainer, how can I switch focus to the new image before running the imageIdentifier process?
2) How can I save the new image as part of this automated process (using the imageIdentifier as the file name; saving in the same directory as the original image is fine)?
3) How can I close this image as part of this automated process?

Ultimately, I would daisy chain within the ProcessContainer so that I am running a series of incremental PixelMath instances on the original image, and saving each one so I can blink through the results later.

Any input would be appreciated. Thanks. Andy

3
Hi. We often shoot an object with more than one system, and that sometimes means with different cameras. For example on our 4-scope array, we have 2 PL16803 and 2 ML29050.

When it comes time to register the images, I'm wondering which camera to select the reference image from. Based on the following information, can anyone tell me how to make the best selection, resulting in the least loss of resolution?

First, here are the camera specs (the cameras are all on identical telescopes):

PL16803:
16 megapixels (4096x4096)
pixel size: 9 microns

ML29050:
29 megapixels (6644x4452)
pixel size: 5.5 microns

Here is a screenshot from SkyX showing the FOVs of the two cameras. As you can see, a portion of the 16803 will ultimately be lost.



I'd love to understand the calculations that would determine whether a sub from the 16803 or a sub from the 29050 is used as the reference image. Should the 29050 subs be downsampled to match the 16803? Or should the 16803 subs be upsampled to match the 29050? Upsampling may compromise resolution. Up until this point, I've been using a 29050 sub as the reference image, but without knowing if that has been the correct decision.

Thanks for any input. Andy

4
General / Background pattern cause?
« on: 2018 April 18 20:09:13 »
Hi. I'm trying to wrap my head around our larger scope as we finally have some images to process. The camera is an FLI ML16200.

The following is a stack of Ha, 110 6- minute subs which have been calibrated, aligned and integrated:



Here is the same image with a very quick ABE, which makes it much easier to see the background pattern:



Note tha pattern in the background. From noise? Chip pattern? Light pollution/sky noise?

Here is a stack from the same Ha images, calibrated but NOT aligned. I did this to see if I saw any type of chip pattern, but I don't really:



Any thoughts as to the source of this pattern? Thoughts on how to eliminate it during capture or processing? Note the subs are not dithered.

Thanks. Andy

5
General / Not sure how to explain this column defect
« on: 2018 April 13 22:50:00 »
Hi. Take a look at the following image. Top row Left to Right: Master L Flat, Master Dark (5 minutes), Super Bias. Bottom row: 5 Minute L sub.

Note the column defect in the flat. This appears on all flat subs, all filters, different nights. But no such defect on the L sub or on the dark/bias. Why would this only show on the Flat?

When I calibrate, the flat "removes" the defect from the raw subs, then I have to use cosmetic correction to fix the column in the calibrated subs.

Does anyone have any idea why this might happen only on the flats? Seems like it's causing me extra work in cosmetic correction, as well as damaging clean data.

Thanks. Andy


6
Hi, I'm having an issue with something that seemed pretty simple to me.

On our 4 scope array (4 matching 300mm telescopes), we have the following cameras:

Array 1 - FLI 29052
Array 2 - FLI 16803
Array 3 - FLI 16803
Array 4 - FLI 29052

All have Optec Gemini rotating focusers. In order to minimize loss of edges due to rotation mismatch, I thought we could measure the rotation required in PixInsight's StarAlignment process based on aligning an image from each of Arrays 2, 3 and 4 to an image from Array 1, and then rotate the focuser on each of Array 2, 3 and 4 the same value to counter the misalignment of the cameras. After doing this, I find that Array 4 is rotationally matched to Array 1. However when I counter the rotational values for Arrays 2 and 3, and take another series of test shots, Arrays 2 and 3 are not aligned with Array 1. In fact I see no correlation between the before and after rotation values reported by the StarAlignment process (i.e. I'm not missing a + or - sign in my offset value).

Is this because the sensor sizes and dimensions are different between the 29052 and 16803? Am I misinterpreting the rotation value reported by PixInsight when star aligning? Obviously something is wrong with my logic, I'm uncertain as to what it is.

If anyone has an idea of how to determine the correct rotational offset between Array 2 (or 3) and Array 1, I would appreciate it. Thanks.

Andy

Not sure if this info is necessary, but:

FLI PL16803 - 4096x4096 px - 36.9x36.9mm sensor - 9µ pixel size

FLI PL29052 - 6576x4384 px - 36.1x24.1mm sensor - 5.5µ pixel size


7
Hi.

On our 4-scope array, we have two 16803s and two 29052s. Last week we shot Monkey Head Nebula on the array. We shot Ha on scopes 1 and 2, which carry a 29052 and 16803 respectively.

Is there a way to use subframe selector to create weighting values across the entire range of Ha (across both cameras)? For example, could I note the highest/lowest FWHM, SNRWeight and Eccentricity values for each of the two sets, then use the highest and lowest values across both sets in my formulas for weighting each set?

If I weight each set independently using the same keyword, I'd be running the risk of lessening the value of an entire set if that set's images are all better than the other set, right? Do I have to forego subframe selector when integrating images from two different cameras? Should I run subframe selector after registration so that I can run all the Ha frames together? Not sure the hardware specs used in system parameters would work in that case, for example the camera gains of the two cameras are .32 (29050) vs 1.4 (16803), and the pixel size of the cameras is different (although perhaps after registration that would be moot if I use the subframe scale of the camera used with the registration reference image).

Any thoughts or ideas?

Thanks. Andy

8
Hi. I don't pretend to be a PI guru. However I put together a post outlining our workflow for processing M 101.

Most of the techniques I use come from other well-written tutorials online, and throughout my post I acknowledge and link to these sources. I'm sharing this so that anyone looking for another workflow example can consider this resource.

https://www.masterdarks.com/blogpost/processing-in-pixinsight-and-photoshop/

I hope someone finds it helpful. Let me know if you have any questions or comments. Thanks.

Andy

9
General / Having trouble with compound light pollution gradients
« on: 2018 January 19 23:42:00 »
Hello,

I've tried every variation of DBE I can think of to remove the light pollution gradients in an image of NGC 2683.

If anyone would like to try, I've placed the .xisf file here:

https://drive.google.com/drive/folders/1GTcInNs8NT5XejaR15gWoerNqkhkM312?usp=sharing

Any suggestions on how to approach these gradients would be appreciated. I'm attaching a screen shot of the L stack. Thanks.


Pages: [1]