This is a bug report. XnView always assumes that Planetary Data System (PDS) format images are in 8-bit format, rather than correctly reading the following line in a PDS file header:
SAMPLE_BITS = xx
where xx specifies the bit depth of the image (usually either 8-bit or 16-bit).
So, while it is extremely cool that XnView, when the "Display all image types" is checked under XnView's General options, will automatically display any files which are encoded in the Planetary Data System format (files with .IMG or .PDS extensions for example, the resulting displayed image is totally incorrect for 16-bit PDS images because a 16-bit PDS image file is being incorrectly read. Likewise, using XnView to convert 16-bit PDS images to another format such as TIFF results in a meaningless conversion since the original 16-bit image data is being incorrectly interpreted as 8-bit image data.
This presents a problem with Lunar Reconnaissance Orbiter (LRO) Narrow Angle Camera (NAC) images. These images are available in two formats. The raw Engineering Data Record (EDR) images are in companded 8-bit format. XnView has no problem converting these images into other formats since at present XnView assumes that all PDS images are in 8-bit format. The Calibrated Data Record (CDR) images have been decompanded by the LRO team and then converted into 16-bit format. This is where XnView runs into a problem since XnView does not look at the SAMPLE BITS file header line, as described above, in order to allow XnView to either properly display the image (by converting the 16-bit greyscale to 8-bit greyscale for display) or when converting the 16-bit greyscale to a TIFF image. Ideally XnView should offer the option to convert the 16-bit greyscale CDR image to another 16-bit file format such as a 16-bit TIFF image or to another 8-bit file format such as a 8-bit TIFF image.
The reason I would like this bug resolved is so that I can subsequently deconvolve 16-bit LRO CDR images, using deconvolution software, after first converting the 16-bit CDR images to either 16-bit TIFF or FITS images. NASA offers their NASAView program, but the Windows version of NASAView will not correctly display 16-bit PDS images. XnView is the only Windows product available which potentially can (if the above bug is fixed) either display 16-bit PDS images (after converting them on-the-fly to 8-bit in memory for display purposes) or convert them to other 16-bit image formats which the user can work with in image processing programs. Converting them to 16-bit TIFF format is a must. Also optionally converting them to 16-bit FITS format would be nice too.
In any event, getting XnView to properly handle 16-bit PDS images would open up a whole new world to Windows users who would love to work with 16-bit PDS images from a variety of NASA missions.
Best regards,
GoneToPlaid
Planetary Data System (PDS) format is hard coded to 8-bit
Moderators: helmut, XnTriq, xnview
-
GoneToPlaid
- Posts: 3
- Joined: Sat Oct 02, 2010 6:04 pm
Re: Planetary Data System (PDS) format is hard coded to 8-bi
+1, I support this requestGoneToPlaid wrote:...Ideally XnView should offer the option to convert the 16-bit greyscale CDR image to another 16-bit file format such as a 16-bit TIFF image or to another 8-bit file format such as a 8-bit TIFF image...Also optionally converting them to 16-bit FITS format would be nice too...
GoneToPlaid
XnViewMP Linux X64 - Debian - X64
Re: Planetary Data System (PDS) format is hard coded to 8-bi
This is an excellent bug report. Welcome to the forum!
John
Re: Planetary Data System (PDS) format is hard coded to 8-bi
NConvert can convert 16bits to 16bits files... XnView can't works on 16bits (XnViewMP will support it)
Pierre.
-
GoneToPlaid
- Posts: 3
- Joined: Sat Oct 02, 2010 6:04 pm
Re: Planetary Data System (PDS) format is hard coded to 8-bi
Hi everyone,
Last night I found a free Windows utility which will (if you set its parameters correctly) properly read the LRO CDR images. Google "pds_img_reader" and click on the first result. While PDS Image Reader will read the 16-bit calibrated LRO images, at present it only exports 8-bit BMP files. At least the Python source code is included in the package, but I am not a programmer. But at least this utility does allow you to first build a histrogram and find the min and max pixel values in the image or in a selected region of the image. The program will then convert the min and max range to 256 greyscale when saving as a BMP. Yet this still doesn't cut it for really good image deconvolution needs, and this is where XnView would be ideal for converting the 16-bit LRO calibrated (CDR) images to perhaps 16-bit TIFF format for subsequent image deconvolution. That would be sweet since then I could use XnView to convert the LRO 16-bit CDR images to 16-bit TIFF and then directly load those TIFF images into MaxIm DL for deconvolution.
This makes me think of another neat new program feature which could be added to XnView -- FFT analysis with automatic removal of all detected repeating noise patterns. Right now I have to first do that in Photoshop using a free FFT plugin. Using the FFT plugin, I have to then manually inspect the channel representing all detected repeating noise patterns, select areas to strongly Gaussian blur in order to remove repeating electronic noise patterns which vary somewhat in amplitude even though the basic pattern repeats, or use a round black paintbrush to manually mark out the "stars" representing the periods of detected repeating noise patterns. It seems to me that the programmer gurus at XnView could completely automate this process by detecting all "stars" and "lines" which are mirrored about the origin (the origin being the center of the fft representation of the image). Now that would be super slick since such patterns also can occur with CCD cameras when the image is read out too quickly to the frame buffer or if the CCD camera's electronics are noisy.
If the above is done, then...
-- Any XnView user could use automatic FFT to remove all electronic noise patterns in an image. This new feature alone would be appreciated by users since images could instantly be "cleaned up" by removing all repeating noise patterns.
-- Any XnView user could view and convert any 8-bit or 16-bit NASA PDS image format file to another 8-bit or 16-bit file such as TIFF for subsequent image processing.
Why stop there? How about...
-- Add automatic descreening capabilities to XnView, similar to the Satva Descreen algorithms. That way XnView users can automatically descreen scanned photos from newspapers or magazines.
-- Add automatic PSF detection for the entire image, including detection of variable PSF due to off-axis lens aberrations, so that users can automatically deconvolve images which are blurred either due to lens aberrations, incorrect focus, or motion blur. The Lucy-Richardson image deconvolution algorithms probably are the simplest to apply. The one thing which no programmer of image deconvolution software seems to have ever done is to write their code to deconvolve images in smaller overlapping chunks of the overall image. This would be a deconvolution solution which would automatically accommodate RAM size limitations of the user's computer. Just for grins, I tried deconvolving overlapping 512x512 chunks of a 2000x2000 image, building up a complete deconvolved image by overlaying the chunks to their correct positions in the final image. The deconvolution result was the same as when I deconvolved the entire 2000x2000 image in one step. The issue is that deconvolution of the entire image in one shot takes far longer since my computer was constantly swapping data to and from my hard drive.
Speaking of image deconvolution, the best software I have come across is written by Dr Paul J. Tadrous. Unfortunately his software is a pita to use since he is a poor programmer. See http://deconvolve.net/ for info and examples of what his software can do. Now imagine XnView's programmers actually incorporating Tadrous's image deconvolution algorithms into an automatic interface which is literally "click and apply." Indeed, this could become a separate paid for feature or plugin for XnView, allowing professional photographers to clean up slightly blurred images so that they are nearly tack sharp. That is worth something -- especially if Tadrous's algorithms for the automatic detection of the image's PSF could be implemented in XnView.
In any event, the code to implement most of the above new features wouldn't be all that much -- especially when one considers the programming skills of the XnView programmers. Utilities for most of the above already exist and in many cases under GNU, but in virtually all cases the authors obviously are not adept programmers.
Well, there you have it for what its worth.
--GTP
Last night I found a free Windows utility which will (if you set its parameters correctly) properly read the LRO CDR images. Google "pds_img_reader" and click on the first result. While PDS Image Reader will read the 16-bit calibrated LRO images, at present it only exports 8-bit BMP files. At least the Python source code is included in the package, but I am not a programmer. But at least this utility does allow you to first build a histrogram and find the min and max pixel values in the image or in a selected region of the image. The program will then convert the min and max range to 256 greyscale when saving as a BMP. Yet this still doesn't cut it for really good image deconvolution needs, and this is where XnView would be ideal for converting the 16-bit LRO calibrated (CDR) images to perhaps 16-bit TIFF format for subsequent image deconvolution. That would be sweet since then I could use XnView to convert the LRO 16-bit CDR images to 16-bit TIFF and then directly load those TIFF images into MaxIm DL for deconvolution.
This makes me think of another neat new program feature which could be added to XnView -- FFT analysis with automatic removal of all detected repeating noise patterns. Right now I have to first do that in Photoshop using a free FFT plugin. Using the FFT plugin, I have to then manually inspect the channel representing all detected repeating noise patterns, select areas to strongly Gaussian blur in order to remove repeating electronic noise patterns which vary somewhat in amplitude even though the basic pattern repeats, or use a round black paintbrush to manually mark out the "stars" representing the periods of detected repeating noise patterns. It seems to me that the programmer gurus at XnView could completely automate this process by detecting all "stars" and "lines" which are mirrored about the origin (the origin being the center of the fft representation of the image). Now that would be super slick since such patterns also can occur with CCD cameras when the image is read out too quickly to the frame buffer or if the CCD camera's electronics are noisy.
If the above is done, then...
-- Any XnView user could use automatic FFT to remove all electronic noise patterns in an image. This new feature alone would be appreciated by users since images could instantly be "cleaned up" by removing all repeating noise patterns.
-- Any XnView user could view and convert any 8-bit or 16-bit NASA PDS image format file to another 8-bit or 16-bit file such as TIFF for subsequent image processing.
Why stop there? How about...
-- Add automatic descreening capabilities to XnView, similar to the Satva Descreen algorithms. That way XnView users can automatically descreen scanned photos from newspapers or magazines.
-- Add automatic PSF detection for the entire image, including detection of variable PSF due to off-axis lens aberrations, so that users can automatically deconvolve images which are blurred either due to lens aberrations, incorrect focus, or motion blur. The Lucy-Richardson image deconvolution algorithms probably are the simplest to apply. The one thing which no programmer of image deconvolution software seems to have ever done is to write their code to deconvolve images in smaller overlapping chunks of the overall image. This would be a deconvolution solution which would automatically accommodate RAM size limitations of the user's computer. Just for grins, I tried deconvolving overlapping 512x512 chunks of a 2000x2000 image, building up a complete deconvolved image by overlaying the chunks to their correct positions in the final image. The deconvolution result was the same as when I deconvolved the entire 2000x2000 image in one step. The issue is that deconvolution of the entire image in one shot takes far longer since my computer was constantly swapping data to and from my hard drive.
Speaking of image deconvolution, the best software I have come across is written by Dr Paul J. Tadrous. Unfortunately his software is a pita to use since he is a poor programmer. See http://deconvolve.net/ for info and examples of what his software can do. Now imagine XnView's programmers actually incorporating Tadrous's image deconvolution algorithms into an automatic interface which is literally "click and apply." Indeed, this could become a separate paid for feature or plugin for XnView, allowing professional photographers to clean up slightly blurred images so that they are nearly tack sharp. That is worth something -- especially if Tadrous's algorithms for the automatic detection of the image's PSF could be implemented in XnView.
In any event, the code to implement most of the above new features wouldn't be all that much -- especially when one considers the programming skills of the XnView programmers. Utilities for most of the above already exist and in many cases under GNU, but in virtually all cases the authors obviously are not adept programmers.
Well, there you have it for what its worth.
--GTP
-
GoneToPlaid
- Posts: 3
- Joined: Sat Oct 02, 2010 6:04 pm
Re: Planetary Data System (PDS) format is hard coded to 8-bi
Hi Pierre,xnview wrote:NConvert can convert 16bits to 16bits files... XnView can't works on 16bits (XnViewMP will support it)
Okay, NConvert will do the job when working with 16bit images, but the problem is that NConvert, like XnView, ignores the SAMPLE_BITS = 16 parameter in the PDS file header. Both NConvert and XnView assume that SAMPLE_BITS is set to 8 bits greyscale, resulting in a 16bit greyscale PDS image being incorrectly converted into an 8bit greyscale image which doesn't even resemble the original image since the 16bit data wasn't being read correctly.