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

Pages: [1] 2 3 ... 5
Gallery / Re: NGC 2403
« on: 2019 February 01 17:00:39 »
Beautiful processing Ron.

Gallery / Re: NGC-1333
« on: 2019 February 01 16:59:46 »
Hahaha, yes you're definitely at a disadvantage with 2 fewer mounts than scopes :-)

We're awaiting one new mount and two side-by-side adapter plates which will convert our two 400mm systems to two dual telescope systems. That will bring our count on property to 9 LOL.

Gallery / Re: NGC-1333
« on: 2019 January 31 17:16:01 »
We're in Bortle 6+ skies an hour outside Bangkok. We combat this with taking lots of exposures.

Currently for small objects we are shooting L on 3 telescopes (600mm, 400mm and 400mm), and RGB on our 4-scope 300mm widefield array. We weren't sure about how well the array's color would size up to match the L but in our first experiment it worked pretty well. I'll post the shot of NGC 1637 here in this forum. We lost a night last night to clouds so 1333 is pushed back until at least Sunday night while we complete two other objects over the weekend.

Actually now I see I can't post the 1637 image here, since after PixInsight processing I finished it in Photoshop. Not sure if links are allowed, but you can see the image here:


Gallery / Re: IC-1396 Close up and far removed
« on: 2019 January 29 21:59:59 »
Both very nice presentations of this object.

Gallery / Re: NGC-1333
« on: 2019 January 29 21:57:39 »
Great image. We've added this to our shooting list, will try to go after it this weekend. Only available to us for a little more than three hours each night, but we can target it with three scopes.

General / Re: A few ProcessContainer and Scripting questions
« on: 2019 January 19 02:19:54 »
Thank you Gerald. I was unfamiliar with that script. It is great, does much of what I want. Unfortunately it doesn't allow me to select how it names the output files, I was hoping I could use the file name as an indicator of the incremental value in the formula for that image.


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?

Thanks. Andy

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.


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

General / Re: Sugestions for a new computer
« on: 2018 July 09 07:16:58 »
We've turned to NVMe SSD instead of SATA SSD for our swap drive. NVMe is a quicker interface to the SSD than SATA. It was specifically designed for SSD drives.


I just want to add my two cents. In February, Adam noticed a post I made about deconvolution, and he messaged me, graciously offering me to review his deconvolution tutorial. I found the tutorial fantastic, providing me with a much deeper understanding of what was actually happening with each component of the deconvolution process. His workflow has sped up my deconvolution, and my results are much, much better. I'm looking forward to checking out his other videos.


Announcements / Re: A programming genius
« on: 2018 May 04 21:29:42 »
Sorry to hear. You might want to consider removing the link to the video, even the entire thread, if you think there may be visitors to this forum who aren't yet PixInsight owners and who might be tempted to take advantage of this video. No reason to point more people to that link.

Hi Kolec,

the question for me isn't whether to combine the data. The data combines nicely and we get great results. My only question is whether to res up or res down when registering the frames.

Thanks. Andy

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

16 megapixels (4096x4096)
pixel size: 9 microns

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

General / Re: Background pattern cause?
« on: 2018 April 27 20:29:08 »
Just a quick update: We sent sample images to FLI (calibrated/aligned stack, uncalibrated aligned stack, single light) and their initial assessment is that something seems wrong. We're waiting to hear back but this will likely require the camera be sent in for a checkup.


General / Re: using lights from two different nights
« on: 2018 April 26 19:26:14 »
Hi Lloyd,

As Rick mentioned, the mosaic merge process is different from the normal registration and integration process. What you're envisioning is the results from aligning and integrating, not mosaic-merging. Read this tutorial, see if it gets you started:

or this video:


Pages: [1] 2 3 ... 5