Hi all,

Considering the dynamic range of HiRISE-images:
Whereas for a "normal sized" image covering one single type of terrain, 8 bit (256 shades of gray) are usually enough, It has been my impression that for the huge area (gigapixels) coverd by each single HiRISE image, often covering a variety of different types of terrain from very dark (basltic black sand) to very light (ice !) typical for the martian landscape, the subtle details in the shadows and very light areas may easily get lost with a *global* dynamic range of only 8 bits.
From reading the specs at http://hirise.lpl.arizona.edu/ it was my impression that the dynamic range of HiRISE images is
compressed

1) already on-board (via 14-to-8 bit Lookup-tables LUT)
2) the dynamic range stretching is done globally for each image

I conclude this from the information I got at the HiBlog:



On the other hand, however, there seems nevertheless to be a way for the HiRISE team to increase the *local* dynamic range for sub-images like the following one

http://hirise.lpl.arizona.edu/PSP_005392_0995

where in the sub-image the details in the very bright area of the icy crater wall are preserved, whereas in the global image the bright area is "blown out" with uniformly white pixels)
This is even so when applying the "local dynamic range stretch" in IAS viewer ...

So my question would be: if the dynamic range compression is already done on-board and globally for each image, then how
could the locally improved dynamic range obtained of the sub-images posted ta the HiRISE site ?

Could this high dynamic range information (i.e. the original 12-14bit per pixels from the CCDs) somehow obtained/recoverd from the raw/IMG-files (converting to 16-bit PNG ?) ?

Thanks a lot in advance for any answers !

Bernhard

I'm no HiRISE expert, but my guess would be yes. Even though the 14 bit data is LUT-converted to 8 bits, it doesn't mean it loses the original dynamic range. It just means you lose resolution in that dynamic range. What it does is select just 256 discrete brightness levels to which the full 14 bit data (16384 levels) is mapped to. On the other hand, compressing such a large dynamic range down to 8 bits of JPEG/JP2000 or whatever destroys dynamic range. 8 bits LUT compression and 8bit output images are two different things. The real issue is the 8 bits from JPEGs don't correspond 1-to-1 to the original raw 8 bits because all these imaging formats assume the DNs map linearly to brightness (neglecting gamma issues here).

Say the LUT preserves high brightness levels better, i.e. it's nonlinear and assigns more 8bit DNs to high than to low levels. That means your 8bit LUT data resolves several high brightness levels even in 14->8 LUT encoding. Once on the ground, the data is passed through inverse LUT and linearized again to get the original 14 bit dynamic range (though all 14 bit values were mapped to a discrete set of only 256 DNs). It's only actually "downsampled" (or binned) to 8 bit once images for the web are prepared. In case of those several high DNs that each got its own DN in LUT conversion, they will all be mapped to probably just one output DN.

The original 14 bit dynamic range should exist in either EDR or RDR IMG sets somewhere.

This is why when calibrating Cassini data and outputting to 16 bit PNGs I try to max out the output DNs to prevent any undesirable dynamic range compression, even if the raw 12 bit data would fit comfortably into the 16 bit PNGs. If the output calibrated 16bit PNG has a highest DN (seen in Photoshop) of 16 out of 255, you're just marginally able to squeeze the original dynamic range into the output linear range and even that's neglecting what calibration does to the data.

Thanks Ugordan, for your informative explanation

you are right: what I really meant was not lack of dynamic range itself but lack of dynamic range *resolution*.

So, to summarize: whereas the original high-resolution can not be recovered (because of the first on-board LUT step)
the original DN *range* (although at only 8-bit resolution) is indeed recoverd via inverse-LUT and its only the final DN mapping
applied for the JPG2000-output that my be responsible for the clipping of the very lightest and/or darkest areas.

On the other hand, I found that for most images the DN stretching/mapping applied to the JPG2000 files found on the web
is already very good at preserving most of the dynamic range.
It's just in (rare) cases such as the highlights in the ice crater walls mentioned above, where it would be worth the effort to re-do
the whole processing chain from the raw EDR/RDRs.

Hello, that quote is from me. Your summary is correct. The locally improved stretch is done within the IAS viewer (DRA and Auto-DRA) or qview, and not by going back to the raw products.

I should also mention that for the current NOMAP products, the mapping of DN to JP2/JPG pixel values is chosen so that at most 0.01% of the pixels are saturated high or low. That is still a lot of pixels. We've been experimenting with a somewhat smarter algorithm and the results look good, the first set of data should be out within a month or so and by June or July, everything should be redone. As always, the full RDR gets you back to the original post-LUTted DN values.

This is a great example. The full RDR on the PDS volume preserves the full range of values (screenshot attached), but the quicklook and the NOMAP products do not, as you have seen.

Click to view attachment

Thanks GuyMac, this perfectly answers my original question ...
Its good to know that (other than the 0.01% clipping) no dynamic range information is lost in-between, even with the qicklook JPGs

I have one additional question I'm struggling with for quite some time:

Is there a way in IAS viewer to save sub-images with resolution larger than the current screen window size ?

IAS veiwer seems to restrict the export/save-window to the current screen/window resolution
(i.e. usually not larger than 1600x1200 pixels ... is there a way to save sub-images at larger resolution ?,
or would it be then necessary to download the whole JPG2 file and extract the sub-image offline with
an JPG2-viewer like OpenEV ?

Yes you can expand the image larger than the current screen window size. When you load up the IAS Viewer the image is in it's own separate window. Simply expand the window that the image is in manually in the horizontal and vertical direction to the size you want. Also keep an eye on the system memory available in order to avoid the program crashing on you. I wish there was an easier way but that's the only way I know of.
Have fun.