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