32-bit PixInsight? DOA?
Posted 20 February 2013 - 10:06 AM
I have tried to get on their forums but they do not seem to be too responsive to my attempts to sign up and get some real answers on this (A bad sign).
Good software? Any product support?
Posted 20 February 2013 - 10:33 AM
Posted 20 February 2013 - 11:06 AM
My machine, a Dell M2400 precision workstation laptop has a fast dual processor and work through the calculations fine. I guess eventually I will go 64-bit by had a 64-bit laptop machine and there are a lot of programs that require use of the emulator for 32-bits that perform poorly.
Anyway, I tried to follow the first basic tutorial on YouTube:
PixInsight Processing Example: NGC 1808 LRGB (Part 1/2)
It worked on my own data until the Dynamic background Extraction where instead of using the actual correction calculated in the example they loaded some other data to correct and miraculously the gradients corrected. When I use my own calculated correction and execute it, nothing happens to the image. Is this just the degraded 32-bit version or what am I missing.
Posted 20 February 2013 - 11:12 AM
The DBE issue you are having should have nothing to do with 32 bits. I started at 32 bits two years ago and it was working fine. It may be operator error on your part. I like Harry's video tutorial better than PixInsight's.
Posted 20 February 2013 - 11:29 AM
My machine, a Dell M2400 precision workstation laptop has a fast dual processor and work through the calculations fine.
For small tasks, perhaps, but once you start doing things like deconvolution your processor probably won't handle the task very well.
I have an I7 x980 3.33Ghz 6 core 64bit processor with 12GB of RAM. Windows 7 see's 12 processors (Xeon) and when I run these routines I can see all processors running at nearly 100% utilization for several minutes.
I think 64bit processing is essential for programs like PixInsight.
Posted 20 February 2013 - 11:36 AM
Posted 20 February 2013 - 11:53 AM
It worked on my own data until the Dynamic background Extraction where instead of using the actual correction calculated in the example they loaded some other data to correct and miraculously the gradients corrected.
I also found this confusing in their video. Once you understand how PixInsight works, it becomes clear.
Basically, on the bottom left corner of every tool is a New Instance icon (arrow). Once you set parameters exactly how you want them for a given tool, you can drag this new instance icon and drop it in the process area located on the left hand side of the workspace and it will save all of the parameters you set for that tool. You can reuse those parameters any time by dragging the process icon back onto the tool or even directly to the image.
As far as DBE is concerned, I have found it works best when you increase the default sample size from 5 to around 15 and use more samples across all of the available sky background. I usually pick a value like 12-16 samples per row and let the program generate the samples. If there's too many, change the samples per row and regenerate or vice versa for too few samples.
You can use the forward and reverse buttons at the top of the tool to cycle through the samples more quickly than clicking on them. You need to scroll through them and delete any that fall onto nebulosity or your galaxy. Any that are on stars as can be seen by a group of black pixels, simply slide them off of the star so they only expose background sky. Keep in mind that for DBE to work correctly it is important that the samples only sample sky background.
That's the magic they did in the video. They had previously setup all the DBE parameters for NGC1808, set the samples where they wanted, saved the instance as a process icon and then later dragged that process icon back onto the DBE tool to set all the parameters and samples to their previously configured values. You can even set the process icon identifier name to something like DBE_NGC1808 so you can resuse it, for exmaple, on the luminance image. In fact, you can simple drag the process icon directly onto an image and it will execute the DBE tool on the image.
I watched this video a dozen times and there were several "tricks" they did that make it difficult for a new user to understand.
Another one that is likely to confuse you is when they use the Histogram Transformation tool to change the image from linear to non linear. They actually go out of the view of the user to disable STF (Screen Transfer Function) using the menu above the workspace and then they drop the STF new instance icon onto the Histogram Transformation tool, then drag the Histogram Transformation tool new instance icon to the darkened image (because they disable STF visualization).
I watched that many times before I figured out what they did "off screen".
Posted 20 February 2013 - 11:57 AM
I have used Dell Precision Laptops for years for various purposes including a lot of C++ OpenGL programming. I believe the 64-bit with multiple processors will do the same jobs faster, but if you are in no hurry... Anyway, I am waiting for the next set of processors to come out and will get the I7 equivalent and now 64-bits... but they will not have the next generation out till later this year....
I seem to be having some problems just replicating the tutorials and the process runs quickly enough. Must be me, so will go over them again.
I am having trouble getting this Dynamic background Extraction to work. I have my own data with a messy backround to extract. Maxim and CS5 do it OK in about 27 steps...
Posted 20 February 2013 - 12:02 PM
EDIT: When using HT, enable Preview so you can see the results in real time before applying to image.
Posted 20 February 2013 - 12:14 PM
I had to watch both PixInsight's and Harry's video several times to understand what they were trying to say. It's the first time using PI is the hardest. Once you get the hang of PI interface, it becomes easier and very powerful. When I signed up for 45 day free trial, I learned it pretty quick thanks to video tutorials and I loved it that I bought after three days with 42 days left of free trial.
Posted 20 February 2013 - 12:33 PM
also, as i mentioned in the PI forum don't forget to select a target image correction method. subtraction is what you want for sky gradients.
if you have black borders around your image after ImageIntegration, sometimes you need to crop them off before doing DBE. the borders are not actually black but very low pixel values and this throws off the statistical calculations that DBE does.
edit: every slider/box in every process has a tooltip. hover your mouse over the name of the slider or text entry box and you will get a description of what the slider or parameter box does.
Posted 20 February 2013 - 01:27 PM
Posted 20 February 2013 - 02:00 PM
PI is definitely lacking on their documentation. Harry's examples above are very good; I'd sit down with the video on one screen and PI on another and just slowly go through each step as he did them. Then I just did each video.
Honestly, there isn't much tweaking required. It's just finding a flow that works and running with it.
Posted 20 February 2013 - 02:39 PM
and yeah, you really want to be running the 64-bit versions.
Posted 20 February 2013 - 04:48 PM
Posted 20 February 2013 - 04:55 PM
First off, 64 bit is not faster than 32 bit. Actually, in many (or most) cases, 32 bit is a little faster on the same hardware. The benefit to 64 bits is that you have a much larger addressable memory space. This is a huge benefit to applications that manipulate large amounts of memory - like an image editor. So if you could compare 32 bit PixInsight side by side with 64 bit PixInsight, the 64 bit would get the job done quicker. But it's not a result of faster execution. It's a result of much more efficient memory usage.
Second, 32 bit software does not run in an emulation layer - at least not a software emulation layer. The CPU can run both 32 bit and 64 bit code natively.
I would guess that the PixInsight guys dropped 32 bit support because it makes their code cleaner, more efficient, and easier to maintain.
All that said, if you stick with PixInsight and learn to use it, you will not be sorry. It is absolutely first rate software with first rate support.
Posted 20 February 2013 - 05:02 PM
I believe the 64-bit with multiple processors will do the same jobs faster, but if you are in no hurry...
Speed is not the biggest factor in using 64-bit processing, memory is. 32-bit processors can only address 4 GB of memory. 1GB of address space is reserved for IO processing, leaving only 3GB available for programs. I have both a 32-bit and a 64-bit laptop running Pixinsight. My biggest problem with the 32-bit processor is that the batch preprossing script crashes because it runs out of memory. When using image integration, I needed to reduce the buffer size to 8 MB and the stack size to 512 or 128, depending on the number of images being stacked, which did slow down the stacking. However, most processes run as fast with 32-bit processors if everything can fit in the available program memory.
My 64-bit laptop has 8 GB ram, all of which is available for programs.
Posted 20 February 2013 - 06:14 PM
in theory the 64-bit machines should be slightly faster due to the addition of extra registers and the 64-bit native word width. in practice though the difference is small because the hardware has many more registers than are exposed in the ISA and juggles them behind the scenes.
plus with all this multithreading (hyperthreading) stuff the hardware has multiple register contexts. but you get that on the 32-bit versions as well.
Posted 20 February 2013 - 07:00 PM
the 3GB limit is not IO processing
Not what I said. 1GB is reserved for memory mapped IO, leaving 3GB for programs.
Posted 20 February 2013 - 08:23 PM
but okay, have it your way. the kernel does not need any address space.
Posted 20 February 2013 - 08:48 PM
So, bottom line is that I ran PI in 32-bit all day and I seem to have survived. It does peg the dual processors at 100%, but I never ran out of memory or used virtual memory. It does not seem to me to be worse than some processes I have had to run in Maxim.
However, on the Dynamic Background Extraction (DBE), there must be a lot of secret sauce involved here. I have some vignette images and it was very hard to get anywhere with them, so I cropped them and ran as TIFF files after cropping in CS5. This worked better, but would be nice to have some best practices for DBE like:
1. How many points are optimal?
2. Is there an optimal pattern?
3. Do you target noisy areas?
4. Can you run it multiple times without a problem?
Anyway, I am learning and probably will buy the software as I need all the help I can get.
PS I have an SSD on my computer so if I run into virtual memory it is hardly noticed...
Posted 20 February 2013 - 08:59 PM
re: SSD that makes paging fast but you still have this hard 2GB/3GB limit that effectively forms a 'jail' for PI. it just can not allocate more memory past that point and memory intensive processes (like imageintegration) can fail.
Posted 21 February 2013 - 02:59 AM
The CPU can execute both 32-bit and 64-bit code but not simultaneously so when you use 64-bit windows the core of the OS and drivers are 64-bit and CPU works in 64-bit mode so the WoW emulation layer is needed for 32-bit programs to run.
Posted 21 February 2013 - 10:20 AM
On Itanium, Windows includes IA32Exec, which actually does software emulation of 32 bit x86. On this platform, 32 bit code does run slower than 64 bit code because of this emulation.
On 64 bit Intel CPUs other than Itanium, and on all 64 bit AMD CPUs, 32 bit code is executed natively. I have done substantial work with benchmarking code compiled for both 32 and 64 bits. In cases where there is no memory address advantage, 32 bit code frequently runs a few percentage points faster than 64 bit code on the same hardware for these CPUs.
My direct experience is with the previous generation of CPUs and compilers My expectation is that, at some point, we'll see parity in execution performance between 32 and 64 bits, or maybe a slight advantage to 64 bits, due to optimizations for 64 bit.
At the end of the day, though, the advantage to 64 bit is in memory addressing. Actual execution speed will remain very close between them, because they both run natively on the CPU.
And to tie this in some way to the topic, PixInsight benefits greatly from the 64 bit memory address space. It makes perfect sense to me that they would want to focus on that environment. Similar software, like CCDStack and Photoshop also run much better on 64 bit.
Posted 21 February 2013 - 10:59 AM
To return to image processing for a bit, I am having some problems determining if the crud I am seeing in my images recently is due to poor flats or skyglow. PixInsight has led me to try to make that distinction.
This shot is of M80 from early this AM. It is stacked in maxim using flats from Sky Flats Assistant. When I use these flats with narrow band images there is no crud at all. But with LRGB you see this and I think it is skyglow because I am in a Red Zone just south of San Francisco.
The screen shot is of my attempt to do DBE. I am pretty sure this is skyglow because it is not exactly centered on the image (the flats are) and that probably reflects some sort of gradiant across the sky.
Anyway, opinions cheerfully received and appreciated. I still need to clean up these images one way or another.
Finally, to reduce skuglow I am trying to use CCDComander to just take images as high as possible in the sky, i.e. only when obejcts is above 45 or 55 DEG. I had to take M80 at above 25 DEG since it is low in the sky... was the last object on my Messier list.