I had a problem with ArcGIS Image Server --- automation commad ???Iscommand.exe???
Obviously, the image server can accept the binary floating point format (IEEE floating point -- BinaryFlt) ??? .flt thru GDAL. BinaryFlt has two Byte-Order (Big Endian and Little Endian) and the binaryFlt hdr file calls MSBFIRST or LSBFIRST ??? see the attached example hdr file.
However, when I ran the command ???iscommand.exe C:\workspace\Temp\Test_Add_Flt.ISDef\Scripts\AddRasterDatasets-001.ISCmd --FullFile=D:\workspace\ImgServer_Test\btrx_100128b%001048_228_09_XLP.flt???, the image server created the derived Images and .RPDef files -- attached please find one example. I found that image server create the one line ???<byteorder>I</byteorder>??? in the example .RPDef??? though the HDR days that it is MSBFIRST. Obviously the image server ignored the definition of Byte Order in the HDR file and assumed all binaryFlt files are Little Endian. So the pixel values for the derived images (pyramids) created by iscommand.exe are incorrect and .RPDef file includes the wrong Byte Order definition ???I???. When I changed the Byte Order as ???<byteorder>M</byteorder>???, the display for the original binaryFlt file will be correct by opening .ISDef file. But the derived images are still wrong values since the Iscommand.exe re-sample the flt file as Little Endian. If I opened the image service in the client side, the pixel value was interporated as "Little Endian".
I do not know if this is the known issue for the image server 9.3 Iscommand.exe and already fixed in image server 9.31 or image server 10. Or am I missing some thing?
Kevin
