Hi Robert, > I have downloaded the windows command line utility ncdump and use it to > create an ASCII version of an HDF5 file I downloaded from the ISCCP data > serve r. D1 Cloud Data. > > The command line I used is: ncdump -l 1212 inputfile > output file > > I have found that the ncdump routine has modified some of the values > from the original input file. > > For example: The value 255 from the input file is changed to the value of - > 1. (255 is supposed to represent an undefined value.) > > The value 201 is changed to the value of -55 > > The value of 190 is changed to -66 > > The value of 144 is changed to -112 (this happens to > be a longitude value in the file) > > To the best of my knowledge this is an HDF5 formatted file. > > Is this a known problem with this utility or should I be including > addition command parameters in the command line. It looks like ncdump is interpreting these 8-bit values as signed integer bytes rather than unsigned integers bytes. The range of a signed byte is -128 to 127, whereas the range of an unsigned byte is 0 to 255. To get the equivalent signed value from the unsigned value, you can subtract 256. An 8-bit byte can represent either range of integers, depending on what type the variable is declared. The netCDF-3 library only supports 3 integer types, and they are all signed: byte (8 bits), short (16 bits), and int (32 bits). The netCDF-4 library (and the ncdump utility that accompanies that version) supports those 3 types but an additional 64-bit type (long), as well as the four unsigned types corresponding to eacho of the four integer signed types. This is documented in the netCDF 3.6.3 User's Guide in Appendix C http://www.unidata.ucar.edu/netcdf/old_docs/docs_3_6_3/netcdf.html#NetCDF-Classic-Format where it says: Note on byte data: It is possible to interpret byte data as either signed (-128 to 127) or unsigned (0 to 255). When reading byte data through an interface that converts it into another numeric type, the default interpretation is signed. There are various attribute conventions for specifying whether bytes represent signed or unsigned data, but no standard convention has been established. The variable attribute â_Unsignedâ is reserved for this purpose in future implementations. Was the HDF5 data you are reading declared to be of type unsigned byte? If so, it ought to be handled correctly by the ncdump utility in netCDF-4, the latest version of which is 4.1.2rc1, available from the netCDF home page. If that doesn't work and the HDF5 type was declared as unsigned, you've identified a bug in the library that we'll have to fix. --Russ Russ Rew UCAR Unidata Program address@hidden http://www.unidata.ucar.edu Ticket Details =================== Ticket ID: AKJ-370049 Department: Support netCDF Priority: Normal Status: Closed
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.