QQ登录

只需一步,快速开始

[天文观测] 大神级行星处理的处理技巧

[复制链接]
gbamboo 发表于 2014-4-18 19:30 | 显示全部楼层 |阅读模式 来自: 美国 xfinity

马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。

您需要 登录 才可以下载或查看,没有账号?加入牧夫(请注明天文爱好者,否则无法通过审核,请勿使用gmail/outlook/aol/icloud邮箱注册)

×
本帖最后由 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..!  







天文之乐 发表于 2014-4-18 19:53 | 显示全部楼层 来自: 中国–云南–昆明–呈贡区 电信
我表示一个都没看懂,哈哈
回复 顶~ 砸~

使用道具 举报

九爷 发表于 2014-4-18 20:40 | 显示全部楼层 来自: 中国–江苏–苏州 电信
已从谷歌翻译搬来







一位朋友找回到马鞍今天上午pm'd我要对这个问题的一些意见后,我送我的答复我想张贴他们作为一个线程它可能是值得的 - 这里FWIW它与一对夫妇的修改/补充: :)
  
编辑:我编辑了一段更为清晰,加上额外的资讯。
  
我从来不叠的45 %的数字 - 50 %以上的帧从AS 2 ,除非他们是真正了不起的记录,在这里我指的是“ 50 % ”为总数的一半帧拍摄,而不是一个“质量% ”值! :定期对我做的比较栈和发现,如果你能得到周围约6至7% +更好的质量(这里我说的“质量% ” WRT “最佳框架” AS 2公司选用! ),那么你很可能会得到更好的了与较小编号的堆栈...通常我的书库由10% - 捕获的总帧数为35 % - 这取决于更上处理这个星球..... 10 % - 通常为15 %,火星(即,如果我捕获20,000帧我很可能使用2K或3K栈)
  
例如,如果AS ! 2后, “分析”,你可以堆叠4000帧@ 58 %或3000的64 %我可能会选择3K堆栈选项说.....这一切都是灵活一点,你应该做你自己试验,但你的想法.....如果它说4K @ 58 %或2K @ 64 %或更好,我很可能还是会已经一去不复返了2K栈和接受,我可能需要多一点对去噪滑块在R6与小波......但略偏上下方。
  
除此之外, IMO 3X小雨的效果要好得多在AS 2与任何半体面数据 - !我自己的研究结果是, 3X毛毛雨通常允许以下小波应用程序,而无需创建一个沉重的, overly-contrasted/sharpened效应,即更多的“精“和更流畅的在随后的结局:例外的是,当你要处理较差的数据和他们是不是真的不够详细证据的采集,让3X小雨顺利进行。
  
在这种情况下,我可能会选择1.5X小雨,虽然埃米尔曾表示,这( 1.5X )仅仅是一个被截断3X的工作,我还没有发现任何的重采样算法,可随时给出一个准确的比较形象:那就是,如果我是在3X小雨在AS 2 ,在任何方法我平时都在我手上回落到1.5X重新取样 - 比如Registax , AstraImage或CS4 - 我很根本无法重现的图像质量,我可以带AS实现! 2的1.5倍小雨... < IMG ALT = “ ”级= “ noBorder ”高度= “ 23 ” src="http://www.cloudynights.com/fileSendAction/fcType/12/fcOid/374815349517413028/fodoid/374815349517413029/imageType/MINI_THUMBNAIL/inlineImage/true/154avatar"宽度= “ 26 ” / >
  
对我来说,这通常是一个相当有争议的问题,因为我不在乎理会数据的边缘,但是当你开始应付这一切可能是值得的。毛毛细雨在1.5X还要求小波的显著较轻的应用 - 我与边缘数据的建议是遵循这个“轻碰”规则和您的最终结果会比更令人高兴的老谚语“试图从做一个丝钱包母猪的耳朵“努力!
  
与3X小雨和小波在Registax6我很少使用什么,但# 1和# 2滑块设置为“全油门”(即“100” )与“链接小波”检查和锐化= 0.12 ,采用精心去噪与观察用“缩放视图”窗口中启用放大的图像 - 一起看“直方图”设置为“对数刻度”......我建议你做一些小的试验自己与这一切,因为你可以轻松地打开2 Registax6一侧的窗户并排在屏幕上,并与AS ! 2你打开的同时你只是堆了几个不同的堆栈大小/ %的的,并在同一时间, R6具有相同小波的设置对它们进行比较,虽然说作为也许须一点点更去噪的小堆栈 - 但这不是必然的...小堆可能有更好的信噪比和不再需要的去噪任何,尽管其“栈拥有更少的帧(你知道我的意思大约有两节R6的+ AS 2同时打开,不要试图让AS 2实际处理作为你玩,在R6上的小波 - !的AS 2是一个贪吃的小卜* * # !与处理器和喜欢吞噬了我8个CPU的所有努力..!
  
我是模棱两可的再我长期使用“直降”到AstraImage什么 - 这意味着我只承担由此产生的符合文件出来Registax6的(我用_SD这些在我的文件名)和刚“ RGB结合”这些文件 - 否则我会处理前“ RGB组合”有.....有时单程比另一个&有时好一点的AstraImage各个通道也许我只是'想'它!它可以帮助的倾向,有时过度的过程,如果你使用“SD”方法,你看本质最终RGB图像,在很大程度上与有良好的手感在这个阶段上到底有多少额外的工作,你可能需要/想要添加,减去P /店处理。
  
另外,我不喜欢得到RGB排列排序之前,我申请去卷积,所以如果我走了' SD '路径I “另存为”此标清RGB合并为一个。 TIFF在AstraImage并把它直接回到R6为“ RGB对齐“ - 这是快得多这种方式,通常比眼A / Image.....but提防更准确的” RGB平衡“ ,我觉得那通常是罚款,土星,但更成问题,有时与火星......然后承担由此产生的对齐。 TIF回AstraImage 。为了避免混淆尝试命名的“直降” tif文件为类似*** RGB_SD.tif ,你把它放回R6和对齐等以后它可以成为*** RGB_SDal & bal.tif或任何... :: )
  
当然,如果我rgb的由眼A /图像解卷积应用到各个渠道先结合后,我还是把它放到R6检查对准.....你可以再尝试在此RGB额外的反卷积组合和排列的图像(东西当然,我申请到了“ _SDal及BAL”文件还因为它已经没有任何解构迄今),但永远记住,你越前面任何形式的磨砺推 - 无论是小波或反褶积 - 越少,你可以在这些工作在这方面进一步环比下滑的图像可以这么说...
  
木星 - 尤其是卫星和阴影,是一种特殊情况,你可能需要自己做的RGB排列由眼AstraImage .....有时(特别是在某些观测条件),它可以是一个有点魔鬼对齐渠道适当的/颜色:我选择对齐细节上精心里面的磁盘调整为顽固卫星等,有时需要诉诸“图层蒙版”的主要部分如果在内部磁盘细节调整导致肢体错位(很少谢天谢地! ) /着色那么你可以去“图层蒙版”路线.....或者(如果你有P /店或类似的东西),只要选择的星球(即很好地围绕着四肢)使用“选择>修改>收缩”一定的像素量,使选择地球内部边缘足够的收缩过去违规肢体着色/错位,然后在“逆选择”和去饱和,这些外围.....移动工具,可用于精确定位在此过程中的选择 - 而且同样的方法可以采用一些“高斯模糊”,以摆脱这种过分热心锐化加剧了对木星边缘文物
  
不管,又回到了AstraImage我通常适用的反卷积的LR在一个更大的C / W的后跟我来说一个显著较小的C / W :这可能意味着作为一个粗略的例子大气压火星上淋上图像也许在3@1.7 @ 1.7 LR & 5@1.2在ME或诸如此类..... LR是“犀利,但恶性”相比, ME拥有更好的噪声结果 - 迭代与LR的数量也是重要的调节......你有什么要铭记不按任何图像中的任何处理软件太远对“丑女区”
  
我的“一般扔掉的球场”的建议确定C / W是作出一系列关于如何任何特定的C / W影响图像细节批评意见的AstraImage的预览窗口.....我有一个相当老版本A的/ Ipro3或诸如此类,但我whinges一个是A /图像没有在此放大图!
  
当应用LR解构我确定C / W值,使更精细的细节与行星的图像显示为精细划定为可通过改变上述C / W是:寻找在木星的EZ地区的精美花饰,土星和最优秀的斑点等火星上的“磁盘标记是我的建议此处.....你可能需要碰撞迭代次数达除了这点,你最终申请得到这个值更清晰的认识:在决定如何多次迭代遵循这一原则有关不推太多&保持在控制噪音等...
  
任何随后的ME反褶积应用通常应该是更容易看到/判断和说ME是侵扰程度较低尽可能噪音的关注。 <img alt="" class="noBorder" height="15" src="http://www.cloudynights.com/static/images/graemlins/icon_smile.gif" width="15" />
  
重新WinJupos ,有时我做了不少处理之前WinJupos &有时没有那么多..... WJ平滑图像'因为它的堆叠更多的帧,但您不希望图像的太过分激化“集”加载到WJ '导向可能会适得其反一点上你.....我喜欢让他们很好地处理'因为我还发现,虽然WJ做平滑的图像效果,它不会让你做太多这种锐化输出 - 如果你尝试了太多的WJ图像可以结束了寻找没有更好的(或更糟! )比非WJ图片!
  
一般来说,我会处理我的图片到USM镜头在P /店铺有形的金额仍可以应用到每个单独的图像(即,略显“下处理”为你将如何衡量你想要处理单个图像的点),然后将这些加载到WJ在这个阶段 - 这通常意味着我可以在P /店申请多一点USM镜头的WJ输出比我会一直能够申请只是一个单一的形象 - 并且仍然风与更顺畅,更详细的结果。
  
我发现,使用“去旋转图像”(或R / G / B帧)给出了相当不错的业绩东西长达约半小时的各大行星(火星,木星和土星),虽然一个真正优秀的“经典时间跨度“捕获&处理可能会稍微表示出更高的分辨率/清晰度的细节,有时...与新的CMOS摄像头fps的速度快并不意味着在合适的时间在显灵你也许可以堆叠大量帧的每个通道或色彩捕获在“经典”的时间限制 - !也许;)
  
希望有这里一些有用的东西,并乐意回答任何额外的查询和随意添加任何你自己的意见/评论这个主题..!
回复 顶~ 砸~

使用道具 举报

lygg 发表于 2014-4-18 21:30 | 显示全部楼层 来自: 中国–北京–北京 联通
啊啊啊,,,让人情何以堪~
回复 顶~ 砸~

使用道具 举报

影风 发表于 2014-4-18 21:50 | 显示全部楼层 来自: 中国–广东–东莞 电信
留名以后看
回复 顶~ 砸~

使用道具 举报

northwolfwu 发表于 2014-4-18 22:47 | 显示全部楼层 来自: 中国–江苏–南京 联通
经验之谈,谢谢分享!
回复 顶~ 砸~

使用道具 举报

无名无敌 发表于 2014-4-19 09:59 | 显示全部楼层 来自: 中国–天津–天津 联通
提示: 作者被禁止或删除 内容自动屏蔽
回复 顶~ 砸~

使用道具 举报

wtyu21 发表于 2015-6-11 16:22 | 显示全部楼层 来自: 中国–香港 城市电讯有限公司
谷歌的中文翻譯還是留給火星人才能看懂~簡體字還好,繁體字的翻譯往往把同音字都翻譯成一個字,懂英文原文的人當然會知道錯在哪裡,不懂的就留給比火星人更高深高智慧的木星人吧!
回复 顶~ 砸~

使用道具 举报

本版积分规则

APP下載|手机版|爱牧夫天文淘宝店|牧夫天文网 ( 公安备案号21021102000967 )|网站地图|辽ICP备19018387号

GMT+8, 2024-12-22 22:58 , Processed in 0.091535 second(s), 6 queries , Gzip On, Redis On.

Powered by Discuz! X3.5 Licensed

Copyright © 2001-2020, Tencent Cloud.

快速回复 返回顶部 返回列表