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 4 ... 272
16
General / Re: Stuck on M33 LRGBCombination
« on: 2019 June 03 22:45:55 »
yes that is an improvement. i looked at the data more and i feel that there are some pretty significant gradients in the R, G and B masters which proved pretty difficult to remove. i think they limit the processing somewhat.

i did kind of a quick and dirty processing and came up with this... maybe it is worth evaluating the RGB subs and seeing if there are a number of frames with gradients and re-taking some of the RGB under better conditions.

rob

17
General / Re: Artifact in pseudo luminance
« on: 2019 June 02 11:14:13 »
make sure all pixel rejection settings are turned off, i think "clip low range" is on by default and may be active even if pixel rejection is turned off.

beyond that i don't think i've ever seen this problem with integrating 3 masters (but i have seen similar artifacts when integrating subs). one thing i'd try, but might be sort of a hack, is to linear fit 2 of the masters to the highest SNR master and save those masters, then see what happens when integrating them.

rob

18
General / Re: Warning While Doing ImageIntegration?
« on: 2019 May 30 18:28:36 »
Maybe an "Input Hints" keyword that converts the value when a file with the old SGP format is loaded?
+1 on this. while i suppose one could write a fits sanitizer to fix this, i have 1000s of frames taken with SGP and honestly i'd rather not touch them. i consider all of my subs to be read-only, and don't want to duplicate them all to fix this fits header problem.

I am very reluctant to implement special adaptations of our code base to solve interoperability problems that we have not generated, unless they are completely unavoidable. An input hint would be doable. However, given that this is a non-fatal error that does not prevent you from using ImageIntegration, I'll have to think about this before making a decision. On the other hand, given that the authors of the software in question have apparently no interest in supporting XISF, which we have created precisely to solve these problems among many others, I have little enthusiasm for this.

i wouldn't read too much into that - the SGP devs have been in "maintenance mode" for a very long time now. i think given that i16 works well enough for what they are doing, as an SGP customer it would be better (for me, anyway) if they put their effort into something other than file type support.

but if indeed Drizzle still works without this then i suppose all is well, i was under the impression that drizzle would be broken against these wrong FITS files.

rob


19
General / Re: Warning While Doing ImageIntegration?
« on: 2019 May 30 12:35:18 »
Juan,

I completely understand what you are doing here with regards to standardization.  And SGP is modifying their application to be consistent, so the problem is solved for data acquired going forward.

But, I now have years of data that I cannot process with the current version of PixInsight (as my techniques and PI tools get better).  So can you reconsider and give us some workaround that doesn't involve trying to maintain 2 installations of PixInsight?  Maybe an "Input Hints" keyword that converts the value when a file with the old SGP format is loaded?

- Shane

+1 on this. while i suppose one could write a fits sanitizer to fix this, i have 1000s of frames taken with SGP and honestly i'd rather not touch them. i consider all of my subs to be read-only, and don't want to duplicate them all to fix this fits header problem.

rob

20
General / Re: Apparent failure of ImageRegistration
« on: 2019 May 28 19:46:47 »
they are hot pixels; it is possible that StarAlignment has interpreted them as stars. i am not sure if it can be done within BPP, but in StarAlignment you need to increase the hot pixel removal control and possible increase the noise scale control. one problem with the m51 area is that there are not a whole lot of stars, and so there are fewer stars for SA to latch on to. sometimes if the stars themselves are soft (meaning not very peaky) then you need to increase the "peak response" control as well, to allow for softer stars to be detected as stars.

rob

21
General / Re: Stuck on M33 LRGBCombination
« on: 2019 May 28 18:20:10 »
by the way the non-LN L master looks fantastic, needs some DBE but i think if you reprocessed using that image you'd have an easier time of things. regardless you do have to take care for what adam is talking about; seems like the stretch you had for the L was too much for the RGB.

rob

22
General / Re: Stuck on M33 LRGBCombination
« on: 2019 May 28 17:35:04 »
no i think you are right adam, i just was trying to start at the beginning... the linear master indicated to me that it needed to be fixed before proceeding.

rob

23
General / Re: Stuck on M33 LRGBCombination
« on: 2019 May 28 17:09:54 »
ok - i should have asked... LN is very useful but (and god bless him) it's inclusion of LN in Kayron's tutorials is really causing a lot of problems for people. LN needs very careful tweaking and a clean reference and i'm not sure his tutorial really emphasizes that enough. i've seen a lot of people over the last 6 months with this type of problem.

you might re-do the RGB masters without LN if you also used LN for those...

anyway i will look at the new one in a little while.

rob

24
General / Re: Stuck on M33 LRGBCombination
« on: 2019 May 28 16:33:07 »
ok - for starters did you do any DBE or any gradient reduction to the L? if so then it needs to be re-done more carefully. if not, you must have some bad subs - there are dark halos around some of the stars and in parts of the galaxy.

rob

25
Bug Reports / Re: BPP 1.48 Problem
« on: 2019 May 28 16:07:54 »
what if you just put in a bias frame?

rob

26
General / Re: Stuck on M33 LRGBCombination
« on: 2019 May 28 16:06:33 »
can you post linear masters for the RGB and L? upload to dropbox or google drive or whatever.

rob

27
General / Re: varisized images
« on: 2019 May 27 19:07:54 »
well they can be calibrated as long as you can come up with darks/flats which match their pixel dimensions.

generally these problems occur when capture programs convert the CR2 files to some other format. since CR2 is a proprietary format, all of the 3rd party programs that handle CR2 have essentially reverse-engineered the file format. so you end up with, say, programs based on DCRAW doing something a little different from programs based on libRaw, which are both probably different than what canon's own software does. usually you'll find that one difference between these various programs is that the pixel dimensions of the converted CR2 files are very slightly different, like by 1-4 pixels.

but if you've got real CR2 files, then as long as you use the same software to create the masters and calibrate the lights, all should be fine.

anyway something is very weird if you have CR2 files that contain different pixel dimension images. what happens if you use canon's software to open the files?

rob

28
General / Re: varisized images
« on: 2019 May 27 11:56:50 »
is APT saving CR2 files or FIT files?

anyway differing X/Y sizes will prevent calibration but it should not prevent registration (and thus integration). but dithering itself can't cause this.

only thing i can think of is that you've got a lot of hot pixels in the subs and staralignment has latched onto those as "stars" resulting in no actual alignment of the subframes. you can increase the noise reduction scale and the hot pixel removal in staralignment and see what happens.

rob

29
General / Re: varisized images
« on: 2019 May 27 08:38:21 »
something else is wrong - are you saying that the subexposures as saved from nebulosity have different frame sizes?

dithering does nothing but move the pointing of the telescope a little bit between exposures, nothing fundamental about the sensor can be changed by this...

rob

30
General / Re: Flat not "flattening?"
« on: 2019 May 26 13:55:48 »
i guess it is worth a try to get some new darks of the same duration of the lights and give it a try without optimization.

RBI means "residual bulk image" and is a problem where some photoelectrons get trapped in the substrate (or bulk) of the imaging chip. it tends to get worse the colder the die temperature. to avoid having actual subexposures getting trapped in the substrate, you 'preflash' the chip with IR light and then read out the bogus image before starting your real sub. because the charge-trapping capability is related to the structure of the substrate, you usually see these circular rings which are a byproduct of growing the silicon ingot from which the wafer (and eventually the die) was made.

rob

Pages: 1 [2] 3 4 ... 272