IPB

Welcome Guest ( Log In | Register )

2 Pages V   1 2 >  
Reply to this topicStart new topic
Question regarding Huygens surface video
sittingduck
post Dec 9 2016, 08:29 AM
Post #1


Junior Member
**

Group: Members
Posts: 43
Joined: 14-December 12
Member No.: 6784



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
Go to the top of the page
 
+Quote Post
elakdawalla
post Dec 9 2016, 08:28 PM
Post #2


Administrator
****

Group: Admin
Posts: 5172
Joined: 4-August 05
From: Pasadena, CA, USA, Earth
Member No.: 454



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/


--------------------
My website - My Patreon - @elakdawalla on Twitter - Please support unmannedspaceflight.com by donating here.
Go to the top of the page
 
+Quote Post
JohnVV
post Dec 11 2016, 11:49 PM
Post #3


Member
***

Group: Members
Posts: 890
Joined: 18-November 08
Member No.: 4489



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
Go to the top of the page
 
+Quote Post
JRehling
post Dec 12 2016, 05:30 PM
Post #4


Senior Member
****

Group: Members
Posts: 2530
Joined: 20-April 05
Member No.: 321



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.
Go to the top of the page
 
+Quote Post
4throck
post Dec 13 2016, 04:04 PM
Post #5


Junior Member
**

Group: Members
Posts: 64
Joined: 17-December 12
From: Portugal
Member No.: 6792



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


--------------------
www.astrosurf.com/nunes
Go to the top of the page
 
+Quote Post
algorimancer
post Dec 13 2016, 06:16 PM
Post #6


Member
***

Group: Members
Posts: 656
Joined: 20-April 05
From: League City, Texas
Member No.: 285



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.
Go to the top of the page
 
+Quote Post
belleraphon1
post Dec 14 2016, 02:01 PM
Post #7


Member
***

Group: Members
Posts: 813
Joined: 29-December 05
From: NE Oh, USA
Member No.: 627



This may be pertinent to the discussion

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

Craig
Go to the top of the page
 
+Quote Post
Spock1108
post Dec 15 2016, 08:36 PM
Post #8


Junior Member
**

Group: Members
Posts: 22
Joined: 13-November 15
Member No.: 7840



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

https://media.giphy.com/media/l3vRiIZ1ufSeaHhxS/source.gif
Go to the top of the page
 
+Quote Post
alan
post Dec 15 2016, 10:22 PM
Post #9


Senior Member
****

Group: Members
Posts: 1887
Joined: 20-November 04
From: Iowa
Member No.: 110



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.
Go to the top of the page
 
+Quote Post
4throck
post Dec 16 2016, 10:30 AM
Post #10


Junior Member
**

Group: Members
Posts: 64
Joined: 17-December 12
From: Portugal
Member No.: 6792



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.


--------------------
www.astrosurf.com/nunes
Go to the top of the page
 
+Quote Post
algorimancer
post Dec 16 2016, 04:36 PM
Post #11


Member
***

Group: Members
Posts: 656
Joined: 20-April 05
From: League City, Texas
Member No.: 285



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.



Go to the top of the page
 
+Quote Post
mcaplinger
post Dec 16 2016, 05:02 PM
Post #12


Senior Member
****

Group: Members
Posts: 2547
Joined: 13-September 05
Member No.: 497



QUOTE (algorimancer @ Dec 16 2016, 08:36 AM) *
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.


--------------------
Disclaimer: This post is based on public information only. Any opinions are my own.
Go to the top of the page
 
+Quote Post
algorimancer
post Dec 16 2016, 05:35 PM
Post #13


Member
***

Group: Members
Posts: 656
Joined: 20-April 05
From: League City, Texas
Member No.: 285



QUOTE (mcaplinger @ Dec 16 2016, 11:02 AM) *
...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.
Go to the top of the page
 
+Quote Post
PDP8E
post Dec 17 2016, 05:53 PM
Post #14


Member
***

Group: Members
Posts: 808
Joined: 10-October 06
From: Maynard Mass USA
Member No.: 1241



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;
}


--------------------
CLA CLL
Go to the top of the page
 
+Quote Post
rlorenz
post Dec 18 2016, 12:15 AM
Post #15


Member
***

Group: Members
Posts: 613
Joined: 23-February 07
From: Occasionally in Columbia, MD
Member No.: 1764



QUOTE (algorimancer @ Dec 16 2016, 11:36 AM) *
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
Go to the top of the page
 
+Quote Post

2 Pages V   1 2 >
Reply to this topicStart new topic

 



RSS Lo-Fi Version Time is now: 31st October 2024 - 10:46 PM
RULES AND GUIDELINES
Please read the Forum Rules and Guidelines before posting.

IMAGE COPYRIGHT
Images posted on UnmannedSpaceflight.com may be copyrighted. Do not reproduce without permission. Read here for further information on space images and copyright.

OPINIONS AND MODERATION
Opinions expressed on UnmannedSpaceflight.com are those of the individual posters and do not necessarily reflect the opinions of UnmannedSpaceflight.com or The Planetary Society. The all-volunteer UnmannedSpaceflight.com moderation team is wholly independent of The Planetary Society. The Planetary Society has no influence over decisions made by the UnmannedSpaceflight.com moderators.
SUPPORT THE FORUM
Unmannedspaceflight.com is funded by the Planetary Society. Please consider supporting our work and many other projects by donating to the Society or becoming a member.