Program To Dump Raw Image Info Options

[jmknapp]

I'm often wanting to find out when a particular image was taken, what sol, etc., for raw image files lying around my hard drive. Particularly with the exploratorium files since they are not offered with the dates the images were acquired.

Here is a command-line program that will decode the raw image filenames:

Windows command-line executable rawid.exe

Linux command-line i386 executable

Source code rawid.c

This is the typical output:

-----------------------------------------------------------------------
Image info for: 1F132089069EDN05A6P1141R0M1
Spacecraft: OPPORTUNITY
Camera: Forward HAZCAM, right
Spacecraft clock: 132089069 (seconds since January 1, 2000, 11:58:55.816 UTC)
Product type: EDR downsampled
Site number: 05
Drive number: A6
Command sequence number: P1141 (PMA or remote sensing instrument) HAZCAM
Producer: MIPL/JPL
Acquisition time (Earth): Tue Mar 9 02:12:22 2004
Time zone: EST
Acquisition time (Mars): Sol 44 11:24:47
Current local time (Earth): Thu Mar 11 22:45:35 2004
Current local time (Mars): Sol 47 06:14:33
Elapsed time since acquisition: 2 days, 20:07:31
-----------------------------------------------------------------------

Hope that helps someone.

[MizarKey]

Looks like a good program, I'm thinking of doing something similar but it would only be usable by people with Crystal reports, so I probably won't post it here.

One suggestion for an addition to your program is to add the filter information...using the data from JPL filename explanation.

Eric P / MizarKey

[jmknapp]

It does list the filter info if applicable. The hazcam example above has none because it doesn;t have switchable filters. Here's an example for pancam:

-----------------------------------------------------------------------
Image info for: 1P130493953EFF0402P2385L5M1
Spacecraft: OPPORTUNITY
Camera: PANCAM, left, filter 5, 535 nm (20 nm bp) green
Spacecraft clock: 130493953 (seconds since January 1, 2000, 11:58:55.816 UTC)
Product type: EDR full frame
Site number: 04
Drive number: 02
Command sequence number: P2385 (PMA or remote sensing instrument) PANCAM
Producer: MIPL/JPL
Acquisition time (Earth): Thu Feb 19 15:07:06 2004
Time zone: EST
Acquisition time (Mars): Sol 26 12:09:52
Current local time (Earth): Fri Mar 12 14:55:11 2004
Current local time (Mars): Sol 47 21:38:33
Elapsed time since acquisition: 21 days, 23:18:19
-----------------------------------------------------------------------

[Guest_Sunspot_*]

Having some trouble getting the program to run, any help and advice?

[djellison]

if you're using the dos version - thing to do is make a text file - save it as raw.bat - and in it, just have, for example...

rawid.exe 1P134052419ESF08AQP2859L5M1

put the raw.bat and rawid.exe into c:\documents and settings\your user


Then - start>programs>accesories> Command Prompt

It'll probably put you in c:\documents and setting\your user

then you simply go

raw.bat

and it'll print the results

You just edit raw.bat to have the file name you need.

You need to run it in the command prompt window because otherwise it just opens and closes in an instant.

it's very VERY usefull - esp. when the Exploratorium stuff is way way way ahead of JPL

Doug

[Guest_Sunspot_*]

OK will try, thanks

[MizarKey]

It does list the filter info if applicable. The hazcam example above has none because it doesn;t have switchable filters. Here's an example for pancam:

-----------------------------------------------------------------------
Image info for: 1P130493953EFF0402P2385L5M1
Spacecraft: OPPORTUNITY
Camera: PANCAM, left, filter 5, 535 nm (20 nm bp) green
Spacecraft clock: 130493953 (seconds since January 1, 2000, 11:58:55.816 UTC)
Product type: EDR full frame
Site number: 04
Drive number: 02
Command sequence number: P2385 (PMA or remote sensing instrument) PANCAM
Producer: MIPL/JPL
Acquisition time (Earth): Thu Feb 19 15:07:06 2004
Time zone: EST
Acquisition time (Mars): Sol 26 12:09:52
Current local time (Earth): Fri Mar 12 14:55:11 2004
Current local time (Mars): Sol 47 21:38:33
Elapsed time since acquisition: 21 days, 23:18:19
-----------------------------------------------------------------------

I've used the program you provided, it works well, but I have too many files to use this againsts individuallly. What I am planning on doing is doing a file list in a dos text file, importing it into a spreadsheet and extracting the date information via a formula. This will work for the 'earth' time. (edit) OK, that's not working so hot either as Excel uses days and I'm dealing with seconds...how many 'seconds' are in a 'day'...or better yet, what formula do you use in your program for converting the seconds to Earth time and Sol time? -should have taken more math in school...(end edit)

What I need to know is how to convert it to know what Sol the picture was taken. Can you tell me the formula you used in your program?

Thanks!

Eric P / MizarKey

[jmknapp]

...or better yet, what formula do you use in your program for converting the seconds to Earth time and Sol time?  -should have taken more math in school...(end edit)

What I need to know is how to convert it to know what Sol the picture was taken.  Can you tell me the formula you used in your program?

Thanks!

Well Eric, I hadn't checked this board in a while, so this answer is some months late! Anyway, I converted the spacecraft clock to Earth time as follows:

mertime = MER clock from the file name (seconds since January 1, 2000, 11:58:55.816 UTC)

umertime = mertime + 946727273 (MER clock converted to Unix time (seconds since Jan. 1, 1970))

Then the C library function ctime(&umertime) can be used to get the conventional Earth time.

As for sols, I took sol1 for Spirit to be 126408373 on the spacecraft clock. then the sol number is given by:

sols = 1.0 + (mertime - 126408373)/88775.244 ;

Where 88775.244 is the number of seconds per sol.

Note that the formulas above are not strictly accurate because the MER clocks do not keep perfect time by any means even though those clocks form the basis for timestamping images, etc.

From the SCLK SPICE kernel for the MERs:

The on-board clock, the conversion for which is provided by this SCLK file, consists of two fields:

SSSSSSSSSS:FFF

    where:

          SSSSSSSSSS -- count of on-board seconds

          FFF        -- count of fractions of a second with one fraction
                        being 1/256 of a second

and nominally starts at the J2000 epoch (2000 JAN 01 12:00 ET).

The coefficients given in the SCLK kernels show that the MER clocks can lose or gain time in a random way. For example this is the latest SCLK kernel for MER-2: ftp://naif.jpl.nasa.gov/pub/naif/MER/kern...KSCET.00016.tsc

The third column of numbers are the clock drift coefficients where 1.0000 would be perfect time. The first column has the sclk boundaries (number of 1/256th second ticks) for the different drift rates, and the second column has what's known as the parallel time system that is a much more precise (in this case Ephemeris Time). So effectively there is a piecewise linear function that will map the sclk to Ephemeris Time. From the SCLK required reading document ftp://naif.jpl.nasa.gov/pub/naif/toolkit_...l_docs/sclk.req :

We can represent the data that define the SCLK-to-ET mapping as a set
    of ordered triples of encoded SCLK values (in units of ticks since
    spacecraft clock start), their equivalents in ephemeris time, and the
    rates corresponding to each pair of times:

        ( s/c_clock(1),  et(1),  rate(1) )
                          .
                          .
                          .
        ( s/c_clock(n),  et(n),  rate(n) )

    The mapping of SCLK values to ephemeris times is carried out as
    follows: If the sclk time clock satisfies

        sclk(i)  <  clock  <  sclk(i+1)
                -

    then the corresponding ephemeris time is

        et(i)    =    rate(i) *  ( clock - sclk(i) )

    If

        clock  >  clock(n)
              -

    the formula still applies, with i = n.

Looking at the rate column for MER-2, it can be seen that sometimes the drift rate can be as much as 1.02 meaning the clock is 2% fast! However, in that particular case the duration was only about about 1000 seconds. No idea what causes the clock to vary like that.

Overall the MER-2 clock seems to be keep time less well as the mission goes on, losing a few minutes from Aug 2004 to Feb 2005. There hasn't been an SCLK file update (released on the NAIF website anyway) since April.

Joe