>From: "Craddock, Mary Ellen" <address@hidden> >Organization: Northrop Grumman Information Technology, TASC >Keywords: 200306121159.h5CBxXLd023117 TASC remap2 Hi Mary Ellen, > You're correct readd.for does not check to see if the bytes need to >be swapped. I don't believe I said that, and if I did, I was mistaken. readd.for does check to see if the header bytes need to be flipped by calling ISAFMT: C Copyright(c) 1997, Space Science and Engineering Center, UW-Madison C Refer to "McIDAS Software Acquisition and Distribution Policies" C in the file mcidas/data/license.txt SUBROUTINE READD(ANUM,ENTRY) C *** $Id: readd.f,v 1.11 2000/08/25 20:06:16 russd Rel $ *** C $ SUBROUTINE READD(ANUM, ENTRY) (RCD) C $ READS DIRECTORY ENTRY FROM AREA/SOUNDING DIRECTORY 'DATDIR' C $ ANUM = (I) INPUT AREA NUMBER C $ ENTRY = (I) OUTPUT 64 WORD DIRECTORY ENTRY (INTEGER ARRAY) C $$ READD = AREA IMPLICIT INTEGER(A-Z) CHARACTER*512 CFILE INTEGER ENTRY(64) DATA ENTSIZ/64/ DATA MAXNUM/9999/ IF(ANUM.LT.0.OR.ANUM.GT.MAXNUM) THEN CALL EDEST(' Invalid AREA number=',ANUM) CALL mcABORT(0) ENDIF I=ARANAM(ANUM,CFILE) I=LWI(CFILE,0,ENTSIZ,ENTRY) C C--- Check for byte flipping C FLIP = ISAFMT(ANUM) IF( FLIP .NE. 0) CALL FAHED(ENTRY) RETURN END C Copyright(c) 1997, Space Science and Engineering Center, UW-Madison C Refer to "McIDAS Software Acquisition and Distribution Policies" C in the file mcidas/data/license.txt FUNCTION ISAFMT( ANUM ) C *** $Id: isafmt.f,v 1.7 1999/10/11 19:03:48 billl Rel $ *** C $ FUNCTION ISAFMT(GFNO) (DAS) C $ IS the Area ForMaT? Is the area byte flipped? C $ INPUT: C $ ANUM = (I) Area number C $ OUTPUT: C $ ISAFMT = (I) = 0 native format C $ = -1 byte flipped format C $$ ISAFMT = AREA, CONVERSION IMPLICIT INTEGER (A-Z) PARAMETER (FLGWRD = 1, VAL = 4) CHARACTER*512 CFILE INCLUDE 'hex80.inc' DATA MISS/HEX80/ ISAFMT = 0 I = ARANAM(ANUM, CFILE) I = LWI(CFILE, FLGWRD, 1, FLAG) IF(FLAG .EQ. VAL) RETURN C C--- If file not exist, just return C IF (FLAG .EQ. MISS) RETURN ISAFMT = -1 RETURN END ISAFMT looks at word 2 of the AREA header and checks to see if it is a '4' or a MISS (-2139062144) value. If it is either of these, it returns a '0' (zero), otherwise it returns a -1. When READD gets a -1 (actually, any non-zero) return from ISAFMT it calls FAHED to flip bytes in the header. FAHED then flips the bytes in words 1-20; checks word 21 to see if it contains character values and flips it if it doesn't; flips bytes in words 22-24; flips bytes in words 54-56; checks word 57 to see if it contains characters and flips it if it doesn't; and then flips bytes in words 58-64. >I did find a program axform.pgm that does call a subroutine FLIP >which seems to be what we could use to accomplish the byte swap. I suppose >we could either modify readd.for to call FLIP if necessary or modify >remap2.pgm to use FLIP as a keyword. readd.for already does the work needed. Is it possible that the copy of readd.for that you are using does not look _exactly_ like the one I listed above? This would be very strange indeed. > I did try DF which works. df.pgm does call readd() so the byte swap >must be done before this subroutine call.... Right, after reading readd.for, isafmt.for, and fahed.for this morning was reacquainted with the fact that the READD call does all of the byte flipping work that is needed. >however, I can't find it. Both >IMGDISP and DF work correctly on the Linux box. This tells me that your copy of readd.for must be identical to the one I listed above. >I completely understand how >busy you are. I appreciate any time you can spare to help me out. I will do >some reading on FLIP to see how I might incorporate its use. What would be useful to me would be to have one of the images that you are having problems with. You can FTP it to our machine here at Unidata as follows: ftp ftp.unidata.ucar.edu <user> umcidas <pass> XXXXXX cd incoming/data binary put AREAnnnn <- one of the AREA files you are having problems with quit and then let me know that you have successfully transferred it. I can then run the copy of remap2.k that I built on our RedHat 7.3 Linux system and see if I get the same results as you. I can tell you, however, that the test I ran with your remap2.k did use an input AREA file that was created on a platform with a different byte order than the one I ran remap2.k on. The program ran with no errors or warnings, but the resulting data in the various bands was odd: "- display of BAND=1 data is black - display of BAND=2 looks sorta reasonable - display of BAND=3 is shows one value only - display of BAND=4 looks washed out - display of BAND=6 has a weird strip diagonally across it I can't explain this." As soon as I get an image that I can get to fail, I can find out where the failure is. Tom
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.