Question regarding Huygens surface video Options

[sittingduck]

Recently I found a short animation of several of the images taken of the Titan surface by Huygens after it landed:

Link to animation.

I see that several objects appear to move in and out of frame, which I have read is attributed to fluffy aerosols kicked up from the surface settling down again.

My question is, what is the explanation for the object which appears to move horizontally from left to right? If it is in fact the same object in all 3 frames from frame 11-13, it appears at (x,y) pixel coordinates (74,290), (119,291), and (212,297). Is it something on the lens, drifting to the side perhaps?

Because I do not know how this sequence of images has been combined, and whether or not they are chronological or in reverse order, or whether there are missing intermediate frames, I cannot estimate the time that passes during the movement of this small blob.

Finally, is there a table somewhere with timestamps of all the Huygens triplets?

Regards,
Nick

[elakdawalla]

That looks incredibly JPEGgy, so I'd hesitate before interpreting anything within that video. As with everything else, it's always best to go to the original data. You can find Huygens DISR data and metadata here:
ftp://psa.esac.esa.int/pub/mirror/CASSINI-HUYGENS/DISR/

[JohnVV]

that animation is of SO LOW quality that it is 100% useless
there are jpg artifacts OF the jpg artifacts OF the jpg artifacts
i would guess that that left to right thing IS jpg artifacts

even the original data has a LOT of compression artifacts
( remember the whole A and B channel not communication with cassini thing )


image "IMG_DISPLY_1207_033503_5312.IMG"
ftp://psa.esac.esa.int/pub/mirror/CASSINI...MAT/IMAGE_12XX/
the brows for the "1207" image
ftp://psa.esac.esa.int/pub/mirror/CASSINI...DR-V1.0/BROWSE/

the 1207 image and in isis3 qview

[JRehling]

The jpeginess, as others noted, is far too great to take the details as indications of real objects.

Recently, I used my telescope camera with my microscope, and – although I should have expected this – I was struck by the lack of temporal variation that the telescope role had gotten me accustomed to. When you look through the Earth's entire atmosphere, things jiggle at all times. When you look through a centimeter of air, things don't.

The Huygens view is something in between. It's interesting that there's any variation here. That is, if we make sure that this is also true in the best possible version of this kind of display.

One really interesting piece of information we have is that the foreground is far closer than the background. If there are pure artifacts at work, then they ought to appear similar in kind in the foreground and the background. If there is something real there, seen in multiple instances, then we should see the scale vary based on distance.

Another thing we should expect to see in something physically real is a linear trend over 3+ frames. If things pop around randomly from frame to frame, there's no such evidence. If something appears to move, we can apply checks of significance vs. the probability of three "pops" of noise happening to align. This is similar to the math done in examining candidate planets in the Kepler data.

The potential is there to make a case for the reality of things in a Huygens video. We know that Huygens apparently altered its environment by boiling off some surface CH4, increasing its abundance in the air. We also know that Titan likely experiences a "snow" / ash of compounds that form in its upper atmosphere. Yet another possible phenomenon would be motions of light and shadow caused by clouds overhead (though this may be at odds with the observation that clouds are typically quite few and far between).

I'd love to see the possibility checked out thoroughly, but a display with highly visible squares all over the place doesn't seem like the data to start with.

[4throck]

The image sequence (in chronological order) shows the lander's light dimming as time passes and the battery runs out.
At least I remember reading something regarding the lamp Vs ambient light levels and that's the only noticeable change.

Here's an official release with all the data:
https://www.youtube.com/watch?v=sZC4u0clEc0

Once tried to use that difference in illumination to get some color, but that JPG compression is just too high.
An interesting processing would be to properly de-block the images (also for Pathfinder or Galileo).

[algorimancer]

I would have expected little change in the jpeg images over time, including the compression artifacts -- but clearly there is noise in the ccd detector, variation in illumination over time, and of course the interaction of the lander with the environment.

A sufficiently motivated person could take the known jpeg compression algorithm, ccd characteristics, optical system characteristics, etceteras, and create a detailed simulation of the surface imaging sequence, and conceivably over many iterations essentially reverse-impute the surface characteristics which produced the observed imagery and the associated variations over time. This would be a VERY complex procedure, and could easily be the basis of a Ph.D dissertation, perhaps jointly between a spacecraft engineer and a planetary scientist. At the very least, inverting the jpeg compression algorithm -- considering it was compressing the same scene repeatedly over time -- may provide some insights.

It would be very cool to see the product of such a study, but I am skeptical that it would add much to our existing knowledge.

[belleraphon1]

This may be pertinent to the discussion

http://www.planetary.org/blogs/guest-blogs...e-of-titan.html

Craig

[Spock1108]

But those white dots are snowflakes / wads of aerosols?
There are official publications?

https://media.giphy.com/media/l3vRiIZ1ufSeaHhxS/source.gif

[alan]

I recall an initial mention of the alleged motion:

http://www.unmannedspaceflight.com/index.p...&#entry4168

Unfortunately the link to that animation is dead.

There is probably a thread devoted to the discussion of it somewhere on the site.

[4throck]

I think that the issues mentioned (jpg compression, limited dynamic, noise) may prevent identification of those "particles".
Even if they are real, the images may not have enough data to characterize what we are seeing.

[algorimancer]

The Huygens descent imager (DISR) utilized a custom hardware solution to implement jpeg-like compression of the images. Is anyone aware of a software emulator of this compression tool? Or even an equivalent and clearly defined algorithm? I've sketched-out a statistical and simulation approach to attempt to extract additional information about the uncompressed images, but I really need some means of taking a simulated uncompressed image and then compressing it as the Huygens system did. My goal is, following compression, to be able to exactly reproduce the compression artifacts from the side-looking imager produced by DISR.

The closest I've come to an answer is the papers:

THE DESCENT IMAGER/SPECTRAL RADIOMETER (DISR) EXPERIMENT ON THE HUYGENS ENTRY PROBE OF TITAN, by Tomasko et al, Space Science Reviews 104:469-551, 2002.
https://www.researchgate.net/publication/22..._Probe_of_Titan

Comparison of the Lossy Image Data Compressions for the MESU Pathfinder and for the Huygens Titan Probe, by Ruffer et al, NASA, 1994.
https://ntrs.nasa.gov/archive/nasa/casi.ntr...19940023751.pdf

So far as archived imagery, this resource seems helpful:
CASSINI PROJECT, IMAGING SCIENCE SUBSYSTEM (ISS), ARCHIVE VOLUME SOFTWARE INTERFACE SPECIFICATION (SIS)
http://pds-imaging.jpl.nasa.gov/documentat...ini_archsis.pdf

A concern I have with simply implementing an algorithm is that it likely would not completely account for the hardware limitations of the solution used on Huygens, such as floating point arithmetic with hardware-specific byte limitations. Plus, if I did implement an algorithm I would still want to be able to validate it on a known pair of uncompressed and Huygens-compressed images.

[mcaplinger]

Comparison of the Lossy Image Data Compressions for the MESU Pathfinder and for the Huygens Titan Probe, by Ruffer et al, NASA, 1994.
https://ntrs.nasa.gov/archive/nasa/casi.ntr...19940023751.pdf

Based on this reference DSIR used 16x16 DCT blocks and a single quantization value for all coefficients except the DC coefficient, unlike standard JPEG which uses 8x8 blocks and a different Q for each coefficient. The hardware DCT chip datasheet is http://www.littlediode.com/datasheets/pdf/...STV/STV3200.PDF and that describes the bit widths of the internal computation.

[algorimancer]

...DSIR used 16x16 DCT blocks and a single quantization value for all coefficients except the DC coefficient, unlike standard JPEG.... The hardware DCT chip datasheet ... describes the bit widths of the internal computation.

Thank you, that helps clarify some of the issues. Maybe a close-enough implementation would be good-enough.

[PDP8E]

algorimancer,
Here is a fast cosine function I use with JPEG file decoding
Cosines are always the bottleneck in the pipeline (or at least the simplistic way I decode JPEGS)
It's at least 10x faster than the library versions (no divisions... and the constexpr compile-time division doesn't count as one in C)
I got it from a co-worker years ago.
You can compare it to other lib cosine functions, rewrite it as a C++ template, or convert to your favorite lang.
I hope it helps you with your project.

CODE

inline float fast_cosf( float x )
{
// wicked fast cosine function

    constexpr float one_over_2pi = 1.0/(2.0* M_PI);
    x *= one_over_2pi;
    x -= 0.25f + floor(x + 0.25f);
    x *= 16.00f * (abs(x) - 0.50f);
//    x += 0.225f * x * (abs(x) - 1.0f);   // for extra precision, uncomment, otherwise it's good enough
    return x;
}

[rlorenz]

The Huygens descent imager (DISR) utilized a custom hardware solution to implement jpeg-like compression of the images.
Is anyone aware of a software emulator of this compression tool? Or even an equivalent and clearly defined algorithm? I would still want to be able to validate it on a known pair of uncompressed and Huygens-compressed images.

To respond to this thread more generally......

In the last few years Erich Karkoschka at U. Arizona has extensively reprocessed the images with revised flatfields, and improved implementation
of the DCT (de)compression. There are several papers in Icarus and Planetary and Space Science that go into the details. Different image versions are
archived on the PDS. But THE MOST IMPORTANT THING is to read the very detailed DISR Users Guide (which hasn't actually been on the PDS for terribly long)

http://atmos.pds.nasa.gov/data_and_service...gens/disr1.html

Someone mentioned battery dimming - I doubt it. The probe power bus was regulated, and there was probably DISR-internal regulation of the lamp
current anyway. However, the auto-exposure algorithm did change the exposure times, so looking at raw pixel numbers might show a decline.
The Appendix to the user guide has a table with the image numbers, exposure times, compression level etc.

Erich analyzed the little spots and determined they were all radiation hits on the detector, except for the one feature in the bottom left of image 897, which seems
to be a dewdrop from methane sweated out of the ground by the lamp. (Note they may be hits from neutrons from the RHUs - the rate of cosmic rays should
be very low in Titan's thick atmosphere).

There was a publication a few months ago purporting to detect a fog bank, but Erich says while one can't exclude it, it's at the noise level.

Ralph