I have noticed that the January 1, 2007 Cassini PDS release is already available, see http://pds-imaging.jpl.nasa.gov/data/cassi...assini_orbiter/

I haven't downloaded all of the imaging data and I'm just beginning to digest what I already have but there are some beautiful images of Enceladus' plumes and satellite mutual events, images of the G and D rings and interesting images of Saturn's nightside and fairly good Iapetus images.

Radar and VIMS is also available.

All in all a nice 'Christmas gift' .

Would love to see this!

This release covers the time period from January 1 to March 31, 2006. No RADAR SAR swaths were taken during this period of time. There were three Titan flybys: T10 (ORS covering anti-Saturnian hemisphere), T11 (ORS low-phase inbound over sub-Saturnian hemisphere), and T12 (ORS moderate phase over anti-Saturnian hemisphere). T11 has some good observations, never messed with T10 or T12 too much since it covered the same territory we had seen over and over again without adding to much new information.

Beyond Titan, there is a decent sequence at Enceladus from Rev20 (look for images in the N1516153055 through N1516171418 range). There are also decent Rhea observations during each orbit (Rev20-21-22). rev22 has some decent Rhea saturn-shine images. Finally, Rev21 has a couple of observations of Tethys over Penelope crater.

EDIT: actually, there was a distant SAR look on T12. I'll try to post that within an hour.

EDIT again...: and that isn't available yet. Hopefully it will be up by Monday.

Here's an 8 frame animation showing the late January 2006 "flyby" of Iapetus from this PDS batch. Closest approach was around 880 000 km.


Three of the frames are natural color RGB composites, the rest are stretched color IR/G/UV processed to match natural color views. Images have been magnified 2x for better visibility.

cool

Nice animation... Click to view attachment

More on Japetus there? What about the november 27th far-encounter in ~2 mio. km distance?

Bye.

Wow. That's a really good way to tie the Moat/Snowman region to eastern Cassini Regio. That's the first time I've noticed the large crater on the eastern edge of the Landslide Basin. And it's interesting that the claw marks are parallel to the tic-tac-toe ridges. (It really would be nice to have some official names for these features. )

Michael

November 2006? That won't hit PDS for another 9 or so months. By then the closest flyby ever will be over!

Jason, is that T12 SAR up yet?

--Emily

Not that I can see. It is possible that I was wrong and that there wasn't a distant SAR look on T12, but I could have swore they did.

(pointed here by Emily's post in another thread)

FWIW, the mission description only mentions radiometry/scatterometry (the obs mentioned in the data playback section are RADAR_022OT_WARM4TI12001_RIDER and RADAR_022TI_T12OUTRAD001_PRIME). I also found T12_SEQ_DESIGN_MEMO.PDF, which says:

The April 1, 2007 PDS release is out with new ISS, VIMS and RADAR data.

I have looked at all of the ISS images and updated my summary of Cassini images at http://www.mmedia.is/bjj/misc/css_stuff/im...s_overview.html.

I will soon be adding a list of flybys for each satellite near the top of the document ("a summary of the summary").

The ISS release wasn't particularly interesting to me this time. Some highlights:

* Images of Iapetus down to a range of ~600,000 km
* Two targeted flybys of Titan
* Many spectacular satellite mutual events since Cassini was very close to the ring plane
* Interesting images of Hyperion, Janus, Atlas and Pan
* Rhea global color at a range of ~480,000 km
* Many distant high phase images showing Enceladus' plumes
* Saturn star occultations

Incidentally, I ran into a few cases of erroneously formatted numbers in several of the index.tab files that caused some problems when loading these files into an Access database so I'm going 'complain' to the PDS. Example: 1.0524616e-
I suspect 'very small' numbers may get incorrectly formatted, possibly numbers smaller than 0.001 or 0.0001.

I could make the database available if someone can host it, it's too big for me to do so (about 55 MB zipped). It contains all of the information from all of the index.tab files on volumes COISS_1001 to COISS_1009 and COISS_2001-COISS_2023.

Is anyone having luck accessing the PDS site, namely http://pds-imaging.jpl.nasa.gov/? It's broken for me at least since yesterday.

No, no luck for me.

Same thing here. Fortunately I finished downloading the ISS data before this started .

http://pds-imaging.jpl.nasa.gov/data/cassi...assini_orbiter/ works fine for me right now.

Some highlights from my perspective are the T13 radar SAR swath (the one that crosses Xanadu) and the distant encounters with Janus and Pan.

Here's Janus, an approximately natural color view and enhanced stretched color to bring out subtle color differences:

Unlike Telesto which appears bluish in natural color and very faintly orangish in stretched color, Janus is more like other rocky moons -- Prometheus and Pandora. Magnified 2x.

After a bit of a tussle with the remote server I've managed to upload the file, so it's now hosted at:
http://filicio.us/tpss3/files/17314/cassini_images.zip

It's 55 MB and unzips to a 500-MB database. I'll let Bjorn chime in with any comments he'd like to make about it. For my part, I'll just thank Bjorn for assembing this whole thing -- and beg for the inclusion of the north_azimuth field that you calculated for some Saturn images for all the images in the next version of this database.

--Emily

A few comments:

This is a Microsoft Access database containing two tables, coiss and coiss_revised. Coiss simply combines all of the index.tab files on the Cassini ISS volumes 1001-1009 and 2001-2023 into a single database without any significant modifications, except for the rejection of erroneously formatted numbers (see the list of errors at the end of this message).

The coiss_revised table contains updated values for a few fields. These values are *probably* slightly more accurate (from my experience when doing a cylindrical map of Saturn) than the original values although I cannot completely guarantee this. They are computed from the latest SPICE kernels (CK and SPK). The NORTH_AZIMUTH value is also included as there's no equivalent field in the coiss table. At this time only a few images are included in coiss_revised. I don't know the exact geometric meaning of north_azimuth_clock_angle in the index.tab files but it is totally different from north_azimuth so I added north_azimuth in a separate table. However, I have only determined it for a few images (70 - mostly the ones I used to do a map of Saturn) but plan to do so for all of the images, possibly before the next batch of images gets released 3 months from now.

There are a few simple queries there as well that I decided to include as a simple example of what can be done.

I use this database extensively when searching for interesting and/or specific images, both from within Access and directly from programs I have written. I rarely use the PDS to search for images, I mainly use it to download entire data volumes.

As previously mentioned I found errors in some of the index.tab files. The errors I know of are:

coiss_2017: There are erroneously formatted floating point numbers in rows 1253-1257 in index.tab, columns 2541-2551 (SUB_SPACECRAFT_LATITUDE). I tried 'guessing' the correct values. These are images N1512191594_1.IMG, N1512191728_1.IMG, W1512191728_1.IMG, N1512191860_1.IMG and N1512191993_1.IMG.

coiss_2020: There are erroneously formatted floating point numbers in rows 170-171 in index.tab, columns 2628-2638 (TARGET_SOUTHERNMOST_LATITUDE). I fixed this manually - the fixed values are a guess and the correct value to use is uncertain. These are images N1517273822_1.IMG and N1517273855_1.IMG.

coiss_2021: There are erroneously formatted floating point numbers in rows 1980-1990 and 2648-2649 in index.tab, columns 2541-2551 (SUB_SPACECRAFT_LATITUDE). I fixed this manually - the fixed values are a guess and the correct value to use is uncertain. These are images W1520869299_1.IMG, N1520869388_1.IMG, W1520869388_1.IMG, N1520869616_1.IMG, W1520869616_1.IMG, N1520869705_1.IMG, W1520869705_1.IMG, N1520869934_1.IMG, W1520869934_1.IMG, N1520870023_6.IMG, W1520870023_1.IMG, W1521409807_1.IMG and N1521409944_1.IMG.

coiss_2023: There are erroneously formatted floating point numbers in rows 2785-2788 in index.tab, columns 2616-2626 (TARGET_NORTHERNMOST_LATITUDE). As previously I fixed this by trying to guess the correct values. These are images N1530372696_1.IMG, N1530372841_1.IMG, N1530372986_1.IMG and N1530373131_1.IMG.

There might be more errors.

Is there any sort of search capability in existence for any of the PDS ISS released products ??

For instance... if one wanted to look for NAC images where the boresite intersect was in the B-ring
and the range was under say 10 Rs ??? or where the target was PROMETHEUS and the range was under
1M km ??

my first impression is that the INDEX.TAB files *seem* to have some problems ... but perhaps I've not
gone thru enough documentation .... any pointers on documentation source would also be great !!

Thanks !!

I'd say the best thing to use to search would be Bjorn's database, referenced earlier in this thread. He's already got basic queries on some targets with ranges in there -- they'd be easy enough to modify to get your Prometheus-under-1Mkm search, but I don't know how you'll do the B-ring one.

Bjorn, if you update your database with the tables of info from the latest release I'll gladly host it for you.

--Emily

What tallbear wants to do should be trivial to do in my database, in fact the reason I made the database was that I wanted flexible search capabilities. The Prometheus-related query is trivial (there are similar sample queries I did in the database where the target is different but they illustrate how to do this).

The B ring query is probably easy as well although I should mention that I have not tried something like it (I'm on my laptop at the moment and the database is on my desktop computer so I cannot try it at the moment).

I didn't notice any problems with the INDEX.TAB files except for the ones mentioned in my April 3 message earlier in this thread. The database contains all of the fields/columns from all of the index files.


Great! I will be updating the database in early July following the July 1 PDS release. The updates can be imported into the database so I do not have to upload the database again in its entireity when I update it.

Cool... I'll try Bjorn's database....read over what it takes to get it up and running....
It's interesting that the Rings Node has really neat search capabilities for Voyager
images... but for Cassini ... it's unmannedspaceflight.com that's forging the way ....
...Thanks ... Great Work ... I'll get in and start nosing around...

The July 1, 2007 PDS Cassini release is starting to appear. The ISS and VIMS stuff is already there:

http://pds-imaging.jpl.nasa.gov/data/cassi...assini_orbiter/

So far I have downloaded only about 1500 ISS images and have looked at only a few of them but there's one particularly interesting imaging sequence in this release: The ISS data includes the famous imaging sequence showing Saturn and the rings backlit with the Earth visible as a tiny bright spot. That particular imaging sequence starts in directory data/1536725883_1537013377 on the coiss_2025 volume.

Cool!

I've been wanting to do something to make PDS Cassini images easier to find but this data set is way too big for me to do a complete treatment on it. Instead, I was thinking of producing an index page to all moon images where the moon spans more than N pixels. The thing is I haven't decided what N should be yet. 200? 100? 128? What's a good number? I'd probably use a different number for the major icy sats than for the ringmoons and Lagrange point moons. Any thoughts?

--Emily

Emily,

That would be pretty neat to see an index. From my perspective it sounds like you have some good numbers in mind. In the case for some of my maps I've used images getting down to just over 100-120 pixels, though most are over 200.

What would the diameter be for the middle of the disc to be 1 degree of latitude / pixel. That might be an appropriate figure to work from. My brain can't do the trig to figure it out

Doug

Maybe 115 pixels?

Yeah, it could be 115. 1/sin(0.5 deg).

I sketched my little diagrams and chanted "SOH CAH TOA" and worked it out and yes it came to 114.6 pixels. That sounds like a good plan. I'll put in >114.

I ran that in to Bjorn's database as of March and got the following numbers of images:
Mimas: 422
Enceladus: 623
Tethys: 749
Dione: 884
Rhea: 1584
Hyperion: 677
Iapetus: 2181
Phoebe: 383

These numbers are a little on the highish side...running it down to 200 pixels across, here's what I get:
Mimas: 327
Enceladus: 603
Tethys: 308
Dione: 600
Rhea: 1150
Hyperion: 496
Iapetus: 1061
Phoebe: 227

(Interesting how much of a hit Iapetus and Tethys take, while Enceladus is virtually unchanged!)

...and remember that that's less than 2/3 of the way through the mission. I'm kind of inclined to go with the higher number so as not to have mind-numbing quantities of images where the moons aren't very big, but if someone makes the case that I'll miss out on too many phase angles or mutual events I'll try it with the lower-res ones included.

I should also add that I'm not real excited about downloading 25 volumes and will be more excited about doing this if I can figure out how to use Bjorn's database to write batch files for wget that will only retrieve the files I want...we'll see!

--Emily

Screw it - go for 2 pixels / degree 230 pixels for cash.

Doug

I think it might be a good idea to limit this by resolution and not pixel size. A 115 (or 200) pixel diameter image of Mimas or Enceladus is usually much more interesting than a 115 pixel diameter image of Rhea unless you are interested in photometry. Another way of putting this: Make the size limit in pixels a function of satellite radius.

That's not a bad idea. Got any specific recommendations?

--Emily

Hm, taking Mimas as your 114 px baseline, that comes out to:

Mimas 114
Enceladus 140
Tethys 292
Dione 306
Rhea 417
Titan 1405
Iapetus 392

Assuming I'm not working with ridiculously antiquated figures here...

I now have the information on the just released Cassini images ready for getting added to the Access image database discussed earlier in this thread. That database includes everything up to and including the April 1, 2007 release. The files below add the images released on July 1, 2007.

Transferring the entire database file is an overkill so I prepared two Excel (!) files that can be imported into the database. The files are fairly small (less than 3 MB each). Emily has hosted them on the same server as the database:

http://filicio.us/tpss3/files/23158/cassin...es_index_24.zip
http://filicio.us/tpss3/files/23159/cassin...es_index_25.zip

In Access, do File -> Get External Data -> Import

What follows should be obvious, accept the defaults and when asked "Where would you like to store your data?" choose the table "coiss" in the list that appears next to "In an Existing Table:".

Thanks to Emily for hosting this together with the database.

A little comparison of Cassini's solar eclipse as seen by VIMS and ISS:
Click to view attachment
The leftmost image is a gamma-correct (2.2 gamma) mosaic of four VIMS cubes and is probably closest to what the human eye would see. The middle image is additionally brightened and saturation increased. The rightmost image is a crop from the famous CICLOPS mosaic. Neglecting massive VIMS noise in the visual channel, if you increase the saturation the CICLOPS and VIMS colors appear pretty similar.

Two short time-lapse sequences:

Three frames on the left show the opposition surge on part of the rings. Don't know which part though, probably A or B rings. The surge appears elongated probably because as VIMS was scanning the cube the opposition highlight moved. Also note ring darkening as phase increases.

The 5 frame sequence on the right was taken on 2006-08-18 and spans an hour and a half. Each VIMS scan took more than 10 minutes to read out. Noisy as hell. I removed most of the linear noise but it wasn't perfect and left some residuals as well as cosmic noise hits.

In addition to size, I think the relative abundance of available images could be a consideration. In this light, it's good for Rhea to have a larger number as there are quite a few hi-res images available. On the other hand, Iapetus has a relative scarcity of images so I would go lower - back to the 100-200 pixel range.

Titan makes sense to have a large threshold, partly as large images are needed to compensate for atmospheric blurring.

I'm returning to this project after a hiatus. I am now trying to figure out what information will be valuable to include in the browse pages. There is a huge number of fields available in the database. Here is what I am thinking about including; let me know if there are any fields I've missed that you can't live without.

FILE_NAME (e.g. W1481738172_2.IMG)
TARGET_NAME (e.g. DIONE)
TARGET_LIST (listed only if it is not "N/A" or identical to TARGET_NAME -- picks up other bodies that may be in frame, useful for mutual events)
OBSERVATION_ID (e.g. ISS_00BDI_GLOCOL001_PRIME) <-- note you get information on which rev you're on in this one
IMAGE_MID_TIME and IMAGE_MID_TIME_SEC_FRAC (e.g. 12/14/2004 5:30:21.716) -- is this OK or is START_TIME better?
PIXEL_SCALE (e.g. 9.3249958) <-- in km
TARGET_DISTANCE (e.g. 156875.92) <-- in km. this is redundant with the pixel scale but I think it's useful to show both.
PHASE_ANGLE (e.g. 34.258215) <-- in degrees
SUB_SPACECRAFT_LATITUDE and SUB_SPACECRAFT_LONGITUDE (e.g. 11.092879 and 207.90797) <-- I prefer this to the CENTER_LAT and CENTER_LON because I think it makes more sense for images where the entire body is contained somewhere within the FOV.
EXPOSURE_DURATION (e.g. 5600) <--need to state units
INSTRUMENT_MODE_ID (listed only if it's been 2x2 or 4x4 binned, "SUM2" or "SUM4")
INST_CMPRS_TYPE (LOSSY or LOSSLESS)

Some questions:
Can I get away with skipping INSTRUMENT_ID? Whether it's WA or NA will be clear from the file name.
Are EMISSION_ANGLE and INCIDENCE_ANGLE important, or is there enough information contained in PHASE_ANGLE?

--Emily

Instrument_ID isn't important if you are listing both WACs and NACs, and the file name is listed. That field is just useful as a search criteria, e.g. you want to retrieve NACs only.

Emission angle and incidence angle is important if the object more than fills the frame. Emission angle is important if you are looking for useful Titan images.

I just went through the process of creating an index page for Dione, using the 2 pixels per degree (=228 pixel diameter) size cutoff:
http://planetary.org/data/cassini/dioneattempt/
WARNING: to view this page requires you to download about 42 MB of data.
[Note: I didn't bother uploading the full-size images, only the thumbnails, so the images won't link to anything. Also, I didn't yet include all the fields I mentioned in my previous post; I did intend to include the filters and stupidly forgot. Next time around they'll be in there.]

This included more than 500 images, but after seeing the results I don't think it was enough. Cassini has so danged many filters that those 500 images were for a relatively small number of distinct observations (22), most of them on nontargeted flybys; the query did not pull in nearly as many global shots of the moon as I was hoping to get. So I think I will back away and try the 1 pixel per degree cutoff next time.

What do you think of the layout, with one observation per line? I think I will reduce the size of the thumbnails next time. They are currently 256 pixels -- I think I will reduce to 128 or even 100.

I used IMG2PNG to convert these, and did calibration, but the calibration didn't seem to work for the WAC images for some reason.

Comments?

Emily

Wow, this is quite an undertaking you're doing there, Emily! You sure your server is good for all this data?

One parameter that might be nice to add is which way north is (IIRC can be approximated from from the so-called TWIST_ANGLE). I'd use IMAGE_MID_TIME as I think it's more reliable than START_TIME.

What do you mean by WAC calibration not working? 128 pixel thumbs seem about right, anything smaller might make more distant observations look bad.

There are a few more fields I'd include, in approximate order of priority:

FILTER_NAME_1
FILTER_NAME_2
SUB_SOLAR_LATITUDE
SUB_SOLAR_LONGITUDE
INST_CMPRS_RATIO
DECLINATION
TWIST_ANGLE
RIGHT_ASCENSION

The first five are essential in my opinion. Possibly include VOLUME_ID and some of the RINGS_ fields as well.

Note: I'm using the field names from the Access database, not the fields in the INDEX.LBL files (which describe the contents of the INDEX.TAB files from which the database was generated). The field names are usually identical but there are a few exceptions where I broke a field from INDEX.LBL up into two fields, for example the two FILTER_NAME fields (because it seemed more convenient) and the SEC_FRAC fields (because as far as I know the maximum precision of Access dates is one second).

I'd use IMAGE_MID_TIME as you did rather than IMAGE_START_TIME.

The page layout looks fine but it contains a lot of stuff (42 MB) so maybe it should be broken up into several pages, probably by OBSERVATION_ID.

I'll see if I can find out why calibration didn't work for the WA images (it does on my machine when I use my big program from which IMG2PNG was cannibalized).

I like it. Perhaps you could do it with more images, but do it yearly (in other words, separate pages for 2004, 2005, 2006, etc). One thing (not sure if it is just because you are still working), the links to the PNG images don't work.

I've stumbled upon an error in the latest batch, there are two polarized UV NAC frames, N1536539385_1.IMG and N1536539427_1.IMG incorrectly labeled as:

TARGET_DESC = "Tethys"
TARGET_LIST = "N/A"
TARGET_NAME = "TETHYS"
OBSERVATION_ID = "ISS_028TE_TETHYSORS001_CIRS"

When in fact they target Enceladus:
Click to view attachment

IIRC, I've also stumbled upon this incorrectly labeled sequence when browsing VIMS cubes. There in fact was a Tethys ORS sequence running just at about that time - 2006-09-09 23:51:20.0, could this be a case of a quick-n-dirty retargeting to get a couple of Enceladus shots without a dedicated observation?

I've reduced the thumbnails to 128 pix and converted them from 16-bit PNG to JPG, and together that brings the page down to 2 MB of data, which is much better!

One thing that bothers me about this page is that there's a lot of redundancy -- it doesn't seem necessary to show thumbnails of all of the images of the same spot taken through different filters. I'm going to do some fiddling and see if I can come up with a different way to present this that has less redundancy, but shows more of the metadata.

Hmmm...

--Emily

Yep, thats down to an error by the person who built the camera command for this observation. The observation, ISS_028TE_TETHYSORS001_CIRS, starts off by turning to Tethys and then tracking Tethys. At the end of the observation Cassini turns from Tethys to Enceladus and ends pointing at Enceladus ready for the next observation to take over. No observations of Enceladus were planned. Margin has to be added to turns to allow for uncertainties so Cassini probably spent 2 mins or so actually pointing at Enceladus right at the end of the observation.

An error was clearly made in syncing the camera command with the spacecraft pointing. When that particular camera command was excecuted the spacecraft was tracking Tethys, thats why 'TETHYS' is the value of the TARGET_NAME keyword. 'Tethys' is the value of the TARGET_DESC keyword becasue thats the photometric model that was used to calculate the exposures for the camera command. The camera command ran 'too long' and images of empty space were taken while Cassini was turning from Tethys to Enceladus, the 12 images from N1536538981_1.IMG to N1536539343_1.IMG. The final two images in the observation were shuttered in that final 2 mins or so of turn margin time when Cassini, or at least the ORS instruments, were pointed at Enceladus. Interestingly the first image taken during the slew, N1536538981_1.IMG is not of empty space but Tethys -- however Tethys is smeared indicating that Cassini must have started turning during the 1.2 seconds that the shutter was open while this image was being taken.

Actually on reflection this can also be explained by the CIRS team changing the spacecraft pointing design after the ISS (and VIMS) Teams had built the camera commands for their rider observations, possibily because the observation had to be shortened.

Ahh, that explains it. Thanks a lot, pat, I'm always interested in learning in more detail how all these sequences are actually developed and executed at the low level. The shortening of the observation does seem like the most plausible reason. I did notice the one smeared image you mention, but the empty ones must have slipped me as "non-interesting".

Speaking of slew maneuvers, one thing I was always wondering is how much buffer time the cameras use when making mosaics of targets spanning over 1 FOV? Is it a couple of minutes or shorter? How fast can Cassini actually turn around say 180 degrees and steady up at the target pointing?

OK, I've had a slightly different go at it.

http://planetary.org/data/cassini/dioneattempt/index2.html
This is a much improved 726k to download. Note that the links to full-size images still do NOT work.

I used the 1 pix/degree cutoff this time (923 images) and incorporated more metadata, but am only showing one image from each multispectral set. I think I am happy with the number of observations included now -- I think it's more like 44 -- but am not totally happy with the page layout yet. I was hoping to come up with something where I could almost fully automate the generation of the html, but the step of deleting redundant images (something that's really necessary to reduce the amount of data on the browse page) has to be done by hand, and that's time consuming.

Two things I forgot and will include in any future version: I wanted to put the file names in with the metadata, but they're not there (though they are preserved in the URLs, so at least you can see them that way); and I wanted to include the TARGET_LIST field at the end.

EDIT: I added one more thing -- I was curious to see how many of these observations had resulted in products released to Photojournal. Many have, but many have not; and there are also a great many Photojournal releases of images where Dione was smaller than my size cutoff (though many of these were multiple-body images, so the small size made sense). Notes on Photojournal releases are now on the page. Also, the look through Photojournal made me realize that I missed all the opnavs, because these have a target of "SKY" -- I need to modify my query to add in those opnavs. There were 20 or so that were within the size range.

I'm going to start uploading the full-size images now and leave it running overnight -- it's 800 Megs of data!! That's a bit more than I bargained for. Too many 16-bit images.

Comments?

--Emily