Cassini image database & updates, And notifications of PDS data releases Options

[elakdawalla]

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

[djellison]

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

Doug

[Bjorn Jonsson]

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.

[elakdawalla]

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

--Emily

[David]

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...

[Bjorn Jonsson]

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.

[ugordan]

A little comparison of Cassini's solar eclipse as seen by VIMS and ISS:

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.

[ugordan]

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.

[scalbers]

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...

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.

[elakdawalla]

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

[volcanopele]

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.

[elakdawalla]

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

[ugordan]

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.

[Bjorn Jonsson]

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).

[tedstryk]

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.