I'm still working on getting this into VR format, but as that's hitting a wall for the moment, here it is conventional format. These are the 30,087 galaxies from the complete ALFALFA catalogue, detected in neutral hydrogen but here showing their optical components. The images are to scale (with a few that are wildly inaccurate) but exaggerated in size by a factor 50. More details here.
Minor adjustments : I'm using ALFALFA's estimate of distance, which is more sophisticated than just using the redshift directly. For size I'm no longer using the Petrosian radius thingy from the SDSS as that's crap, but assuming a constant surface density for the hydrogen instead. Works much better, though it still fails from time to time so you'll see a few clipped images. That probably happens if the galaxy has much less gas than normal.
The VR format has hit a frustrating point. The standard version (below) is easy and fast to render. The VR one requires Cycles, which does this really stupid synchronising objects and loading images thing that's much, much slower than the actual rendering process. By default it takes about 6 minutes to prepare and then about three seconds to render. By some clever tricks I've got that down to 2 minutes. Normally I'd throw that on to my beefy work machine and let it chug away for a while, but that's not possible here. I need Blender 2.79 for this, as previous versions limited the number of image textures to 1024. Can't run that version on my work computer as 2.79 is compiled against an updated version of glibc which means I'd have to update the OS. Can't render in passes either as for some reason, GOD KNOWS WHY, images with transparent backgrounds don't render correctly in Cycles.
These things were sent to try us...
https://www.youtube.com/watch?v=qyaeGfMgqn0&feature=youtu.be
Subscribe to:
Post Comments (Atom)
-
In the last batch of simulations, we dropped a long gas stream into the gravitational potential of a cluster to see if it would get torn... -
Another day, another paper on how exciting Ultra Diffuse Galaxies are. At first, these large, faint galaxies were just wholly unexpected, a...
-
Of course you can prove a negative. In one sense this can be the easiest thing in the world : your theory predicts something which doesn...
That’s amazing! Wow.
ReplyDeleteVery nice!
ReplyDelete...though of course the truncated textures in some instances are distracting. I didn't quite follow how the size estimate triggers that; a scaled rectangle is a scaled rectangle, is it not? Or were you referring to the near/far clipping planes?
Regardless, I've had occasional trouble finding good, untruncated images even of popular, nearby galaxies like M-51, so I totally sympathize.
(s/though/throw/, s/KNOW/KNOWS/)
Greg Roelofs Typos fixed, thanks.
ReplyDeleteThe texture truncation happens because I don't have a very accurate estimate of the optical size of each galaxy. Instead I make an estimate based on the HI mass provided by the ALFALFA catalogue and assuming a constant HI surface density. That determines the size of the image obtained from the SDSS, which is sometimes too small. Not really anything I can do about that. It works a lot better than using the SDSS's own size estimate, at least.
Oh, and for the Virgo cluster, I had more accurate size estimates from the VCC. But I still had to do things the hard way, manually photoshopping out foreground stars, background galaxies, and various other image artifacts. With 781 galaxies this... wasn't fun.
ReplyDeleteI won't be doing that again. :P
youtube.com - Virgo Tour.mpg
Rhys Taylor Ohhhh, OK, I think I see now. If the automatic size estimate matches the visual appearance, then it fits on the poly just fine. If it's 2x wrong in one direction, you end up with a tiny image in the middle of the poly, maybe with some extraneous junk at the edges; if it's 2x in the other direction, it overflows the polygon and gets truncated.
ReplyDeleteSo in principle, if these were all field galaxies with minimal foreground and background noise, you could just double or quadruple the size of the polygon and scale down the texture correspondingly, and then you'd never get truncation of the intended galaxy. But in practice you'd bring in more foreground stars or neighboring/background galaxies, and many of those would get truncated instead.
And yes, I can imagine the tedium for Virgo. Very impressed you went to such lengths!
Pretty much. The size of the poly is determined in the same way as the size of the image to download though. If the calculated image size is too small, only the central region will be displayed but that central region will be at the correct size. So if the region is 2 kpc across, it will be shown as 2 kpc across, but the other 8 kpc (say) of the galaxy will be missing. The images always completely fill the polygon.
ReplyDeleteHere's an example :
http://skyserver.sdss.org/dr13/en/tools/chart/image.aspx?ra=188.584518343161&dec=8.19800244174534&width=64&height=64&scale=0.4
What I do is keep the image resolution constant at 0.4" per pixel. If this galaxy were shown as above, you'd see its nucleus at the correct size but nothing else. To show the rest at the same resolution needs a pixel dimension of 1500x1500 or so.
Rhys Taylor Gotcha! In terminology I'm more familiar with, you're trying to estimate the right viewport size to capture the visual extent of an object but no more and no less. The viewport is on a whole-sky virtual texture at your specified angular resolution. Picking the viewport to be even a little too big in this particular case (1600x1600) brings in three moderately large background galaxies and a whole bunch of smaller ones and foreground stars.
ReplyDeleteThanks! I've actually never searched a catalog for pixel data, only coordinates and other metadata, so this was illuminating. Such things didn't exist back when I was a wee lad...