Wrong value of proper motion for some stars

[Nick Fedoseev]

0.13.1.90
All stars are drawn shifted by 15 years in time. Drawn star positions "now" are actually positions for year 2000.
Seems somewhere time delta (J2000-Jnow) is missed, as there is a similar bug regarding ecliptic line.

Note: I found that while preparing a new image set for nebulae.
Ask for sample if needed.

[Alexander Wolf (alexwolf)]

I can't reproduce the issue. Please give details.

[Nick Fedoseev (nick-ut2uz)]

In attached textures.json original "m33bousquet.png" is replaced with new "M33.png" (also attached)

Go to M33, click F5 and play with years.

[Nick Fedoseev (nick-ut2uz)]

Forgot to say, the image was made last summer.

[Alexander Wolf (alexwolf)]

Equatorial grid for the date is enabled. One star was selected and date near J2000 was set. All stars on correct places.

[Alexander Wolf (alexwolf)]

Same place, but for current date - some bright stars shifted from J2000 positions. Of course, texture was not distorted for current date. Where is errors for stars positions?

[Alexander Wolf (alexwolf)]

I think I understood the bug report now - textures.json use J2000 coordinates for points, not JNow. For texture, who was calibrated for the J2000 position, she will be on the correct place for J2000. If you want show the texture on the correct place for other date (e.g., on the date, when picture was taken), then you should recalculate coordinates to J2000 epoch.

[Nick Fedoseev (nick-ut2uz)]

Unfortunately, not.

The image is calibrated for J2000 coordinates. And most of stars are OK, since their apparent movement speed is near zero. In case of calibration by JNow, the error will be for all stars and much much greater.

Stellarium calculates star positions very nice except of time shift.

If we set year 2000, we see star positions for JNow. That image is just a fast method to investigate the problem. It can be verified with special astronomic tools as well, with the same result, but requires more time. Since there is a similar problem with ecliptic line, it looks like there is an extra shift (Jnow-j2000) in time used for some astronomic calculations.

[Alexander Wolf (alexwolf)]

You are wrong :)

Why you want get correct position of stars on the picture for JNow, if you "moved" coordinates for those stars to the J2000 epoch? Or, in other words, you marked JNow coordinates as a J2000 coordinates.

[Alexander Wolf (alexwolf)]

Oh, I forget say - ecliptic line is drawn for J2000 epoch.

[Nick Fedoseev (nick-ut2uz)]

See attached image for date when image was taken.
Red arrows point run stars.
Green arrows point still ones.

[Nick Fedoseev (nick-ut2uz)]

And this is the same picture but for 2000/1/1

[Alexander Wolf (alexwolf)]

You are taken the picture in J2014 epoch, but why you mark those coordinates as J2000 epoch without any calculations?

[Alexander Wolf (alexwolf)]

Давайте я по-русски еще напишу - исходя из Вашего имени я предполагаю, что русский Вы знаете, а мой английский оставляет желать лучшего. Итак, фотография M33 была сделана крайним летом (эпоха J2014.6 я предполагаю), соответственно, все звёзды на ней имеют координаты этой эпохи. Эти координаты нельзя просто обозначить как координаты эпохи J2000.0, потому что это появится ошибка из-за вполне объективных причин: собственного движения звёзд, нутации и прецессии. Правильно будет редуцировать эти координаты на эпоху J2000.0 и уже потом "привязывать" текстуру к небу, чтобы на момент действительной съёмки фотографии звёзды были на своих местах.

[Nick Fedoseev (nick-ut2uz)]

Why without calculations? J2014.8 coordinates of the picture were transformed to J2000 for json script. Coordinates were verified with Aladin and Astronometry.net
As you can see, still stars are matched. That's impossible if wrong epoch were given.

Base coordinates are OK in Stellarium. Still (far) stars are drawn properly.
The bug is somewhere in star movement calculation for close stars.

[Alexander Wolf (alexwolf)]

Stellarium can't move stars on the pictures.

[Nick Fedoseev (nick-ut2uz)]

After deep investigation, which required installation and compiling from source, I found that the problem is not with epoch, but wrong proper motion values for Star2 type objects. The bug is fixed, the patched file is attached.

Thanks to Alexander Wolf for nice assistance.

[Alexander Wolf (alexwolf)]

Nick, where is patch? :)

[Nick Fedoseev (nick-ut2uz)]

I was sure that this was attached to the previous message

[Nick Fedoseev (nick-ut2uz)]

В предыдущем сообщении галочку [V] solution/patch галочку проставил, видимо какой-то фильтр бортанул этот файл, ибо формально не патч.

[Nick Fedoseev (nick-ut2uz)]

Just trying the same in patch form
Which is easier to use?

[Alexander Wolf (alexwolf)]

A fix has been committed as revision 7210 of the trunk branch of Stellarium's Bazaar repository at Launchpad: http://bazaar.launchpad.net/~stellarium/stellarium/trunk/revision/7210

Thanks, Nick!