Celestia Forums

t00fri wrote:An eccentricity of 0 means a circular orbit according to Kepler's equations. Titan's eccentricity 0f 0.0292 is very close to a circular orbit, as may be easily checked with Celestia: put Titan at rest and let Saturn orbit around it. Watch this from a position /othorgonal/ to the orbit plane: for all practical purposes, Saturn "encircles" Titan in a "Titano-centric system" on a circular orbit...

Actually, for all practical purposes - especially tidal - Titan's orbit is very much eccentric. It's nearly three times the eccentricity of Europa's orbit around Jupiter, and it's almost as far from Saturn as Callisto is from Jupiter.

It is certainly eccentric enough to cause some significant tidal dissipation and raise some hefty tides on the surface. Do not be deceived by appearances - an orbit does not have to be far off circular at all to have a significant effect on the body.

Oh yes! R?? effect. So, those very strong tidal forces are even more reason against a global ocean then! .

Meanwhile, found this: http://www.es.ucl.ac.uk/research/planetaryweb/undergraduate/dom/weathering_titan/tocf.htm

Considers oceans, no oceans and tides.

Spiff.

FYI, The ESA has now posted the raw data as well.
http://esamultimedia.esa.int/docs/titanraw/index.htm

Hopefully, this will leave people a little more comfortable with using this data.

BTW, this data ahs the same compressino artifacts. I think it is safe to assume that the compression is the best available to anyone.

Is this the raw data?It seem a collage(mosaic?!) of the same pictures released before.I??m very disappointed...

wcomer wrote:FYI, The ESA has now posted the raw data as well.
http://esamultimedia.esa.int/docs/titanraw/index.htm

Hopefully, this will leave people a little more comfortable with using this data.

BTW, this data ahs the same compressino artifacts. I think it is safe to assume that the compression is the best available to anyone.

In case, you are interested where Huygens' final landing site was located according to today's ESA info: I have marked it (including the remaining uncertainty) as a golden blob in my 'georgeous' Titan panorama below (sources as in same image above).

Jestr: does that agree with your add-on?

Bye Fridger

I cant tell from this picture.The landing site I used came from projected figures.Does anyone know what the real values are?Jestr

danielj wrote:Is this the raw data?It seem a collage(mosaic?!) of the same pictures released before.I??m very disappointed...

How anyone can be disappointed by this absolutely magnificent achievement escapes me completely... This is sort of my generation??s Eagle Moon Landing, and i get goosebumps just looking at those rocks...

Of course i can take better pictures with my own camera. But that camera isn??t there.

-rthorvald

All too often in space exploration, people gauge a mission's success by the pictures that mission takes. Huygens returned a wealth of data visually, but the true treasure came back in other forms. And the images that came back, for the capabilities of the probe, were spectacular.

A first time mission like this is *not* going to be sending back Spirit or Opportunity quality images. To expect it to be so is, frankly, silly.

We are going to be looking at data from this probe for decades and more; heck, we're still pouring over Voyager data!

For my part, I'm thrilled beyond belief.

...John...

Dollan wrote:
For my part, I'm thrilled beyond belief.

Me, too! I really hope NASA and ESA will announce a plan to send a couple of rovers to Titan sooner than later. This looks like a world that's worth exploring!

wcomer wrote:BTW, this data ahs the same compressino artifacts. I think it is safe to assume that the compression is the best available to anyone.

"The images are transmitted using a compression scheme which pre-dates JPEG", according to an answer on their Ask an Expert http://www.lpl.arizona.edu/~kholso/expert.htm page. No details on that compression scheme though. I suppose knowing how it works may help removing some artefacts created by it.

With Huygens rotating as it descends through the atmosphere, no two successive images cover exactly the same area, and thus compression artefacts normally won't blur the same ground feature repeatedly. However, the images taken after landing all have the camera pointing in the same direction, and the compression mosaic grid yields the same set of distortions on every image.

When I first browsed the raw triplet pages, I thought they were only releasing images from the ground, as they appear both in the beginning and the end of the set. However, they seem to be presented in semi-random order, and the images from the descent can be found in the middle of the set. Has anybody seen any metadata associated with the triplets, such as timestamps? Are the three images in each triplet supposed to be taken simultaneously, or did the cameras operate independently of each other?

A number of images are severely scrambled, perhaps due to sampling or transmission errors. I think there are also repetitions, or what do you think of the following two triplets:



The bottom images are from the downward-looking camera, and the features in them seem to be distorted by motion blur, but it looks like the very same motion blur. The middle-row images also look identical. Yet the top-row images (from the sideways-looking camera) are quite different from each other, and I'm not convinced they even overlap.

By the way, if the images were transmitted using a compression scheme other than JPEG, then converted to JPEG by the DISR team before being released on the Internet, doesn't that introduce yet another layer of potential distortion? Then someone compiles an animated GIF from 100 images that have been converted to JPEG independently of each other, and I'd be surprised if there weren't any flickering in the resulting animation...

Therefore, I think calling those image triplets in JPEG files "raw data" isn't entirely accurate. Not that I'd want the raw data off the Deep Space Network dishes as my browser hardly understands the format, but after having that data travel a billion kilometers to reach us, I think it deserves better than being compressed yet again using another lossy scheme just to save a little bandwidth here on Earth. What about PNG?

Anders,

The raw files appear to be using lossless .jpg (i.e. 100% quality.) If so, then calling these .jpgs "raw data" is accurate.

-Walton

Anders,

Let me amend that a bit. The 12 original triplets put up on the arizona site which are not contrast enhanced appear to be lossless compressed. I cannot say the same for the contrast enhance "raw" files that currently appear on the arizona and esa sites.

The rest of the unprocessed (and seemingly uncompressed) images can be found on the Anthony Liekens site:
http://anthony.liekens.net/titan/huygen ... ges.tar.gz

cheers,
Walton

wcomer wrote:The raw files appear to be using lossless .jpg (i.e. 100% quality.)

I guess you are right; I'm just a little paranoid about JPEG being used with lossy compression in the wrong places. Can you tell from examining a JPEG file what the quality rate is (do you have some tool for it)?

I still wonder about the proper sequence of the triplets. The images from the ground can be found in triplets 0-190, then again in 723-996. Triplets 194-713 seem to cover the descent phase, although there are a few from 194 and onward that are difficult to characterize. Which image was taken first, which was taken last, and why do they come in this order?

The files numbered 716, 718, 719 and 721 are mutually identical, and appear to be a mere misalignment of the images in triplet 713, probably due to a software error (perhaps in post-reception processing here on Earth).

You can tell the format of the file from its header data but that doesn't tell you anything about its history. That is. If I compress at 75%. Then compress that file at 100%, you might think it was 100% just looking at the header data. However, if you open the file and compress it at 95% and you find that this removes about 5% of the bytes. Then you can guess that it was already compressed pretty efficiently. On the other hand, if it removes more like 30% of the bytes then you know you are probably working with the original image. That is the basis for my assumptions that the anthony.lieken data is uncompressed.

-Walton

wcomer wrote:You can tell the format of the file from its header data but that doesn't tell you anything about its history. That is. If I compress at 75%. Then compress that file at 100%, you might think it was 100% just looking at the header data. However, if you open the file and compress it at 95% and you find that this removes about 5% of the bytes. Then you can guess that it was already compressed pretty efficiently. On the other hand, if it removes more like 30% of the bytes then you know you are probably working with the original image. That is the basis for my assumptions that the anthony.lieken data is uncompressed.

-Walton

Walton,

yesterday I examined the raw images that you quoted as presumably uncompressed under fairly high zoom. Also there one notices those big squares with image content that does not match well the content in the neighboring squares. Where do these squares come from? The size of the squares is about 1cm^2 if the image size is magnified to something like 8x16cm^2.

Bye Fridger

wcomer wrote:The raw files appear to be using lossless .jpg (i.e. 100% quality.)

Please note that there is no truely "lossless" JPG - even with 100% quality you lose some information. At least this is true for normal JPGs, for details see: http://www.faqs.org/faqs/jpeg-faq/part1/, "Subject: [13] Isn't there a lossless JPEG?"

Harald

t00fri wrote:yesterday I examined the raw images that you quoted as presumably uncompressed under fairly high zoom. Also there one notices those big squares with image content that does not match well the content in the neighboring squares. Where do these squares come from? The size of the squares is about 1cm^2 if the image size is magnified to something like 8x16cm^2.

Bye Fridger

The images are probably compressed on the lander and sent back that way, in that case. Remember that bandwidth is limited, and so the more data you can squeeze back the better (supposedly) - the problem of course is that you can sometimes compress the data so much that you LOSE a lot of it in the process.

This happened with Galileo, where some images were compressed onboard (using ECW compression I think, which is like JPG) and had a ridiculous number of compression blocks that demolished the data. Of course, the way it worked was that areas in the image with a lot of pixel variation would be preserved and areas that were relatively uniform were compressed. Unfortunately, the most interesting areas that people want to look at happen to be those ones that are relatively uniform in brightness because usually they've been resurfaced! It was really frustrating to see a potentially interesting part of an image, and then realise you're looking at a couple of compression blocks that have obliterated the data that was originally there. Unfortunately you can't "undo" compression blocks...

PNG file format or similar might be better to use in upcoming flybys, so the image stays relatively uncompressed. Is this feasible?

Michael Kilderry

Michael Kilderry wrote:PNG file format or similar might be better to use in upcoming flybys, so the image stays relatively uncompressed. Is this feasible?

You'd think... But they use their own proprietary formats and compression schemes, which are hideously clunky but do the job they want them to do. I think it might be so that they can put their own image headers and labels on the top of the files, which you can't do with PNGs or GIFs.

I don't know too much about the format that the cameras actually save the images as, I deal more with turning those into processed images.