[Kstars-devel] Kstars-devel Digest, Vol 35, Issue 16
brian hurren
brianhurren at yahoo.com
Sun Jun 18 10:41:31 CEST 2006
Can you add other star catalogues to kstars? and there are people at the astro society who want to know if you can get it on windows? and also when your pointer is over a blank piece of sky can you still acces internet links with the right mouse button, like for example when you are in say scorpio and you are pointing at a blank point in the sky can you access info about scorpio? wikipedia have some very good articals about the 88 constellations.
kstars-devel-request at kde.org wrote: Send Kstars-devel mailing list submissions to
kstars-devel at kde.org
To subscribe or unsubscribe via the World Wide Web, visit
https://mail.kde.org/mailman/listinfo/kstars-devel
or, via email, send a message with subject or body 'help' to
kstars-devel-request at kde.org
You can reach the person managing the list at
kstars-devel-owner at kde.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Kstars-devel digest..."
Today's Topics:
1. Re: XYZ Rotation matrix in 3.5.x (Jason Harris)
2. Release of INDI Library v0.4 (Jasem Mutlaq)
3. Re: XYZ Rotation matrix in 3.5.x (James Bowlin)
4. Re: XYZ Rotation matrix in 3.5.x (James Bowlin)
5. Re: XYZ Rotation matrix in 3.5.x (James Bowlin)
6. Re: XYZ Rotation matrix in 3.5.x (James Bowlin)
----------------------------------------------------------------------
Message: 1
Date: Thu, 15 Jun 2006 08:35:55 -0700
From: Jason Harris
Subject: Re: [Kstars-devel] XYZ Rotation matrix in 3.5.x
To: James Bowlin , KStars Development Mailing
List
Message-ID: <200606150835.56322.kstars at 30doradus.org>
Content-Type: text/plain; charset="iso-8859-1"
Hello,
Sorry I'm coming late to this thread. A couple of things I want to note:
+ It looks like you've implemented your own XYZ system for skypoint
("skyP->cx")...did you know that I already added XYZ members to SkyPoint in
trunk?
+ I don't think we need a function like slowToScreenXYZ() to compute the
rotation matrix. The matrix elements can be derived directly from the RA/Dec
of the Focus point:
Rotation about z-axis (i.e., rotation to bring Focus point's RA to center of
projection):
cos(RA) 0 sin(RA)
0 1 0
-sin(RA) 0 cos(RA)
Rotation about x-axis (i.e, rotation to bring Focus point's Dec to center of
projection):
1 0 0
0 cos(Dec) -sin(Dec)
0 sin(Dec) cos(Dec)
+ The code to convert from RA/Dec to Az/Alt is already in
SkyPoint::EquatorialToHorizontal(), commented out. I did some timing tests
of it just now, compared to the existing spherical trig method. To isolate
the codepath, I added a loop over the Stars which only calls
EquatorialToHorizontal() for each one, and bound this code to a key.
It also prints out the elapsed time for the loop.
In this case, I see no difference at all between the two methods! Both take
30 ms, on average. There's some extra overhead in the XYZ method, because I
redefine the rotation angles for each object, when these should only be done
once. So there are two extra SinCos() calls. Still, not a huge savings, I
think.
regards,
Jason
On Thursday 15 June 2006 02:21, James Bowlin wrote:
> On Thursday 15 June 2006 02:10, Luciano Montanaro wrote:
> > Well, a 20% improvement is not something to sneeze at. Maybe it's not
> > sufficient to visibly improve things, but it may be one of the needed
> > optimizations.
>
> There is some added expense/baggage using the rotation matrix. First,
> each SkyPoint needs storage space for 3 more doubles, the x-y-z. Also,
> in the simple way I implemented it, it does not work for AltAz coordinates.
> It is possible that this could be fixed by recalculating the x-y-z
> coordinates for all SkyPoints. But these would then need to get updated
> (I think). Also, I don't know how to deal with refraction correction.
>
> If it didn't come with this extra baggage, then I would have suggested that
> we adopt it. If it had given us a factor of 2 or 3 speed improvement then
> I would have argued that the extra expense would be worth it. But as it
> stands now, I think our efforts would be better spent elsewhere. But I
> don't have strong feelings about it. If other people want this code in
> the 4.0 trunk, I would be happy to help port it.
>
> > > So it appears that modern processors can do simple sin() and cos()
> > > calculations almost as fast as multiplication. This implies that there
> > > is probably not much speed boost from caching sin() and cos() values,
> > > at least for modern processors.
> >
> > Are you sure the speedup is not masked by the overhead of function calls?
> > Maybe the toScreen function should be inlined.
>
> This is possible. It could also be masked by the time it takes to do the
> actual drawing on the screen. The times roughly doubled when I switched
> from outline mode to filled mode for drawing the Milky Way. I'll try
> inlining and see if that makes any difference.
>
> > Also in the toScreen function, you evaluate
> >
> > double Width = ( width() * screen_scale );
> > double Height = ( height() * screen_scale );
> >
> > each time, while it is a value which will not change between invocations.
> > (You could actually cache Width * 0.5 and Height * 0.5, from what I see.
>
> Good idea. But I don't expect this change to give us a startling speed
> boost.
>
> > Obviously, these optimizations will not do much good if the problem is
> > the function call overhead anyway.
> >
> > > For completeness, I've included the new code below. Only the first two
> > > routines are new. 98% of slowToScreenXYZ() came from the original
> > > toXY(). Maybe there is a more efficient way of doing the matrix
> > > calculation, making use of the SSE registers or something. I tried
> > > removing the sqrt() from both branches but this didn't significantly
> > > alter the timing results.
> >
> > Maybe. But vector instructions works best if you feed them with, well,
> > vectors, so probably it should be better to ave a function to iterate
> > over a vector of coordinates.
>
> I can give this a try by putting the celestial x-y-z values in an array and
> also put the nine rotation coefficients in an array (or an array of
> arrays). But I doubt that the compiler is being given the flags that tell
> it to use the SSE registers. Usually this sort of thing is hand-coded but
> maybe compilers have advanced so far that they are now good at this sort of
> thing. But you did remind me, I remember working on some code like this
> about 15 years ago and there was a mild speed boost when the data was put
> into arrays.
>
> Thanks for the comments Luciano. You have made me realize that I should
> probably run a few more tests: inlining toScreen(); caching the Width and
> Height; using arrays for the matrix evaluation; and also running a test
> that just calls toScreen() and toXY() repeatedly to eliminate masking due
> to the drawing functions.
>
> I had been hoping that this might be a quick "end around" the speed
> problems in the 4.0 code that would make it more responsive and thus a more
> user friendly development platform. Unless I've made a mistake (or a
> series of mistakes) it doesn't look like that is going to happen.
--
KStars: http://edu.kde.org/kstars
Community Forums: http://kstars.30doradus.org
------------------------------
Message: 2
Date: Thu, 15 Jun 2006 11:38:56 -0700 (PDT)
From: Jasem Mutlaq
Subject: [Kstars-devel] Release of INDI Library v0.4
To: kstars-devel at kde.org, indi-devel at lists.sourceforge.net
Message-ID: <20060615183856.78936.qmail at web35701.mail.mud.yahoo.com>
Content-Type: text/plain; charset=iso-8859-1
Hello,
INDI Library v0.4 has been released today.
The new release adds support for several devices,
including:
- SBIG CCD
- SBIG CFW
- FLI Precision Digital Focuser
- RoboFocus
- SkyScan/SkyAtlas
- Argo Navis DTC
Furthermore, this release fixes a number of bugs. For
a complete overview, please checkout the ChangeLog.
I'd like to thank all of those who made this release
possible:
- Elwood Downey
- Jan Soldan
- Markus Wildi
- Bruce Bockius
- Doug Phillipson
- Brian Crook
- Ken Hough
Homepage: http://indi.sf.net
Regards,
Jasem Mutlaq
------------------------------
Message: 3
Date: Thu, 15 Jun 2006 13:57:24 -0600
From: James Bowlin
Subject: Re: [Kstars-devel] XYZ Rotation matrix in 3.5.x
To: Jason Harris
Cc: KStars Development Mailing List
Message-ID: <200606151357.25004.bowlin at mindspring.com>
Content-Type: text/plain; charset="iso-8859-1"
On Thursday 15 June 2006 09:35, you wrote:
> + It looks like you've implemented your own XYZ system for skypoint
> ("skyP->cx")...did you know that I already added XYZ members to SkyPoint in
> trunk?
Yes, I knew that. It was one of the reasons I did my experiment in the 3.5
branch. I didn't want to pollute your work in the trunk.
> + I don't think we need a function like slowToScreenXYZ() to compute the
> rotation matrix. ?The matrix elements can be derived directly from the RA/Dec
> of the Focus point: [rotation matrices snipped]
That's fine. My use of slowToScreenXYZ() was based 100% on laziness.
I was taught matrix math in my first year in college but unfortunately,
the hot-shot teacher defined matrices backward from the standard conventions.
This created a confusion in me that lingers to this day.
It could have taken me several days to create the rotation matrix from
scratch. The slowToScreenXYZ() method allowed me to treat the rotations
and scaling as a "black box".
> + The code to convert from RA/Dec to Az/Alt is already in
> SkyPoint::EquatorialToHorizontal(), commented out. ?I did some timing tests
> of it just now, compared to the existing spherical trig method. ?To isolate
> the codepath, I added a loop over the Stars which only calls
> EquatorialToHorizontal() for each one, and bound this code to a key.
> It also prints out the elapsed time for the loop.
>
> In this case, I see no difference at all between the two methods! ?Both take
> 30 ms, on average. ?There's some extra overhead in the XYZ method, because I
> redefine the rotation angles for each object, when these should only be done
> once. ?So there are two extra SinCos() calls. ?Still, not a huge savings, I
> think.
This is good to know. It sounds like we are in agreement that the XYZ method
is not going to be a big win for us. I was very surprised by this result and
I am glad to see that wasn't just due to a stupid mistake on my part.
I thought that the rotation matrix was a terrific idea. I still do. I was
hoping that it would make the 4.0 code faster than 3.5 in one fell swoop.
But it seems that my intuition about the relative speeds of sin() and * was
way off.
Where do we go from here? I feel torn between helping to speed up 4.0 and
porting the Milky Way clipping to 4.0. Maybe something as simple as enabling
the Solar System toggle will be enough to make 4.0 more usable for my testing.
Here are my current 4.0 times:
kstars: Milky Way : 8 ms
kstars: Coord grid : 125 ms
kstars: Cons Bound : 76 ms
kstars: Cons Lines : 8 ms
kstars: Cons Names : 69 ms
kstars: Equator : 59 ms
kstars: Ecliptic : 7 ms
kstars: Deep sky : 59 ms
kstars: Custom cat : 0 ms
kstars: Stars : 173 ms
kstars: Solar sys : 162 ms
kstars: Name labels : 0 ms
kstars: Horizon : 54 ms
Most of the slower things (except the Solar System) I can turn off via the
toggles.
One thing that strikes me is that the coord grid, the equator, and the
horizon all seem to be taking a lot of time. Here, they take 238 ms
combined which is more than either the Solar System or the stars.
They each take much longer than the Milky Way (which was fully present
when I did the timing above). Perhaps this will point us to what is
taking so long.
I've also noticed some little blips on the equator line and on some of
the grid lines that I don't see in the 3.5 version. The equator has
a blip where it crosses the horizon line, almost like on an older schematic
diagram that indicates that wires cross but do not connect. I also note
similar blips on the grid lines of constant ra near dec = 77 degrees.
Maybe this would also give us a clue to what is going on.
--
Peace, James
------------------------------
Message: 4
Date: Thu, 15 Jun 2006 14:24:26 -0600
From: James Bowlin
Subject: Re: [Kstars-devel] XYZ Rotation matrix in 3.5.x
To: Jason Harris
Cc: KStars Development Mailing List
Message-ID: <200606151424.27520.bowlin at mindspring.com>
Content-Type: text/plain; charset="iso-8859-1"
On Thursday 15 June 2006 14:05, you wrote:
> On Thursday 15 June 2006 12:57, James Bowlin wrote:
> > kstars: Milky Way ?: 8 ms
> > kstars: Coord grid : 125 ms
> > kstars: Cons Bound : 76 ms
> > kstars: Cons Lines : 8 ms
> > kstars: Cons Names : 69 ms
> > kstars: Equator ? ? : 59 ms
> > kstars: Ecliptic ? ?: 7 ms
> > kstars: Deep sky ? ?: 59 ms
> > kstars: Custom cat ?: 0 ms
> > kstars: Stars ? ? ? : 173 ms
> > kstars: Solar sys ? : 162 ms
> > kstars: Name labels : 0 ms
> > kstars: Horizon ? ? : 54 ms
> >
> Are these with AA on or off? ?I see times similar to this with AA drawing, but
> when I turn it off, they get much much smaller. ?I had assumed that the grid
> and other lines took a long time, only because it's antialiasing the lines.
Those are with AA off, the KStars window is at about 1400 x 1200 and the whole
(half) celestial sphere is in view. Here are the numbers with AA turned on:
kstars: Milky Way : 818 ms
kstars: Coord grid : 1229 ms
kstars: Cons Bound : 0 ms
kstars: Cons Lines : 156 ms
kstars: Cons Names : 22 ms
kstars: Equator : 105 ms
kstars: Ecliptic : 71 ms
kstars: Deep sky : 165 ms
kstars: Custom cat : 0 ms
kstars: Stars : 3214 ms
kstars: Solar sys : 683 ms
kstars: Name labels : 0 ms
kstars: Horizon : 71 ms
The coordinate grid number reflects the change I made below that made
a big improvement in the speed. The original code was drawing 1440
points per grid line of constant Declination.
Index: skycomponents/coordinategridcomponent.cpp
===================================================================
--- skycomponents/coordinategridcomponent.cpp (revision 551265)
+++ skycomponents/coordinategridcomponent.cpp (working copy)
@@ -38,7 +38,7 @@
emitProgressText( i18n("Loading coordinate grid" ) );
if ( Parallel ) { //line of constant Declination
- double dra = 1./60.; //90 points around full circle
+ double dra = 1./5.; //120 points around full circle
for ( double ra=0.0; ra < 24.0; ra += dra ) {
SkyPoint *sp = new SkyPoint( ra, Coordinate );
sp->EquatorialToHorizontal( data->lst(), data->geo()->lat() );
--
Peace, James
------------------------------
Message: 5
Date: Thu, 15 Jun 2006 16:07:38 -0600
From: James Bowlin
Subject: Re: [Kstars-devel] XYZ Rotation matrix in 3.5.x
To: kstars-devel at kde.org
Message-ID: <200606151607.38857.bowlin at mindspring.com>
Content-Type: text/plain; charset="iso-8859-1"
On Thursday 15 June 2006 12:57, James Bowlin wrote:
> kstars: Coord grid : 125 ms
> kstars: Equator ? ? : 59 ms
> kstars: Horizon ? ? : 54 ms
The previous patch for skycomponents/coordinategridcomponent.cpp dropped
the time down for the coordinate grid down to about 10 ms.
I looked at the equator code and found that the big time consumer there
is drawing the label in the rotated coordinate system. At the bottom
of skycomponents/equatorcomponent.cpp there is the following code:
psky.save();
if ( Options::useAntialias() )
psky.translate( o.x(), o.y() );
else
psky.translate( int(o.x()), int(o.y()) );
psky.rotate( double( angle ) ); //rotate the coordinate system
psky.drawText( 0, 0, i18n( "Equator" ) );
psky.restore(); //reset coordinate system
}
}
If I comment out either the psky.rotate() or the psky.drawText() then the
time drops from over 50 ms down to under 5 ms. I don't have the detailed
timing code in my 3.5 branch so I can't immediately see if it also requires
50 ms to draw rotated text but this time seems excessive to me. I think
we could do it ourselves 10 times or more faster by drawing the text in
a way that is similar to the way we draw the Milky Way. My guess is that
this is something that might get improved upstream.
In the meantime, if we just skip rotating the labels for the equator and
the horizon, we can probably save over 100 ms or so per draw cycle (on
my 1.6 GHz laptop).
--
Peace, James
------------------------------
Message: 6
Date: Thu, 15 Jun 2006 18:46:35 -0600
From: James Bowlin
Subject: Re: [Kstars-devel] XYZ Rotation matrix in 3.5.x
To: kstars-devel at kde.org
Message-ID: <200606151846.36620.bowlin at mindspring.com>
Content-Type: text/plain; charset="iso-8859-1"
On Thursday 15 June 2006 16:07, James Bowlin wrote:
> In the meantime, if we just skip rotating the labels for the equator and
> the horizon, we can probably save over 100 ms or so per draw cycle (on
> my 1.6 GHz laptop).
I commented out the psky.rotate() in the horizon code but drawing the horizon
still takes 36 ms on my system with AA turned off. The funny thing is that
the time drops to 2 ms when showGround() is on. If anything, I would have
expected the opposite behavior where it took longer to do the fill than to
do the outline.
What is even more strange is that sometimes the outlined horizon will draw
in 2 ms depending on the zoom factor. I usually use the mouse wheel to
change the zoom in order to force a redraw. But if I stick with one zoom
level and just hit "X", the timing seems pretty consistent, either 2 ms
or 36 ms depending on the zoom level. The slow drawing seems to happen
when the horizon line on the bottom of the celestial sphere is partially
clipped by the bottom of the kstars window.
In summary:
filled horizon: always fast
outlined horizon: sometimes slow depending on zoom level (clipping?).
--
Peace, James
------------------------------
_______________________________________________
Kstars-devel mailing list
Kstars-devel at kde.org
https://mail.kde.org/mailman/listinfo/kstars-devel
End of Kstars-devel Digest, Vol 35, Issue 16
********************************************
---------------------------------
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail Beta.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kstars-devel/attachments/20060618/71bc1e9e/attachment-0001.html
More information about the Kstars-devel
mailing list