本帖最后由 gbamboo 于 2014-4-19 07:59 编辑
外面翻出来的,与大家共享。 作者人见称darryl
http://www.cloudynights.com/ubbt ... /o/all/fpart/1/vc/1
看看这位大神的近期作品
http://www.cloudynights.com/ubbthreads/showflat.php/Cat/0/Number/6471247/page/0/view/collapsed/sb/5/o/all/fpart/1/vc/1
(我自己开始加批注了)
EDIT: I edited this for some more clarity plus additional info.
I never stack figures of 45% - 50% or more of the frames from AS!2 unless they are truly remarkable recordings, here I'm referring to "50%" as half the total frames captured, not a "quality%" value: I regularly make comparison stacks and find that if you can get around approximately 6 to 7%+ better quality (here I am talking "quality%" wrt the "best frame" AS!2 chooses) then you are probably likely to be better off with the lesser numbered stack...usually my stacks consists of between 10% - 35% of the total frames captured - depending more on the planet processed.....10% - 15% usually for Mars (ie, if I captured 20,000 frames I'd likely use 2k or 3k stacks)
For example if AS!2 says after "Analyse" that you can stack 4000 frames @ 58% or 3000 at 64% I'll probably choose the 3k stack option.....this is all a bit flexible and you should do your own trials but you get the idea.....if it had said 4k @ 58% or 2k @ 64% or better I most probably still would've gone for the 2k stack and accepted that I'd probably need a bit more on the De-noising sliders in R6 with wavelets...but a bit more on that below.
Other than that, imo 3X drizzle works much better in AS!2 with any half-decent data - my own findings are that 3X drizzle usually allows the following wavelets applications without creating a heavy, overly-contrasted/sharpened effect, ie more "refined" and smoother in the ensuing outcome: exceptions are when you want to process poorer data and their isn't really enough detail in evidence in the capture to allow 3X drizzle to work successfully.
In those situations I might opt for 1.5X drizzle and although Emil has stated that this (1.5X) is merely a truncated 3X job I have not found any of the resampling algorithms that are readily available to give an accurate comparative image: that is, if I were to drizzle at 3X in AS!2 and resample back down to 1.5X in any of the methods I usually have at my disposal - eg Registax, AstraImage or CS4 - I quite simply cannot reproduce the image quality I can achieve with AS!2's 1.5x drizzle...<img alt="" class="noBorder" height="23" src="http://www.cloudynights.com/fileSendAction/fcType/12/fcOid/374815349517413028/fodoid/374815349517413029/imageType/MINI_THUMBNAIL/inlineImage/true/154avatar" width="26" />
(注: As2叠加在10%-35%, 特别是火星在10%-15% 数量, 好图像开3x drizzle)
For me this is usually a fairly moot point because I don't care to bother with data that marginal, but it might be worthwhile as you come to grips with all of this. Drizzling at 1.5X also requires a significantly lighter application of wavelets - my advice with marginal data is to follow this "lighter touch" rule and your end-result will be much more pleasing than the old proverbial "trying to make a silk purse from a sow's ear" efforts!
With 3X drizzle & wavelets in Registax6 I rarely employ anything but #1 & #2 sliders set at "full throttle" (ie, "100") with "Linked Wavelets" checked and Sharpening=0.12, applying De-noising carefully & observing the magnified image with the "Zoom View" window enabled - along with watching the "Histogram" set to "Log Scale".....I suggest you do some little trials yourself with all of this because you can easily open 2 Registax6 windows side-by-side on your screen and with AS!2 opened at the same time you just stack a couple of different stack-sizes/%'s and compare them at the same time in R6 with the same wavelets settings, although as said you might perhaps need a tad more de-noising for the smaller stack - but this isn't inevitable...the smaller stack might have much better SNR and not need any more de-noising whatsoever, despite possessing fewer frames in its' stack (you know what I mean about having two R6's + AS!2 open at the same time, don't try to have AS!2 actually processing as you're playing with the wavelets in R6 - AS!2 is a greedy little bu**#! with processors and likes to gobble up all the efforts of my 8 CPU's..!
(在R6中的处理, wavelet 锐化居然只处理layer 1跟layer2到100%, “linked” 设置)
I'm equivocal re what I term using "Straight Drop" into AstraImage - meaning I merely take the resulting .fits files out of Registax6 (I use _SD for these in my filename) & just "rgb combine" these files - otherwise I will process the individual channels in AstraImage before "rgb combine" there.....sometimes one way works a bit better than the other & sometimes perhaps I just 'think' it does! It can help the tendency at times to over-process if you use the "SD" method as you're looking at essentially the end-rgb image to a large extent & have a good feel at this stage on just how much extra work you might need/wish to add, minus P/shop processing.
Also, I do like to get the rgb alignment sorted before I apply deconvolution so if I go the 'SD' path I "Save as" this SD rgb combine as a .tiff in AstraImage and drop it straight back into R6 for an "RGB Align" - it's much quicker this way and usually more accurate than by eye in A/Image.....but beware "RGB Balance" which I find is usually fine for Saturn but much more problematical at times with Mars...then take the resulting aligned .tif back into AstraImage. To avoid confusion try naming the "straight Drop" tif file as something like ***RGB_SD.tif and after you drop it back into R6 and align etc it can become ***RGB_SDal&bal.tif or whatever...::)
(R6后的rgb直接在Astra Image里处理,然后再会R6 做RGB Aligment )
Of course if I rgb combine by eye in A/Image after applying deconvolution to the individual channels first, I still drop it into R6 to check alignment.....you might then try additional deconvolution on this rgb combined & aligned image (something that I of course apply to the "_SDal&bal" file also as it has NOT had any decon thus far) but always remember that the more you push earlier in any form of sharpening - be it wavelets or deconvolution - the less you can work on these images in that respect further down the chain so to speak...
Jupiter - especially with moons & shadows is a special case where you will probably need to do the rgb alignment yourself by eye in AstraImage.....sometimes (especially in certain seeing conditions) it can be a bit of a devil to align channels/colours appropriately: I opt for alignment on details well-inside the major portion of the disk with tweaks for recalcitrant moons etc that sometimes need a resort to "Layer Mask" (rarely thankfully!) If aligning within the internal disk details causes limb misalignment/colouration then you can go the "Layers Mask" route.....or (if you have P/shop or something similar) just select the the planet (ie, nicely around the limbs) employ "Select>modify>contract" a certain pixel amount to bring the selection inside the planet edges enough to contract past the offending limb colouration/misalignment, then "Select inverse" and de-saturate these peripheries.....the move tool can be used for fine-positioning the selection during this procedure - and the same methodology can be employed with some "Gaussian Blur" to get rid of edge artefacts that over-zealous sharpening exacerbates on Jupiter
Regardless, getting back to AstraImage I usually apply an LR deconvolution at a greater C/W followed by ME at a significantly lesser C/W: this might mean as a rough example atm for Mars on a drizzled image perhaps 3@1.7 @ 1.7 in LR & 5 @ 1.2 in ME or somesuch.....LR is "sharp but vicious" in comparison to ME which has better noise outcomes - the number of iterations with LR is also important to regulate...what you have to be mindful of is not pushing any image in any processing software too far towards the "Ugly Zone"
(给出了Astra Image 的卷积算法经验, LC卷积然后ME卷积)
My "general throw-away ballpark" suggestion for determining c/w is to make a series of critical observations on how any particular c/w affects the image detail in AstraImage's preview window.....I have a fairly old version of A/Ipro3 or somesuch but one of my whinges is A/Image NOT having a magnified view herein!
When applying LR decon I determine the c/w value that enables the finer detail with planetary images to appear as finely delineated as is possible by varying said c/w's: looking at fine festoons in Jupiter's EZ region, spots etc on Saturn & the finest markings on Mars' disk are my suggestions herein.....you might need to bump the number of iterations up beyond that which you eventually apply to get a clearer awareness of this value: the decision as to how many iterations follows that principle about not pushing too much & keeping noise etc under control...
Any ensuing ME deconvolution you apply should usually be much easier to see/determine and as said ME is less intrusive as far as noise is concerned. <img alt="" class="noBorder" height="15" src="http://www.cloudynights.com/static/images/graemlins/icon_smile.gif" width="15" />
Re WinJupos, sometimes I do quite a bit of processing before WinJupos & sometimes not so much.....WJ smooths images 'cos it's stacking many more frames but you don't want a too-over-sharpened "set" of images loaded into WJ 'cos it can backfire a bit on you.....I like to have them fairly well processed 'cos I also find that although WJ does smooth image outcomes, it doesn't let you do too much sharpening with this output - if you try too much the WJ image can end up looking no better (or worse!) than the non-WJ images!
(WinJoPus 对于长时间修自传还是有用的,但是对于短时间快速拍摄而言不用WJ也不差,甚至更好)
Generally I'll process my images to the point where a tangible amount of USM in P/shop could still be applied to each single image (ie, slightly "under-processed" as to how you would gauge a single image you wanted to process) and then load these into WJ at this stage - this usually means I can apply a bit more USM in P/shop to the WJ output than what I would've been able to apply for just one single image - and still wind up with a smoother, more detailed outcome.
I've found that using the "Derotation of images" (or r/g/b frames) gives pretty good results for anything up to around half an hour on the major planets (Mars, Jupiter & Saturn) although a really excellent "classic timespan" capture & process might evince slightly finer resolution/detail clarity at times...fast fps with the newer cmos cameras does mean at the right time in the apparitions you might be able to stack large numbers of frames for each channel or colour capture within "classic' time constraints - maybe!;)
Hope there's something useful here and happy to answer any additional queries and feel free to add any of your own observations/comments to this thread..!
|