问题标签 [astronomy]

尝试使用 PyEphem 计算太阳经纬度，但与星历不匹配
SUN: 2011 MAY 04 We 04 14:46:08 13TA12 = 43 度左右（根据网站 www.findyourfate.com）

有什么问题？如何计算行星/太阳的经度。Helio/地心。

我正在编写一个平均/组合/堆叠一系列曝光的应用程序。这通常用于减少生成图像中的噪声。

然而，似乎为了优化平均/堆栈，通常首先对曝光进行归一化。这个过程似乎为每个曝光分配了权重，然后将它们组合起来。我猜测该过程会计算每个图像的整体强度，因为目的是匹配堆栈中所有图像的强度。

我的问题是，我怎样才能结合一个算法来规范化一系列图像？我想这个问题可以通过问“我如何标准化一系列读数？”来概括。

我脑海中出现的一个轮廓如下：

• 计算参考图像的平均值。
• 将每个帧的平均值除以参考帧的平均值。
• 每次除法的结果就是每一帧的权重。
• 将帧中的每个像素缩放/乘以为该特定帧找到的权重。

这对任何人来说似乎都有意义吗？在过去的一个小时里，我试图用谷歌搜索，但没有找到任何东西。还查阅了亚马逊上各种图像处理书籍的索引，但也没有任何结果。

我正在使用 Java 和 Java3D 构建一个可以“飞行”通过的相对简单的银河系模型。

到目前为止，我有一个简单的版本，可以读取 40,000 个已知恒星并将它们（通过键盘+鼠标导航）显示为 Sphere 对象。然而，有几个问题阻碍了进一步的进展。

我正在努力解决的一个问题是我需要根据它们的视星等来渲染恒星，这是恒星绝对亮度（对数标度）和它与观察者的当前距离的函数。视星等非常低的恒星（例如从地球轨道上看到的比邻星）应该是不可见的，而极亮的恒星（例如天津四）即使在距地球相对较大的距离处也应该是可见的。

所以我不能仅仅根据它们固定的“实际”大小和它们与当前观测位置的距离来显示星星。这会导致即使是非常暗淡的近距离恒星也会出现巨大的斑点，而像天津四这样异常明亮的恒星由于距离太远而根本不会显示。

问题是，如何在不动态分配和删除 Java3d 对象的情况下根据其视星等表示恒星的图像，视星等根据其与当前视点位置的距离而变化？或者，如果我必须在渲染开始后更改 Java3D 中的对象，我怎样才能在不降低帧速率的情况下做到这一点？

我试过使用透明度；这只会让巨大的圆圈更难看到。我试过使用雾，但它完全模糊了遥远的星星（和星座线）。我尝试将 Spheres 转换为 Shape3D 对象，但这会占用两倍的堆空间。

一个快乐的特例是我不需要显示任何视星等大于 7.00 的恒星，因为人眼看不到它们。理论上，我应该只需要根据我在空间中的当前位置为我能看到的任何东西生成一个 3D 对象。与为数据库中的每个星形创建一个 Sphere 对象相比，这不仅可以提高性能，还可以帮助我避免用完 Java 堆空间。（我有超过 100,000 颗真正的星星想要包括在内，但是在 40,000 颗之后我的堆空间已经用完了，而且我尝试过的任何 Java 设置都没有给我更多的堆空间。）

我知道这种星光亮度的动态显示是可能的。卓越的 Space Engine 模拟程序的创建者做到了（并且设法获得每秒 60 帧）。我一辈子都想不通他是怎么做到的。

我完全希望我已经达到了我幼稚实现的极限，并且获得可接受的性能和功能的唯一方法是重新设计整个显示概念。我很想看到一些关于如何使用 Java3D 进行动态对象可见性的具体答案，但在这一点上，我将满足于专家的推测。（我不想放弃 Java3D，但我也愿意接受那里的具体建议。）

我很难找到天空中星星的当前坐标（RA，DEC）。在网上我发现只有这一个教程，如何使用 ephem 库：http ://asimpleweblog.wordpress.com/2010/07/04/astrometry-in-python-with-pyephem/

据我了解，我需要：

1. 创建观察者

1. 在这里创建一个主体对象星很麻烦，我只有（RA，DEC）星坐标

2. 通过 .calculate(now()) 计算位置

3. 通过新坐标找到高度

关于这个库的准确性的另一个问题，它有多准确？我比较了这个程序和 kstars 之间的 juliandate 和 sidestreal time，看起来非常相似。

这个http://www.jgiesen.de/astro/astroJS/siderealClock/

PS！或者可能有人可以为此目的推荐更好的库。

我正在编写一个 Python 程序，该程序需要确定它是否是日出后，只给定当前的 UTC 时间和目标纬度和经度。我看到应用程序一直在做这种事情，但我不知道它是如何完成的。有任何想法吗？

我查询了 PyEphem 模块给出的与 Observer() 查询相关的结果以及海拔的影响。我从几个来源（例如http://curious.astro.cornell.edu/question.php?number=388）了解到观察者的高度对日落时间有显着影响。但是在下面的代码中，我看到几乎没有区别：

我得到输出：

我相当确定我做错了什么而不是这是一个错误，但是尝试了许多不同的方法后，恐怕我总是会得到相同的结果。有谁知道我在这里做错了什么？

我已经在https://launchpad.net/pyephem上发布了这个，但我没有任何回应。我希望我没有从根本上误解了高程函数的目的......

我正在尝试改进美国海军天文台计算太阳位置的算法，方法是以更简单的方式编写它，其中所有使用的数字都已正确识别 - 所以普通人也可以理解它。

但不知何故，时间等式偏离了 27 天。也许这里有人可以发现问题所在？

测试运行：

新算法：

谢谢！

垫子

如何在特定日期使用 PyEphem 计算星星的位置。我写了代码，但它只在今天计算

感谢帮助

这个问题在三年多以前就有人问过了。给出了一个答案，但是我在解决方案中发现了一个小故障。

下面的代码在 R 中。我已经将它移植到另一种语言，但是直接在 R 中测试了原始代码，以确保问题不在于我的移植。

我遇到的问题是它返回的方位角似乎是错误的。例如，如果我在（南）夏至 12:00 对位置 0ºE 和 41ºS、3ºS、3ºN 和 41ºN 运行该函数：

这些数字似乎不正确。我对海拔高度感到满意——前两个应该大致相同，第三个稍微低一点，第四个要低得多。然而，第一个方位角应该大致是正北，而它给出的数字是完全相反的。其余三个应该大致指向正南，但只有最后一个指向。两个在中间点就在北边，再次向外 180 度。

如您所见，低纬度地区也触发了一些错误（靠近赤道）

我相信故障出在本节，在第三行（以 开头elc）触发了错误。

我用谷歌搜索并在 C 中找到了类似的代码块，转换为 R 用于计算方位角的行类似于

这里的输出似乎正朝着正确的方向前进，但是当它转换回度数时，我无法让它一直给我正确的答案。

更正代码（怀疑只是上面的几行）以使其计算正确的方位角会很棒。

这看起来是一项非常基本的任务，但我无法解决。

PyEphem 文档：

http://rhodesmill.org/pyephem/radec.html

描述了如何以相反的方式执行转换，从一个Body和一个Observer对象到表观地心位置，在.alt和.az属性中具有仰角和方位角。

但是，我应该如何从 Elevation 和 Azimuth 开始并获得 RA 和 Dec？

例如，这是我想在赤道参考系中获得 RA 和 Dec 的一组坐标：

谢谢！