search

DOI-USGS / ISIS3

Integrated Software for Imagers and Spectrometers v3. ISIS3 is a digital image processing software package to manipulate imagery collected by current and past NASA and International planetary missions.
https://isis.astrogeology.usgs.gov
Other
200 stars 168 forks source link

issue with isis2std creating usable tiffs in Isis 3.4.0 #1409

Closed ascbot closed 4 years ago

ascbot commented 5 years ago

Author Name: Tammy Becker (Tammy Becker)

External Post: https://isis.astrogeology.usgs.gov/IsisSupport/index.php/topic,3504.0.html

Hi everyone,

I've been having an issue using Isis 3.4.0 where when I run isis2std to turn my cube into a tiff, the file that it creates isn't readable by any programs that should be able to read tiffs, even though there are no errors. I was able to run isis2std in Isis 3.3.1 using the same command successfully, with the resulting tiff being 830MB, so I don't think size is an issue?

This is an example of the command that I used: isis2std from=copern_controlled_1.8mpp_pho.cub+1 to=copernicus_controlled_1.8mpp_pho_mosaic.tif format=tiff stretch=manual minimum=0.0 maximum=0.04

I've also tried it without the +1 for the band at the end and without the file extension for the to= parameter.

Thanks!

Steps to reproduce:

I have been able to reproduce the problem (xv and photoshop cannot open any of the output tifs). No errors, isis2std seems to run through completion

Test files and working area: /work/users/tbecker/IsisTesting/Isis2std/

1st input: one band needs to be specified (entire file=52G) input=/work/projects/lro/minirf/Level1/NorthPole/120504_RUN/MOSAIC//NP_70to90N_0to360E_S1_180to360_MOS.cub+1

2nd input: original reduced by 1/2 (one band) NP_70to90N_0to360E_S1_180to360_MOS_half_notrack.cub

3rd input: Original reduced by 10 NP_70to90N_0to360E_S1_180to360_MOS_smby10_notrack.cub

ascbot commented 5 years ago

Original Redmine Comment Author Name: Trent Hare (Trent Hare) Original Date: 2012-08-08T21:31:56Z

Since there seems to be a need to write out Tiffs larger than 4GB (e.g. BiGTiff) and the ability write/read 8/16/ and 32bit Tiffs maybe we can use this oppertunity to start using the GDAL library w/ GeoTiff support into the mix? This might help us get a handle on how to potentially use GDAL as a pixel reader in the future.

The ISIS exported tiffs since 3.4.0 has been pretty iffy, even the ones that use to work did not have a propoer tiff header.

thanks, Trent

ascbot commented 5 years ago

Original Redmine Comment Author Name: Tammy Becker (Tammy Becker) Original Date: 2012-08-21T17:57:36Z

I have tested a recent fix by Steven under /work/projects/isis/latest/m00579_linux/isis

The output are on /usgs/shareall/TEMP/tbecker/ 812M Aug 21 09:55 halflargefile_1band_m0579_21Aug.tif 3.2G Aug 21 09:56 largefile_m0579_21Aug.tif 34M Aug 21 09:56 smallerby10_m0579_21Aug.tif

photoshop will now open these files....'xv' will not, including the smallest one unfortunately

ascbot commented 5 years ago

Original Redmine Comment Author Name: Tammy Becker (Tammy Becker) Original Date: 2012-09-14T18:24:50Z

Tammy will test this for small and large tiff's...and try xv under Production.

ascbot commented 5 years ago

Original Redmine Comment Author Name: Tammy Becker (Tammy Becker) Original Date: 2012-09-27T17:59:59Z

Tammy tested the tif option for a smaller image under /usgs/pkgs/isis3production2012-09-25/isis

The output tif can still be opened by photoshop and windows-photo-viewer, unfortunately, xv still cannot open it.

ascbot commented 5 years ago

Original Redmine Comment Author Name: Steven Lambright (Steven Lambright) Original Date: 2012-10-01T23:34:37Z

Are the TIFFs being produced actually invalid?

'xv' on astrovm1 cannot read a tiff I created, but on Fedora Core 16 (my desktop) xv had no problem opening the tiff.

So I created a tiff on astrovm1 using gimp, and 'xv' still could not read it. I think the astrovm's xv is missing tiff support.

ascbot commented 5 years ago

Original Redmine Comment Author Name: Tammy Becker (Tammy Becker) Original Date: 2012-10-03T18:24:06Z

Trent helped suggest using 'gdalinfo' to check out the 'guts' of the tiff output:

ast{201}> /usgs/dev/contrib/bin/gdalinfo -stats halflargefile_1band_m0579_21Aug.tif Driver: GTiff/GeoTIFF Files: halflargefile_1band_m0579_21Aug.tif halflargefile_1band_m0579_21Aug.tfw Size is 41382, 41382 Coordinate System is `' Origin = (-612715.276978599955328,612715.276978599955328) Pixel Size = (29.612646898584000,-29.612646898584000) Image Structure Metadata: COMPRESSION=DEFLATE INTERLEAVE=BAND Corner Coordinates: Upper Left ( -612715.277, 612715.277) Lower Left ( -612715.277, -612715.277) Upper Right ( 612715.277, 612715.277) Lower Right ( 612715.277, -612715.277) Center ( 0.0000000, -0.0000000) Band 1 Block=41382x1 Type=Byte, ColorInterp=Gray Minimum=1.000, Maximum=255.000, Mean=23.311, StdDev=31.973 Metadata: STATISTICS_MINIMUM=1 STATISTICS_MAXIMUM=255 STATISTICS_MEAN=23.310673295072 STATISTICS_STDDEV=31.973355537037

ascbot commented 5 years ago

Original Redmine Comment Author Name: Trent Hare (Trent Hare) Original Date: 2012-10-03T22:28:17Z

Hold the presses. Currently there is still an issue with the Tiff creation in isis2std. The current default for the Tiff output is to use a deflate compression (zlib). Now the "deflate" implementation in isis2std is NOT supported by all apps. For example the two main "science" apps used by the community, ENVI/IDL and ArcMap, do not support this deflate method. Now if I re-encode the Tiff image to use the deflate method used in GDAL (called AdobeDeflate), both application support it. This is odd since ArcMap actually uses GDAL to read images (however it is an older version of GDAL which may be the issue). To figure this out I used "/usgs/pkgs/local/v002/bin/tiffinfo" on the files.

1.) The default for Tiff output should be raw (no compression). 2.) For compression it would be nice to "fix" this deflate method. 3.) For compression it would also be nice to support LZW and Packbits also. 4.) For larger images being able to output tiled Tiffs (instead of stripped) is important (raw or compressed). 5.) I am still desperately missing the projection section in Tiffs and Jp2s (as shown above in the gdalinfo report where Coordinate System is blank). Without this I will continue to not recommend isis2std and recommend 'stretch' (or 'bit2bit' when fixed) and 'gdal_translate' for proper geoTiff (8,16, 32bit) conversion for science applications.

ascbot commented 5 years ago

Original Redmine Comment Author Name: Trent Hare (Trent Hare) Original Date: 2012-10-03T22:45:52Z

Thus I would still contend for isis2std, to add the option or replace with GDAL which supports (Tiff, PNG, Jpeg, Jp2, FITs, NetCDF, ASCII, ...) even as a static binary.

ascbot commented 5 years ago

Original Redmine Comment Author Name: Tammy Becker (Tammy Becker) Original Date: 2012-10-03T22:46:10Z

While this post was not assigned, there was hope that the fix to the related Mantis post (#579) fixed this issue as well. Based on further evaluation of the tiff output, I am setting this to feedback for now.

It's a good heads-up for the related #579 issue as well.

ascbot commented 4 years ago

I am a bot that cleans up old issues that do not have activity.

Happy Birthday to this issue! :birthday:

Unfortunately, this issue has not received much attention in the last 12 months. Therefore, I am going to close it. Please feel free to reopen this issue or open a new issue sometime in the future. If this issue is a bug report, please check that the issue still exists in our newest version before reopening.