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

Pages: [1] 2
Bug Reports / Program not responding constantly
« on: 2016 August 13 04:02:09 »
I recently updated to the newest version of PI.  Everything works perfectly (and some things better) but I am always getting the "not responding" when the program computes something memory intensive.  Such as creating a star mask or saving a project.  By not responding I mean the entire screen goes opaque and the mouse pointer spins the blue circle.  Eventually it will work itself out and get back on track and I have not had the program actually crash or stay in that state of not responding... but it does  happen every single time I ask it to do something intensive. 

BTW- I'm running this on a machine with Intel i7-3840QM CPU and 32G of RAM and never had this problem with the previous version of PI.  Just wondering if this is a potential bug or is there a setting I can change somewhere that effects how resources are utilized. 

Thank you!

Thanks for the additional information Vincent.  My images did not seem to suffer from the "red", but I just found it odd that Bias and Dark frames were not actually black before viewing with an STF.  They were clearly red prior to any stretch.  None of my other cameras' RAW files presented like this, it was only the 750D.  They should have been black when first opened...

Either way, it seemed to not be a problem when calibrating and with the new version of PI, all looks the way it should.


I couldnt find the setting you recommended, so I checked to see if my version of PI was up to date.  It was not.  After performing an update, all is well. 

It looks like the new version handles the rendition of RAW files better for my camera as well.  Perhaps DCRAW update, or something else....  (Canon 750D)

Files used to be strange and red.

Thanks for your help!

Hmmm.  I don't see that setting.   

Also, with Dark Frames it is not quite the same as a full black border.  It's darker, but not black.

See attached for RAW settings and a Dark Frame.

The explanation you linked to makes sense to me.  I assume that image integration / calibration processes and scripts like BPP ignore this "unused" region.   So if I do noting, I don't really have to worry about it.... it will just look funny when I view the files.??

General / PixInsight- Dark Border on Two Sides (Whats going on?)
« on: 2016 August 08 11:27:15 »
Hi all.  I've been digging into manual integration and realized that I have a strange border that is on two sides of my frame.  When I open a file (Light, Flat, Bias, Dark, ) it displays this very strange artifact.  See attached:

These are Canon CR2, from Canon 750D.  I'm using PI v 1.8.

Any ideas what is going on here?

General / Re: Multiple Masks
« on: 2016 July 09 13:29:04 »
Thanks pfile.  I think that will work perfectly for me.  That is pretty simple and not nearly as daunting as I was thinking it would be.  I appreciate your reply!

General / Multiple Masks
« on: 2016 July 05 05:35:41 »
I'm not sure if there is a way to already do this...

I found myself editing the veil nebula and really wanted to be able to apply two masks to an image to isolate the nebula.  A really simple way to do this would be to create a Lum mask and clip in HT.  Apply to image, then create a star mask and apply that to the image to further mask off the areas you dont wan to touch. 

I'm guessing that this could be achieved with pixel math, but that is beyond me at this time.  It would be so simple (UI) to drag and drop the first mask, have that tab visible, then drag and drop the second mask.  You could then independently remove and invert those masks depending on what you want to do for edits.  I find myself wanting to do this more and more frequently.  It sounds simple to do, but maybe it is not that simple when executing this in the program. 

I'm not a programmer, and only an amateur user of PI so simple execution of a concept like this would really be helpful.  Does this already exist?  Kudos to the programmers on this program... it is just awesome!  Thank you!

Thank you Juan for your fast reply.  Should I play with the DNG files for now, or simply wait?  I guess, how long until the current version of DCRAW is available for PI update?  If its just a day or two I'll stop wasting my time with DNG, but if it will be longer I can at least start processing images as DNG.  Thanks again!

The version of dcraw integrated in the current official version of PixInsight (dcraw revision 1.473, released 2015 February 25) does not support the Canon EOS 750D and 760D cameras.  These models are supported in the latest dcraw revision 1.476, which I have integrated today with the DSLR_RAW module that will be distributed in the new version. So please be patient, and sorry for the inconvenience.

Juan,  Thanks for the info.  This is what I concluded.  No worries though, converting files to DNG first works just fine for now.  Is there any reason why I would prefer the RAW file over DNG in the future once the new version of DCRAW is implemented?  I have used both DNG and RAW files in the past and I can't tell any differences with the final results. 

I just noticed that if I convert the RAW file to DNG, that the DNG does load and display properly.  Is the CR2 of the T6i not supported by PI?

I just picked up a Canon T6i/750D.  It's cloudy so I set out to start building master calibration frames.

I shot and integrated bias frames and ended up with a pink frame that had no banding noise or anything.  I thought this was very peculiar, so I re-checked my parameters... all looked right, and then decided to open up a RAW file to see what it looked like.

A single RAW image also looks the same... its just a pink file without any noise.  Next I opened a debayered version of the file to see what that would look like... still the same.  A pink file.

These should all look black and upon stretching should show the noise.

When I open the RAW file in LR or PS it displays as a black image, and upon stretching starts to show the banding noise as expected....

Any ideas about this?

Attached is a screen shot of a RAW file.  Bias image.  Shot in the dark with lens cap on.  ISO 1600.  1/4000 second.  No STF or HT applied.

What am I missing here???

Interested to see your results, particularly in relation to dark scaling. Matching darks to lights, exposure time and temperature, each session is laborious, but usually predictable.

Right now it's all just theory to me, and I hope to implement this type of thing over the next few weeks (clear nights *fingers crossed).  Jon Rista mentioned that dark frames shot with longer exposure than light frames will always be scaled down, resulting in a reduction in random noise, which may be more ideal than the "normal" method of matching dark frame exposure length to lights...  Not sure I fully understand the "why" with this, but it is appealing to me to be able to generate master darks at various temps with a specific long exposure rather than a whole mess of master darks at various temps AND exposure lengths.  makes for a MUCH more manageable dark frame library.   8)

Plus the concept of dark scaling makes sense to me from the viewpoint that within a specific imaging session the temp can drop 10 to 15 degrees (or more).  Plus, even if ambient temp remains stable, the sensor temp varies across the session.   This is really cool for those of us who are using uncooled DSLR's.

I've had my share of cloudy rainy nights recently and have been thinking about calibration frames.  I can't seem to find a thread on this topic, although I am sure it has been discussed before.   I primarily use BatchPreProcessing however it's no problem for me to create master frames independently, therefore processing time and power usage is not a primary consideration.  These rainy nights give me plenty of time to waste on making the best calibration frames possible. Let's imagine for this thread that we live in a perfect world.  What's best for PI processing?

1) Dark frames.  I've been reading about dark frames and the concept of dark scaling and have come to the conclusion that rather than shoot a quantity of dark frames at the same exposure length as light frames that it is better and more efficient to create a master library of dark frames at various ambient temperatures with LONG exposures (longer than the longest light frames captured)... Then through the implementation of dark scaling, IP will scale the dark frames using noise evaluation to best calibrate with the lights.  For example:  If I plan on only shooting 2 minute subs, create a master dark library of 4 minute dark frames and simply dark scale. Regardless of whether I shoot 2 minute subs or 30 second subs, I can use dark scaling with the 4 minute darks for calibration.  (Any opinion AGAINST using this practice?  Also, how many should be captured?  I understand the math on diminishing returns, but as we will be making a master dark library, and only making each master once, what is the best qty to shoot for?  30 darks?  60 darks? 100 darks?

2) Flat Frames.  This one is pretty straight forward.  A master flat can be re-used over and over as long as the orientation of the optical train and the sensor are kept constant.  Of course, this will not help with dust bunnies or other variable anomalies, AND flats are so easy to take that it is not really a big deal to take them every time.  Either method is likely acceptable.  The big question:  How many? What is the perfect number for PI?  30? 100?

3) Bias frames.  I have read that for an excellent quality master bias frame to have the greatest impact when calibrating darks, flats and lights, that having MANY bias frames is ideal.  With 180 bias frames an excellent master bias can be created and that with 360, an almost perfect master bias can be created.  Is it worth taking 360 bias frames for PI to play with?

Thanks and fingers crossed for some clear skies!


If you want to use the BatchPreprocessing script you need at least bias and dark frames. In fact, the main reason for the existance of the BatchPreprocessing script is to do image calibration, so unless you have bias, dark, and flat frames there isn't too much point to using the script.

So, you'll have to do a manual debayer operation (BatchDeBayer script), followed by StarAlignment (under ImageRegistration), and then ImageIntegration. For a quick practice run with three files you can probably just use the defaults for each process and it should take only a few minutes to perform the entire set of operations.

Great information!  I was having the same issue as the OP and gave this a try.  Worked like a charm.  Thanks!

Hi, using
  FITS Header
provides the requested stacking data
in the line:
ImageIntegration.numberOfImages: xx


Thanks Gerald!  Just what I was looking for. 

Pages: [1] 2