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 ... 272
1
Off-topic / Re: Purchasing a license
« on: Today at 13:08 »
what if you open your own paypal account and your brother just sends the money to you, then you use your paypal account to pay for the license? i don't think there is any fee to send money to friends and family.

rob

2
General / Re: > 4GB files
« on: 2019 June 15 09:57:53 »
is the file size < 4GB/3? you could split the file into 3 mono images and save as tiff, then use ChannelCombination in PI to put it back together. barring that it seems like the only way would be to crop to < 4GB files and reassemble with pixelmath in PI.

rob

3
General / Re: Basic Question on Calibrating Darks and Flats
« on: 2019 June 11 08:59:37 »
hi mark, hover your mouse over the optimization checkbox in the master dark area of ImageIntegration for a brief explanation of optimization.

rob

4
General / Re: DSLR PI Process Flow for Dithering?
« on: 2019 June 07 20:23:31 »
yeah, i agree, the lack of temperature regulation in DSLRs is a real killer... i also switched to a cooled CCD camera and life got a lot easier.

rob

5
that could be the case... if for some reason each thread needs its own copy of the file in memory. but usually with lightweight threads the address space of all threads is shared with the parent process. so in theory each thread could share the file handle for the CR2 files. but who knows.

rob

6
well on the software side, obviously there have been a ton of windows updates during that time... and also DCRAW was orphaned at some point so juan had to switch to libRAW. i guess if libRAW is less memory efficient than DCRAW that could also have something to do with it.

it is possible that if you configure windows to have more backing store the 300 deep stack could work, but then again there's a good chance your system would be brought to its knees paging all that stuff on and off the disk.

rob

7
i don't think its a waste of time, don't worry about it.

while i agree that the problem is with the capture software, with millions of frames out there with bad fits data it's not unreasonable to have to "clean up" after SGP as now the only way to solve the problem is on the processing side...

rob

8
apparently due to the lack of support for 'incremental reading' of CR2 files, pixinsight has to hold the entirety of a CR2 file in memory while integrating each pixel stack. CR2 files are generally enormous, so this puts a lot of pressure on the computer's memory system - all CR2 files participating in the integration must be held in memory concurrently. xisf and fits files can be read incrementally so less stuff is forced to be held in memory at any one time.

having said that of course if you have a lot of ram and lots of VM backing store, this should be OK. i guess one thing would be to compute how large your 20 CR2 files are together and see if you're anywhere near starting to need to page (keeping in mind all the other processes that are currently paged-in and how much DRAM they are using...)

rob

9
General / Re: FITS Processing Issues
« on: 2019 June 07 10:19:57 »
were the darks and lights taken with the same capture software?

this is the kind of thing that happens on cmos cameras where the gain of the lights and darks does not match, but a CCD camera should not have that kind of a problem. can you share the lights and calibration frames?

rob

11
you will have to upload a few subs somewhere and post the link so someone can take a look

rob

12
General / Re: DSLR PI Process Flow for Dithering?
« on: 2019 June 05 14:25:47 »
ok, i think that guy is saying that canon RAW files are actually cooked, meaning the camera firmware is attempting dark signal suppression, and that it can't be turned off. i think that is broadly true but i'm not sure it's settled science that calibrating a DSLR frame makes the pattern noise worse.

generally speaking calibration of frames from uncooled cameras is somewhat difficult as you can't really be sure that the temperatures match properly. usually optimizing the darks will mostly take care of this, but then of course any hot pixels in your frame end up being under-corrected by the scaled dark. then i suppose if they are now not bright enough to be rejected as outliers, the hot pixels make the "walking noise" even more obvious. i guess if this is the situation you are in, you could try running CosmeticCorrection to clean up the 'warm' pixels before proceeding to bayer drizzle.

rob

13
General / Re: DSLR PI Process Flow for Dithering?
« on: 2019 June 05 10:52:27 »
i don't know why you'd exclude calibration frames when drizzling. i can't find the thread at CN... what arguments are people making saying that you shouldnt calibrate images you are going to drizzle?

rob

14
General / Re: Why does STF do this?
« on: 2019 June 04 14:35:40 »
you have some problem with the way your flats are being acquired. or you have some reflections inside your and/or stray light entering your OTA. this can be a very difficult thing to debug...

there's not much that can be done about what STF does after ABE/DBE, short of modifying STF's default behavior (which can be done by clicking on the wrench icon in the interface.) if you want to "undo" the autostretch just follow what Geoff said in his point #1 - save the autoSTF configuration from the original image as a process icon and then apply that to the ABE/DBE'd image. it won't look so ratty, but the problem is real; the ABE/DBE just reveals it better.

rob

15
General / Re: Ha Extraction of OSC Data
« on: 2019 June 04 14:31:33 »
most debayer algorithms don't mix the channels together. i think maybe AHG does but PI doesn't support that method anyway.

you can use the SplitCFA process if you want to extract the individual R/G/G/B image from a bayer image.

rob

Pages: [1] 2 3 ... 272