[X] My Assistant

[Bjorn Jonsson]

This may be a bit specialized to say the least but if anyone can help I'd be grateful. I have now downloaded most of the raw Cassini images from the PDS imaging node plus the coiss_0011 volume from the PDS rings node. Volume coiss_0011 contains calibration stuff like flatfields, masks for removing dust rings and mottling etc.

I have been implementing calibration code which will eventually be added to my IMG2PNG utility, assuming there is interest in this. This utility is mentioned in this thread: http://www.unmannedspaceflight.com/index.p...wtopic=291&st=0 .

My code has been largely based on the CISSCAL source code on volume coiss_0011 but cleaned up a bit and rewritten using C++. This has been very successful despite a wide variety of rather arcane data formats on the coiss_0011 volume (bigendians, littleendians, IEEE and VAX floating point numbers, a weird TIFF file containing floating point data etc.). For example, flatfielding, linearization etc. works very well and in particular, for images of low contrast targets like Saturn and Titan makes a big difference if the images are to be greatly sharpened (no mottling or dustrings).

There is one problem though: Darkcurrent subtraction. This is a problem, the CISSCAL code for this is somewhat complex and may contain some bugs - what it does is to generate 'synthetic' darkcurrent images based on a model taking various factors into account. These 'synthetic' darkcurrent images get written to disk so each of them only has to be generated once. If anyone has 'sample' synthetic darkcurrent images I would greatly appreciate if at least one of these could be emailed to me since without this it is almost impossible for me to know if the images my code is generating are correct.

These images should (assuming my code is correct !) have names like \calib\darkcurrent\darks04228\n_dark027102410100_04228.img where '\calib' is in my case the calib-directory on the coiss_0011 DVD volume (which is lying on my hard disk).

Bjorn

[volcanopele]

Sounds like some of you are joining me in the hell that is calibrating Titan images. The only thing I can tell you is that you will need a secondary flatfield file. The flatfield file that comes with the PDS delivery is not sufficient. In this delivery, and in PDS deliveries to come, look for bland CB3 images with similar camera settings (gain state, exposure time. etc.) as the images you want to flatfield, and sum those to get a secondary flatfield file.

[ugordan]

Bjorn: concerning the way your app does shutter offset treatment, I'm personally confused with the way cisscal handles this and the 1 ms it adds to the overall offset slope. I don't understand whether the actual exposure is (exp+offset[sample_number]) or (exp-offset[]) and whether we're supposed to add or subtract a fixed value from the offset file.
It's not so much of a point for NAC, but for WAC, which tends to use very short exposures (only a few ms) for the R/G/B filters, the different approaches produce dramatically different results.

[Bjorn Jonsson]

The true exposure is commanded_exposure-offset[sample_number]-1.0.

The 1.0 constant seems to be a temporary 'quick-and-dirty' way of doing things if I understand the ground calibration report (section 4.3) and the comments in CISSCAL correctly.

However, I now notice that there seems to be a bug in CISSCAL (and consequently also in IMG2PNG), 1.0 should only be subtracted when calibrating NAC data.

I'll need to fix this in IMG2PNG and also make it possible to specify additional flatfielding files as tfisher's processing of Titan data has demonstrated.

[ugordan]

The true exposure is commanded_exposure-offset[sample_number]-1.0.

The 1.0 constant seems to be a temporary 'quick-and-dirty' way of doing things if I understand the ground calibration report (section 4.3) and the comments in CISSCAL correctly.

However, I now notice that there seems to be a bug in CISSCAL (and consequently also in IMG2PNG), 1.0 should only be subtracted when calibrating NAC data.

I only bring this up because my two "testbed" image sets, Jupiter flyby WAC R/G/V and the Dione flyby WAC R/G/B frames both exhibit excessive overexposure in the violet/blue filter after radiometric correction. I might be off, but I'm attributing this to the fact that in both cases the red and green exposures were 5 and 15 ms or so, respectivelly, while the violet/blue exposures were around 150 ms. This would be the reason small variations in the shutter offset (+/- 1 ms) tend to dramatically darken/brighten the red and green channels compared to the blue/violet.
OTOH, the offset read from the file, for the middle sample in the WAC is somewhere around -2.7 ms which is why I got the feeling the actual offsets should be added instead of subtracted. The official document did say the actual exposures were always less than the commanded ones.