Reading BMP graphic file
Luu Quang Hung
program. So I wrote one. The following program I would like to talk is
given below.
The program seems to read well the header information as well as some
initial data of the BMP-file. However, it breaks down at some steps.
Anyone who has experience, could you please give me an advice?
Thank you very much!!
PROGRAM BITTOCK
!--------------------------------------------------------------------------------------!
! !
! BITTOCK = BITmap to TOpology Converter Kit, v0.0.1, date:
2009-02-27 !
! Read bitmap topology data (eg. sea bottom) and convert to fortran
unformatted data !
! (C)Luu Quang Hung, http://www-ocea.kugi.kyoto-u.ac.jp/luuqh/
!
! !
!--------------------------------------------------------------------------------------!
use DFLIB
implicit none
parameter fin='example.bmp',fout='example.dat'
call ConvertBMP(fin,fout)
stop
END
SUBROUTINE ConvertBMP(fin,fou)
implicit none
character*12 fin,fou
character*54 header
character*1 s
integer rgb,im,jm,i,j,k,t
open(unit=1,file=fin,status='old',recl=1)
open(unit=2,file=fou,form='unformatted')
read(1,'(a54,$)')header(1:54)
call Bits(4,header(19:22),im) !Width
call Bits(4,header(23:26),jm) !Height
print*,'Image Size',im,jm
t = 0
do i = 1,im
do j = 1,jm
do k = 3,1,-1 !Read in BGR order, not RGB
t = t + 1
read(1,'(a2,$)')s
call Bits(1,s,rgb)
write(2)rgb
print*,rgb,t,i,j,im*jm*3
enddo
enddo
enddo
close(1)
close(2)
return
END SUBROUTINE
SUBROUTINE Bits(n,s,b)
integer n ! length of bit
integer b ! bit value
character*n s ! string of bmp bit
integer i,b1,b2
b2 = 0
do i = 1,n
b1 = ichar(s(i:i))
b1 = b1*256**(i-1)
b2 = b2 + b1
enddo
b = b2
return
END SUBROUTINE
Arjan
To circumvent problems with numbers of bits and bytes that have to
be written, and which Fortran refuses to write due to some silly
restrictions, I use a C-routine and call it from Fortran.
In contrast with the coordinate transformations
in C, that I have been trying to get to work in another discussion
on this forum, the .bmp-routine runs smoothly.
Arjan
E-mail: Arjan.van.Dijk [at] RIVM [dot] nl
Arjan
that Fortran is well capable of doing .bmp-files all by itself. He
even sent me some code showing how to do it. It works with g95 and
gfortran, but not with Portland pgf90... The single statement that is
rejected by Portland is:
OPEN(ScratchFile,FILE=FName,ACCESS='transparent', STATUS='replace')
It seems that ACCESS='transparent' is not supported.
I tried FORM='UNFORMATTED', since I saw no other specifyer in the
above call for opening the file as unformatted/binary, but that didn't
work.
Anyone here know a replacement for ACCESS='transparent'?
Regards,
Arjan
Gary Scott
difficulty processing .bmp formats in Fortran. Of course there are tiny
little non-standardisms, but I haven't personally come across a Fortran
compiler that could not handle the problem.
--
Gary Scott
mailto:garylscott@sbcglobal dot net
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
Jan Vorbrüggen
> I tried FORM='UNFORMATTED', since I saw no other specifyer in the
> above call for opening the file as unformatted/binary, but that didn't
> work.
UNFORMATTED won't do because the file still contains or the RTL still
expects record markers. TRANSPARENT is one of the non-standard pre-F03
was of saying "read the bits and give 'em to me, no massage please".
You'd need to check what the compiler in question supports as an
extension for this purpose, if such an extension exists at all.
Jan
Arjan
Apparently I was wrong with my statement. The only problem left now
is the ACCESS='TRANSPARENT' specifyer not being universally
supported...
@Jan:
> You'd need to check what the compiler in question supports as an
> extension for this purpose, if such an extension exists at all.
I just cross-posted the same question to the Portland forum.
See what they come up with.
Arjan
Arjan
I'm sorry, I meant Gary...
A.
e p chandler
ACCESS="stream" is F2003.
>
> Regards,
>
> Arjan
Craig Powers
> Someone who read my above reaction has been so kind as to point out
> that Fortran is well capable of doing .bmp-files all by itself. He
> even sent me some code showing how to do it. It works with g95 and
> gfortran, but not with Portland pgf90... The single statement that is
> rejected by Portland is:
>
> OPEN(ScratchFile,FILE=FName,ACCESS='transparent', STATUS='replace')
>
> It seems that ACCESS='transparent' is not supported.
The basic semantics of this statement are commonly supported pre-F2003
(where they become officially spelled "ACCESS='STREAM'"). However, the
spelling is inconsistent. In ifort, the spelling is "ACCESS='DIRECT',
FORM='BINARY'". I think those two (access transparent, or access
direct, form binary) are the most common non-standard spellings.
Arjan
Computer says "no"...
A.
Arjan
> direct, form binary) are the most common non-standard spellings.
ACCESS = 'DIRECT' asks for a record length. Setting it to e.g. 1 does
not work.
The FORM='BINARY' specifier is not recognized...
A.
me...@skyway.usask.ca
works - haven't more recent fortrans caught up yet ?.
To find that out I tried every combination of switches.
It's better to have something non-standard that works
rather than something standard which doesn't.
my 2c
Chris
Arjan
> rather than something standard which doesn't.
Agree. So far the Portland compiler still resists against any attack!
A.
Richard Maine
> > It seems that ACCESS='transparent' is not supported.
> > I tried FORM='UNFORMATTED', since I saw no other specifyer in the
> > above call for opening the file as unformatted/binary, but that didn't
> > work.
>
> UNFORMATTED won't do because the file still contains or the RTL still
> expects record markers.
Odd. I don't recall the details, but is BMP really a text file format?
That would seem surprising. In particular, I wonder what the nature of
the record markers is. Are they the normal text record markers for
whatever system you are running on? If that is the case, then the file
format would be non-portable without transofmation. You would have lf
for some systems, cr/lf for others, cr for others, and a completely
different scheme for yet others.
If the format has "record markers" whose form is defined as part of the
format rather than being whatever the host system happens to use for
text files, then that would be something most appropriately and portably
dealt with as unformatted - not formatted. Just because the file has
something called a record marker, that doesn't automatically translate
into "formatted access".
"Formatted" is for text files; that's really all. Using it for anything
other than text is fraught with "issues". I've done it on rare occasion,
but it has many portability complications and is best avoided. I can't
even recall all the different kinds of complications I've seen with it.
This posting would get long and side-tracked if I tried.
I'll just repeat and summarize a point mentioned by others in the
thread. Prior to f2003, there is no portable way to deal with files hat
are arbitrary byte streams defined by non-Fortran means. Most pre-f2003
compilers have some extension for the purpose. It has been quite a while
since I've run into an exception. There are early f77 compilers that
can't do it, but I can't off-hand name one. I think I recall Lahey ELF90
as being an exception of sorts, but then that didn't actually claim to
be a Fortran compiler; rather it compiled a subset of Fortran that Lahey
called ELF. The Lahey Fortran (as opposed to ELF) compilers could do it
fine.
The extensions in various compilers even have structural similarities,
and there are groups of compilers that share the same syntax for them.
But you won't find a form that works unchanged on all compilers. You
might possibly find one that works on a sufficiently large subset to fit
some particular need, but it won't work on others.
So you can do the job pre-f2003. I have quite a lot of experience in
such things, as do others here. But don't expect to do it portably.
That's a lot of why f2003 standardized the feature. There is a lot of
debate about some things in the standards process, but this one fits
most people's criterion for the kinds of things that beg for
standardization. It was a feature widely regarded as important enough
for all current compilers to implement, but the implementations were
different in syntax from compiler to compiler.
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
nm...@cam.ac.uk
Richard Maine <nos...@see.signature> wrote:
>
>I'll just repeat and summarize a point mentioned by others in the
>thread. Prior to f2003, there is no portable way to deal with files hat
>are arbitrary byte streams defined by non-Fortran means. Most pre-f2003
>compilers have some extension for the purpose. It has been quite a while
>since I've run into an exception. There are early f77 compilers that
>can't do it, but I can't off-hand name one. I think I recall Lahey ELF90
>as being an exception of sorts, but then that didn't actually claim to
>be a Fortran compiler; rather it compiled a subset of Fortran that Lahey
>called ELF. The Lahey Fortran (as opposed to ELF) compilers could do it
>fine.
Er, not quite. MOST Fortran 77 compilers on systems which didn't
have an arbitrary byte stream file format didn't have such a facility;
I am pretty certain that IBM VS Fortran didn't, at least until after
I lost touch with it, but my memory of its minutiae is fading.
On the other hand, since the demise of the mainframes for Fortran
programming, who has used such a system? VMS added a byte stream
format when C started to become important.
Regards,
Nick Maclaren.
Richard Maine
> Er, not quite. MOST Fortran 77 compilers on systems which didn't
> have an arbitrary byte stream file format didn't have such a facility;
> I am pretty certain that IBM VS Fortran didn't, at least until after
> I lost touch with it, but my memory of its minutiae is fading.
>
> On the other hand, since the demise of the mainframes for Fortran
> programming, who has used such a system? VMS added a byte stream
> format when C started to become important.
There was a time when I did a lot of work on IBM mainframes, but that
was pre-f77. Probably about 1976 was the last time that I regularly used
one. After that, my exposure to them has been sparse. That was partly
intentionally so. I got on the board to spec our new "central computer"
in the early 80's partly to make sure we didn't get "stuck" with an IBM
mainframe, which I didn't want to see.
Craig Powers
This is something where the compiler's documentation is invaluable.
Compaq and subsequently Intel are great at documenting their extensions,
I would hope that this information would be available for other
compilers as well.
Incidentally, looking through the PGF documentation available on my
system (for version 7.0-6), I don't see anything that indicates support
for stream access, so PGF may not support this common extension to F9x.
nm...@cam.ac.uk
Richard Maine <nos...@see.signature> wrote:
>
>> Er, not quite. MOST Fortran 77 compilers on systems which didn't
>> have an arbitrary byte stream file format didn't have such a facility;
>> I am pretty certain that IBM VS Fortran didn't, at least until after
>> I lost touch with it, but my memory of its minutiae is fading.
>>
>> On the other hand, since the demise of the mainframes for Fortran
>> programming, who has used such a system? VMS added a byte stream
>> format when C started to become important.
>
>There was a time when I did a lot of work on IBM mainframes, but that
>was pre-f77. Probably about 1976 was the last time that I regularly used
>one. After that, my exposure to them has been sparse. That was partly
>intentionally so. I got on the board to spec our new "central computer"
>in the early 80's partly to make sure we didn't get "stuck" with an IBM
>mainframe, which I didn't want to see.
We were one of the last half dozen sites in the world to use an
IBM mainframe for general-purpose academic computing. I tried to
persuade others that we were backing a dying horse during our
final procurement, but failed.
By the end, I was porting 30% of all of our applications software
to MVS as well as doing two other jobs - it was a hopeless task.
That was also why I was the designer and main author of the first
fully functional C run-time interface to MVS and a consultant on
the second.
Regards,
Nick Maclaren.
Richard Maine
> Incidentally, looking through the PGF documentation available on my
> system (for version 7.0-6), I don't see anything that indicates support
> for stream access, so PGF may not support this common extension to F9x.
If the compiler doesn't support stream directly, about the next best
thing is direct access unformatted. That can run into problems with the
last part of a file if it has a "partial record", but it works ok with
some systems/compilers.
Also, direct access unformatted with a record length of 1 is specially
treated as a form of stream by some compilers. That might slip through
compiler documentation cracks, since it isn't a separate piece of
syntax.
nm...@cam.ac.uk
Richard Maine <nos...@see.signature> wrote:
>
>If the compiler doesn't support stream directly, about the next best
>thing is direct access unformatted. That can run into problems with the
>last part of a file if it has a "partial record", but it works ok with
>some systems/compilers.
Frankly, calling a simple C function is MUCH safer! Yes, that method
may work, but risking a library's error-handling code makes me twitch.
>Also, direct access unformatted with a record length of 1 is specially
>treated as a form of stream by some compilers. That might slip through
>compiler documentation cracks, since it isn't a separate piece of
>syntax.
I had forgotten that one! Thanks. I must check my course notes.
Regards,
Nick Maclaren.
Terence
The three most common methods of giveing parameters in the OPEN
statement for using stream data are:-
FORM='UNFORMATTED',ACCESS='TRANSPARENT', (Lahey, Fujitsiu)
FORM='BINARY',ACCESS='SEQUENTIAL', (MS, IBM, CVF.DVF,Intel, many
onthers .
When these don't work and nothing else does, than use:-
FORM='UNFORMATTED' ACCESS='DIRECT',RECL=256 or similar, and read and
write blocks and put in or extract bytes at will into/from the buffer
you are using.
This is actually VERY simple, very very few lines of code needed.
I started with version three for years, found out about version two
and never had to use version one. I use this "BINARY" method
extensively for writiing bit files and for writing WORD RTF documents
and HTML files
And I have NEVER used FORM='UNFORMATTED', ACCES='SEQUENTIAL:', ever!
I was in IBM in 1961 working with and on Fortran and wrote upwards,
internally, 'what's the point?' and they came back with "to read tape
files backwards". Tape, anyone?
Terence
AGAIN. :o)>
This is what I never used (to avoid jokes like "how true!").
FORM='UNFORMATTED', ACCESS='SEQUENTIAL',
nm...@cam.ac.uk
Terence <tbwr...@cantv.net> wrote:
>
>And I have NEVER used FORM='UNFORMATTED', ACCES='SEQUENTIAL:', ever!
>I was in IBM in 1961 working with and on Fortran and wrote upwards,
>internally, 'what's the point?' and they came back with "to read tape
>files backwards". Tape, anyone?
In 1961, the OPEN statement was a decade and a half in the future.
Regards,
Nick Maclaren.
Arjan
The probability that my parents already knew each other is existent.
A.
Terence
>
The JCL was there to trigger the opening and assign the unit number to
the file name.
It wasn't the non-existent open, it was the use of the count fields
either side of the written unformatted sequential record I was
querying the practicality of.
And if you wrote with a format statement you got formatted records; if
you didn't, you got prefixed and postfixed (to show length from both
directions) records of memory word copies of variables and the usual
tape EOR marks and EOF marks and so on.
I've got 56 sort-of-working once-Fortran II/Fortran IV programs of
1964 to 1966 vintage compiled as F66/F77. And a listing of my own
nuclear stability calculations (Fortran) off the 704 from 1961. And of
course, there isn't an OPEN statement in any of them.
nm...@cam.ac.uk
Terence <tbwr...@cantv.net> wrote:
>> In 1961, the OPEN statement was a decade and a half in the future.
>
>The JCL was there to trigger the opening and assign the unit number to
>the file name.
IBM JCL never opened a file except (in a limited way) for extremely
arcane formats that were never supported by Fortran. It attached a
file or files to the DD statement, and the first transfer opened it.
>It wasn't the non-existent open, it was the use of the count fields
>either side of the written unformatted sequential record I was
>querying the practicality of.
>
>And if you wrote with a format statement you got formatted records; if
>you didn't, you got prefixed and postfixed (to show length from both
>directions) records of memory word copies of variables and the usual
>tape EOR marks and EOF marks and so on.
In MFT, MVT and MVS, there NEVER WAS a count field either side of
the record. All of the libraries used VS or VBS format, and that
used only a prefix count. BACKSPACE was done by backtracking.
I don't think there was a Fortran compiler for PCP, so what system
are you referring to?
Regards,
Nick Maclaren.
Luu Quang Hung
+interesting discussion about this topic.
Unfortunately my compiler Compaq Visual Fortran 6 does support Terence
guidance.
> FORM='UNFORMATTED',ACCESS='TRANSPARENT', (Lahey, Fujitsiu)
> FORM='BINARY',ACCESS='SEQUENTIAL', (MS, IBM, CVF.DVF,Intel, many onthers .
I hope that there is any solution somewhere instead of transfering to
another compiler or dll-employment, isn't it?
Regards,
Gary Scott
FORM='binary'
open(10,file='filename.txt',form='binary)
is all you need to begin performing "stream" I/O in CVF.
Gary Scott
> Luu Quang Hung wrote:
>
>> Thank Adrjan, Terence and all others very much for providing useful
>> +interesting discussion about this topic.
>>
>> Unfortunately my compiler Compaq Visual Fortran 6 does support Terence
>> guidance.
>>
>>
>>> FORM='UNFORMATTED',ACCESS='TRANSPARENT', (Lahey, Fujitsiu)
>>> FORM='BINARY',ACCESS='SEQUENTIAL', (MS, IBM, CVF.DVF,Intel, many
>>> onthers .
>>
>>
>>
>> I hope that there is any solution somewhere instead of transfering to
>> another compiler or dll-employment, isn't it?
>>
>> Regards,
>
> I'm probably missing something here...Compaq Visual Fortran does support
> FORM='binary'
>
> open(10,file='filename.txt',form='binary')
>
> is all you need to begin performing "stream" I/O in CVF.
>
corrected
Terence
n...@cam.ac.uk wrote:
> >The JCL was there to trigger the opening and assign the unit number to
> >the file name.
>
> IBM JCL never opened a file except (in a limited way) for extremely
> arcane formats that were never supported by Fortran. It attached a
> file or files to the DD statement, and the first transfer opened it.
>
> >It wasn't the non-existent open, it was the use of the count fields
> >either side of the written unformatted sequential record I was
> >querying the practicality of.
> >
> >And if you wrote with a format statement you got formatted records; if
> >you didn't, you got prefixed and postfixed (to show length from both
> >directions) records of memory word copies of variables and the usual
> >tape EOR marks and EOF marks and so on.
>
> In MFT, MVT and MVS, there NEVER WAS a count field either side of
> the record. All of the libraries used VS or VBS format, and that
> used only a prefix count. BACKSPACE was done by backtracking.
>
> I don't think there was a Fortran compiler for PCP, so what system
> are you referring to?
I don't understand half? most? of what Nick is referring to.
I repeat: the JCL defined the unit number, name and device to any
program, including Fortran-compiled programs.
That data wass passed to the program so that when it has to open a
file (first I/o on that unit number) it knows how to, (name, unit,
mode). And that decides the mode of how the data will in future be
written or read to/from that device number. Note: the file name was on
the tape header record.
The "prefix count" phrase used by Nick is precisely the same as my
"prefix and postfix" and "count field" phases. It was on both ends of
the record. "So nothing changed when you were reading backwards").
Backspacing was by processing the signal received by the tape unit
electronics as it read magnetic impulses under the heads as the tape
was moved in the "backwards" direction. Nick may call it backtracking
but that sounds like book-keeping. It was all micro-programmed.
In the latest IBM machines that I actually worked on the software/OS
parts, there were channel command chains set up in the software
control to carry out the desired functions. I WORKED on IBM hardware
at Winchester Labs in the UK and in the LaGoude lab in France. And in
software I wrote the 1406 multiplexer operating system and other
'stuff', mainly for 1610, 1401 and 1440. Later I wrote mutiplexing
software for remote terminals anywhere to access several mainframes in
different continents, simulating a direct terminal connection. "3270
mode" rings a bell.
MFT, MVT and MVS are all way past my time in IBM but these operating
system names passed my desk with the IBM 360 50, 60 etc, days much
later ('68 on ?) as purchasing/planning manager, before I went into
process control of refineries.
Glen Herrmannsfeldt
> n...@cam.ac.uk wrote:
>>> The JCL was there to trigger the opening and assign
>>> the unit number to the file name.
>>IBM JCL never opened a file except (in a limited way) for extremely
>>arcane formats that were never supported by Fortran. It attached a
>>file or files to the DD statement, and the first transfer opened it.
A file (data set, actually) would be created or deleted based on
JCL, but not 'opened.'
>>>It wasn't the non-existent open, it was the use of the count fields
>>>either side of the written unformatted sequential record I was
>>>querying the practicality of.
>>>And if you wrote with a format statement you got formatted records; if
>>>you didn't, you got prefixed and postfixed (to show length from both
>>>directions) records of memory word copies of variables and the usual
>>>tape EOR marks and EOF marks and so on.
VBS has block lengths and record lengths at the beginning, not the end.
FB has fixed length records with no length fields. (Not counting
the length field internal to the disk drive, such that it knows
where the block ends.)
>>In MFT, MVT and MVS, there NEVER WAS a count field either side of
>>the record. All of the libraries used VS or VBS format, and that
>>used only a prefix count. BACKSPACE was done by backtracking.
The maximum record length and block length are 32767. With a block
in the buffer it is pretty easy to go through the counts and find
a specific record.
>>I don't think there was a Fortran compiler for PCP, so what system
>>are you referring to?
I presume Fortran G would run on a PCP system with enough memory.
> I don't understand half? most? of what Nick is referring to.
> I repeat: the JCL defined the unit number, name and device to any
> program, including Fortran-compiled programs.
> That data wass passed to the program so that when it has to open a
> file (first I/o on that unit number) it knows how to, (name, unit,
> mode). And that decides the mode of how the data will in future be
> written or read to/from that device number. Note: the file name was on
> the tape header record.
I am not sure about mode. One problem has been that Fortran wants to
open for INOUT (an IBM term) even if starting with READ. There is
a JCL option to force INPUT mode, LABEL=(,,,IN), in cases where
needed, such as sharing data sets. The file name is on SL
(standard label) tapes, but no NL (unlabeled tapes).
> The "prefix count" phrase used by Nick is precisely the same as my
> "prefix and postfix" and "count field" phases. It was on both ends of
> the record. "So nothing changed when you were reading backwards").
As far as I know, Fortran can't do read backwards. One can use
BACKSPACE twice and read a record, and even do that in a loop.
With true read backwards, which IBM supports only for tapes, the
tape moves backward and data fills the buffer from the end toward
the beginning.
> Backspacing was by processing the signal received by the tape unit
> electronics as it read magnetic impulses under the heads as the tape
> was moved in the "backwards" direction. Nick may call it backtracking
> but that sounds like book-keeping. It was all micro-programmed.
Which I don't believe Fortran, or at least OS/360 Fortran, can do.
nm...@cam.ac.uk
Glen Herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
More-or-less "Precisely". We may disagree about a few minutiae of
those systems, or the way they were used, but this is all about the
basic design.
Here are a few minor niggles.
>>>IBM JCL never opened a file except (in a limited way) for extremely
>>>arcane formats that were never supported by Fortran. It attached a
>>>file or files to the DD statement, and the first transfer opened it.
>
>A file (data set, actually) would be created or deleted based on
>JCL, but not 'opened.'
Except (in a very limited sense) for ISAM and, later, VSAM. Fortran
supported neither!
>VBS has block lengths and record lengths at the beginning, not the end.
>FB has fixed length records with no length fields. (Not counting
>the length field internal to the disk drive, such that it knows
>where the block ends.)
All other Fortran-supported formats (VB, U, even D!) followed one
or the other of those two approaches.
>The maximum record length and block length are 32767. With a block
>in the buffer it is pretty easy to go through the counts and find
>a specific record.
Though VBS allowed spanning, where a record could be continued into
a later block, and so was effectively unlimited in size.
>I presume Fortran G would run on a PCP system with enough memory.
Yes, but would the library?
>As far as I know, Fortran can't do read backwards. One can use
>BACKSPACE twice and read a record, and even do that in a loop.
>With true read backwards, which IBM supports only for tapes, the
>tape moves backward and data fills the buffer from the end toward
>the beginning.
Yes. That was rarely used, though early sort products used it.
>> Backspacing was by processing the signal received by the tape unit
>> electronics as it read magnetic impulses under the heads as the tape
>> was moved in the "backwards" direction. Nick may call it backtracking
>> but that sounds like book-keeping. It was all micro-programmed.
>
>Which I don't believe Fortran, or at least OS/360 Fortran, can do.
I can't remember if it was possible, even in theory, but I am sure
that it was almost never used. The few Fortran programs I saw that
read in reverse order used BACKSPACE in a loop, as you described
above. And it was very unreliable, for software reasons.
Regards,
Nick Maclaren.
Glen Herrmannsfeldt
(snip)
>>I presume Fortran G would run on a PCP system with enough memory.
> Yes, but would the library?
I think so. What part do you think might not work.
As far as I know, PCP can do everything that OS/360 is supposed
to do with only one task running. Some SVCs don't do anything,
especially ones related to multitasking. Also, I believe that
there is no timer so date and time don't work.
PCP is supposed to be able to run PL/I (F), which usually
requires more of the OS than Fortran does. Among others,
it does a lot of GETMAIN/FREEMAIN and LINK macros.
>>As far as I know, Fortran can't do read backwards. One can use
>>BACKSPACE twice and read a record, and even do that in a loop.
>>With true read backwards, which IBM supports only for tapes, the
>>tape moves backward and data fills the buffer from the end toward
>>the beginning.
> Yes. That was rarely used, though early sort products used it.
Some time ago someone had TOS/360 running on Hercules. It took
fixing some bugs in read backwards support in code that had never
previously been tested. Otherwise, yes, it is mostly used for
sorting.
(snip)
-- glen
Glen Herrmannsfeldt
(snip)
>>The maximum record length and block length are 32767. With a block
>>in the buffer it is pretty easy to go through the counts and find
>>a specific record.
> Though VBS allowed spanning, where a record could be continued into
> a later block, and so was effectively unlimited in size.
I think that the RDW and BDW includes bits for that, but I thought
that LRECL was still limited to 32767. VBS allows for LRECL
greater than BLKSIZE, which was important when disk tracks
weren't that big.
This is important for Fortran (which I believe is what VBS was
created for), in that it determines the maximum record length
for an unformatted data set. I know I never wrote one larger
than that.
-- glen
nm...@cam.ac.uk
Glen Herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>
>>>The maximum record length and block length are 32767. With a block
>>>in the buffer it is pretty easy to go through the counts and find
>>>a specific record.
>
>> Though VBS allowed spanning, where a record could be continued into
>> a later block, and so was effectively unlimited in size.
>
>I think that the RDW and BDW includes bits for that, but I thought
>that LRECL was still limited to 32767. VBS allows for LRECL
>greater than BLKSIZE, which was important when disk tracks
>weren't that big.
Not DCB=(RECFM=VBS,LRECL=X)!
>This is important for Fortran (which I believe is what VBS was
>created for), in that it determines the maximum record length
>for an unformatted data set. I know I never wrote one larger
>than that.
I did, often. Our default VBS format was LRECL=X.
Regards,
Nick Maclaren.
nm...@cam.ac.uk
Glen Herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>
>>>I presume Fortran G would run on a PCP system with enough memory.
>
>> Yes, but would the library?
>
>I think so. What part do you think might not work.
God alone knows! It's too long ago now. It might have worked.
Regards,
Nick Maclaren.
robin
news:1ivsgo3.1be058vqydr5sN%nos...@see.signature...
> I'll just repeat and summarize a point mentioned by others in the
> thread. Prior to f2003, there is no portable way to deal with files hat
> are arbitrary byte streams defined by non-Fortran means.
That isn't correct. I've been using Fortran to read and write
picture files for 15 years now, various compilers. And the method
uses standard constructs.
> Most pre-f2003
> compilers have some extension for the purpose. It has been quite a while
> since I've run into an exception. There are early f77 compilers that
> can't do it, but I can't off-hand name one. I think I recall Lahey ELF90
> as being an exception of sorts,
ELF90 was/is not an exception.
robin
news:504e25e8-4d59-42fd...@33g2000yqm.googlegroups.com...
> Someone who read my above reaction has been so kind as to point out
> that Fortran is well capable of doing .bmp-files all by itself. He
> even sent me some code showing how to do it. It works with g95 and
> gfortran, but not with Portland pgf90... The single statement that is
> rejected by Portland is:
>
> OPEN(ScratchFile,FILE=FName,ACCESS='transparent', STATUS='replace')
>
> It seems that ACCESS='transparent' is not supported.
> I tried FORM='UNFORMATTED', since I saw no other specifyer in the
> above call for opening the file as unformatted/binary, but that didn't
> work.
>
access='direct'
robin
news:1bb0f039-9200-4861...@r10g2000prf.googlegroups.com...
ACCESS = 'DIRECT'
robin
news:91737cf6-1716-449c...@d19g2000prh.googlegroups.com...
> This come up a lot.
> The three most common methods of giveing parameters in the OPEN
> statement for using stream data are:-
>
> FORM='UNFORMATTED',ACCESS='TRANSPARENT', (Lahey, Fujitsiu)
>
> FORM='BINARY',ACCESS='SEQUENTIAL', (MS, IBM, CVF.DVF,Intel, many
> onthers .
>
> When these don't work and nothing else does, than use:-
> FORM='UNFORMATTED' ACCESS='DIRECT',RECL=256 or similar, and read and
> write blocks and put in or extract bytes at will into/from the buffer
> you are using.
With picture files (and with any arbitrary file), the last record is
a problem, in which case RECL=1 is preferred.
robin
> Craig Powers <craig....@invalid.invalid> wrote:
>
> > Incidentally, looking through the PGF documentation available on my
> > system (for version 7.0-6), I don't see anything that indicates support
> > for stream access, so PGF may not support this common extension to F9x.
>
> If the compiler doesn't support stream directly, about the next best
> thing is direct access unformatted. That can run into problems with the
> last part of a file if it has a "partial record",
Not when the record length is 1.
robin
> > I think those two (access transparent, or access
> > direct, form binary) are the most common non-standard spellings.
>
> ACCESS = 'DIRECT' asks for a record length. Setting it to e.g. 1 does
> not work.
Yes it does.
nm...@cam.ac.uk
robin <rob...@bigpond.com> wrote:
>"Richard Maine" <nos...@see.signature> wrote in message
>news:1ivsgo3.1be058vqydr5sN%nos...@see.signature...
>
>> I'll just repeat and summarize a point mentioned by others in the
>> thread. Prior to f2003, there is no portable way to deal with files hat
>> are arbitrary byte streams defined by non-Fortran means.
>
>That isn't correct. I've been using Fortran to read and write
>picture files for 15 years now, various compilers. And the method
>uses standard constructs.
You have confused "using standard constructs" with "conforming to the
standard". You will have used only systems derived from Unix, where
the trick of using RECL=1 and ACCESS='DIRECT' will usually 'work'.
But, as Richard said, it is not specified by the standard - and many
of us know of systems where it will not work.
Regards,
Nick Maclaren.
Gary Scott
unit", by default.
Arjan
Good to see this discussion is still alive! And not for nothing!
I read and re-read all the above stuff and finally got the bmp-file
writing running even without ACCESS='TRANSPARENT', but with
ACCESS='DIRECT', RECL=1. This means that there is 1 reason less to buy
a new compiler.
Sorry to the OP that my contribution to this discussion has been
focussed on writing bmp-files, whereas the question was about
reading...
I am very satisfied with the outcome of this discussion, but I still
have a question or two to satisfy my curiosity. With
ACCESS='TRANSPARENT' I did just this:
OPEN(ScratchFile,FILE=FName,ACCESS='transparent', STATUS='replace')
WRITE(ScratchFile) bmp_Header
WRITE(ScratchFile) bmp_Data
CLOSE(ScratchFile)
Now the latter write-statement is replaced by:
Count = BMPHeader_length
DO k = 1,Image_Height
DO j = 1,Columns
DO i=1,3 ! RGB
Count = Count + 1
WRITE(ScratchFile,REC=Count) bmp_Data(i,j,k)
ENDDO
ENDDO
ENDDO
I was just wondering if the writing of the data block can be done in a
shorter statement. The REC= specified prevents the construction of a 1-
statement loop like: WRITE(kh,,,) (((Bmp_Data
(i,j,k),i=1,3),j=1,Columns,k=1,Image_Height
I opened the file with RECL=1, so I just as well could have opened it
with FORM='FORMATTED'. This would maybe have opened the way for a
smart FORMAT statement!
Suggestions?
Furthermore, the header block was even more a pain. It's just 54
bytes, but to get the several integer*2 and integer*4 into a
CHARACTER*54 (which I then could write per byte to the file) required
silly conversion functions involving the EQUIVALENCE statement.
Compiler g95 even warns me that now I am going berserk. But, it's just
a warning, and it works... Is there a more friendly way to write a
collection of integer*2, integer*4 and a 2-character string to the
file in direct access-mode with recl=1?
I probably just got what I deserved/asked for when I suggested to
remove ACCESS='TRANSPARENT', but maybe I have overlooked an obvious
way out.
Regards,
Arjan
Terence
Oh dear, Oh Dear!
I thought I wrote in English. (Even if my editor doubles up or omits
the odd keystroke)
What has what the O/S and what the microcode actually do, with
anything that Fortran does or the Fortran programmer is interested in?
Fortran just communicates with the O/S and asks to read, or write a
(talking about tape) file in a predetermined mode. Fortran has no idea
about VBS or MVS and so on. The various access methods provided in the
O/S achieved their desired actions using (in the end) machine
language.
But if you take your Fortran-written tape off a mainframe tape drive
unit and go to a desktop PC with a tape reader (yes, I had one), you
can find what is actually written on the tape.
And I'm sure there are sets of standards about writing tapes, starting
from the past.
Initially (at least with IBM) you have a tape header record (which
names the tape and provides a date and the ID number of the tape and
usenumber and so on) and a tape marker, followed by the file or files
you wrote. Some tape drives CAN read backwards but almost NEVER do to
get data, but backspacing needs the tape drive to read data off the
tape, backwards, to know when it has finished passing the previous
record to find the "inter record gap" between records, stops on the
even-earlier record, or the tape hearder tape marker, and advances
again to position itself before the inter recored gap. This is done by
microcode instructions, not programmed in Fortran, nor even the
operating system as such, but part of the O/S as are say, the machine
instructions underlying the Kernel functions are in Windows.
But what is written DOES depend on the mode Fortran requested the file
to be wriiten in.
If it was sequential formatted data you will get mostly ascii data
bytes, but possible pure binary words written with A2 format which
could be any combination of bits and eventually a line teminator group
(e.g. cr-lf). If you wrote in an unformatted mode you would not have
the line terminator group unless you actually wrote it was part of
your data (which I do a lot).
But IBM wrote data from Fortran programs in the unformated modes with
a byte count prefix and postfix. Probably a very early design decision
that stayed around in the impletmentations. It doesn't have to be
there and isn't on disks files. When I found about about this I asked
"why"
and The answer I got was it was instrumental in being able to read
those kinds of files backwards". True or not, I don't know.. But I
know IBM DID used the reading of file backwards in operations of fast,
uninterrupted file searching (the data was stored backwards, BY
KNOWING THE LENGTH OF THE RECORD FROM THE POSTFIX COUNT). That
explained it to me. And from then on I didn't want extra data in my
files in case I wanted to process them another way and so never used
the sequential unformatted mode!.
Luu Quang Hung
Did you mean employing the code open
(10,file='filename.txt',form='binary').
As far as I compile with my CVF, its does not work.
Anyway, I appreciate your help. Thank you Gary!
> -- Henry Ford- Ẩn nội dung trích dẫn -
>
> - Hiển thị văn bản được để trong dấu trích dẫn -
Luu Quang Hung
As I mail you, I got the Hayashi code to WRITE the BMP-file with very
simple commmand
open(unit=2,file=fnameout,status='unknown')
The sucessful code is given as below.
Hoever, I could not using the same declaration to READ the BMP-file.
It seems to be a harder job. I do not know why.
* --------------------------------------------
* Sample FORTRAN 77 program to make PPM / BMP
*
* 1998-Apr-03 (long long ago)
* :
* 2005-Jul-22 (added P3)
* :
* 2006 Dec-22 (added BMP)
*
* Image array rgb(3,*,*) is filled in subroutine mkbitmap()
* and
* saved in PPM or BMP format in subroutine pixout().
*
* K. Hayashi
* --------------------------------------------
*
program pixelout
implicit none
integer ihpixf, jvpixf
parameter(ihpixf = 128, jvpixf = 128) ! pixel size
character*1 rgb(3,ihpixf,jvpixf) ! RGB image array
integer nframe, nf2
do nframe = 1, 50
nf2 = nframe
call mkbitmap(rgb,nf2)
call pixout(rgb,nf2)
enddo
stop
end program pixelout
* --------------------------------------------
*
* Notes
* o With a parameter ipixout set at 1, 2 or others,
* this subroutine will generate PPM-P6(binary), PPM-P3(text),
* or BMP(24bit depth without color table).
*
* o Some parts follow DEC-FORTRAN that had been defacto-standard long
ago.
* Some compilers today may not accept if "ipixout" is not 2.
*
* o g77 (ver. 3.3.3) works for all three choices.
* o Recent intel compiler (ver. 9 or so) works for all three choices.
*
* --------------------------------------------
*
subroutine pixout(rgb,nframe)
implicit none
* interface arg.
integer ihpixf, jvpixf
parameter(ihpixf = 128, jvpixf = 128) ! pixel size, must be
multiple of 4 for BMP
character*1 rgb(3,ihpixf,jvpixf) ! RGB data array
integer nframe
* local
character*12 fnameout
integer i, j, k
integer itmp, icnt
character*14 frmtstr
character*54 headmsw
character*4 byt4
character*2 byt2
* choices
integer ipixout
parameter(ipixout = 3) ! 1 / 2 / other= PPM6, PPM3, BMP(24bit)
if (ipixout .EQ. 1) then
* PPM P6
write(fnameout,'(''smpl'',i3.3,''.ppm'')') nframe ! name of
PPM file
open(unit=2,file=fnameout,status='unknown')
write(*,*) 'Now writing PPM (P6) file : ', fnameout
* header
write(2,'(''P6'', 2(1x,i4),'' 255 '',$)') ! some
compiler may not accept this line.
& ihpixf, jvpixf
* image data
itmp = ihpixf * jvpixf * 3
write(frmtstr,'(''('',i8.8,''A,$)'')') itmp ! make output
"format"
write(2,fmt=frmtstr) ! some
compiler may not accept this line.
& (((rgb(k,i,j),k=1,3),i=1,ihpixf),j=jvpixf,1,-1) ! here, j
(vertical address) runs from top to bottom.
close(2)
else if (ipixout .EQ. 2) then
* PPM P3 ! rather "safer" choice for many Fortran compiler(s).
write(fnameout,'(''smpl'',i3.3,''.ppm'')') nframe ! name of
PPM file
open(unit=2,file=fnameout,status='unknown')
write(*,*) 'Now writing PPM (P3) file : ', fnameout
* header
write(2,'(A)') 'P3'
write(2,'(2(1x,i4),'' 255 '')') ihpixf, jvpixf
icnt = 0
* image data
do j = jvpixf, 1, -1 ! here, j
(vertical address) runs from top to bottom.
do i = 1, ihpixf, 1
do k = 1, 3
itmp = ichar(rgb(k,i,j))
icnt = icnt + 4
if (icnt .LT. 60) then
write(2,fmt='(1x,i3,$)') itmp ! mind "$" is
not standard.
else
write(2,fmt='(1x,i3)') itmp
icnt = 0
endif
enddo
enddo
enddo
write(2,'(A)') ' '
close(2)
else
* BMP (24bit depth)... this part works only when width is multiple of
4.
itmp = mod(ihpixf, 4)
if (itmp .NE. 0) then
write(*,*) 'width must be multiple of 4'
stop
endif
write(fnameout,'(''smpl'',i3.3,''.bmp'')') nframe ! name of
BMP file
open(unit=2,file=fnameout,status='unknown')
write(*,*) 'Now writing BMP(24bit) file : ', fnameout
* header 1 (file header ; 1--14 byte)
headmsw( 1: 2) = 'BM' ! declaring this is BMP
file
itmp = 54 + ihpixf * jvpixf * 3 ! total file size = header +
data
call num2bit4(itmp,byt4)
headmsw( 3: 6) = byt4(1:4)
itmp = 0 ! may be 0
call num2bit2(itmp,byt2)
headmsw( 7: 8) = byt2(1:2)
itmp = 0 ! may be 0
call num2bit2(itmp,byt2)
headmsw( 9:10) = byt2(1:2)
itmp = 54 ! must be 54 : total length
of header
call num2bit4(itmp,byt4)
headmsw(11:14) = byt4(1:4)
* header 2 (bit-map header ; 13--54 byte)
itmp = 40 ! must be 40 : length of bit-
map header
call num2bit4(itmp,byt4)
headmsw(15:18) = byt4(1:4)
itmp = ihpixf ! width
call num2bit4(itmp,byt4)
headmsw(19:22) = byt4(1:4)
itmp = jvpixf ! height
call num2bit4(itmp,byt4)
headmsw(23:26) = byt4(1:4)
itmp = 1 ! must be 1
call num2bit2(itmp,byt2)
headmsw(27:28) = byt2(1:2)
itmp = 24 ! must be 24 : color depth in
bit.
call num2bit2(itmp,byt2)
headmsw(29:30) = byt2(1:2)
itmp = 0 ! may be 0 : compression
method index
call num2bit4(itmp,byt4)
headmsw(31:34) = byt4(1:4)
itmp = 0 ! may be 0 : file size if
compressed
call num2bit4(itmp,byt4)
headmsw(35:38) = byt4(1:4)
itmp = 0 ! arbit. : pixel per meter,
horizontal
call num2bit4(itmp,byt4)
headmsw(39:42) = byt4(1:4)
itmp = 0 ! arbit. : pixel per meter,
vertical
call num2bit4(itmp,byt4)
headmsw(43:46) = byt4(1:4)
itmp = 0 ! may be 0 here : num. of
color used
call num2bit4(itmp,byt4)
headmsw(47:50) = byt4(1:4)
itmp = 0 ! may be 0 here : num. of
important color
call num2bit4(itmp,byt4)
headmsw(51:54) = byt4(1:4)
* writing header part
write(2,'(a54,$)') headmsw(1:54)
* image data
itmp = ihpixf * jvpixf * 3
write(frmtstr,'(''('',i8.8,''A,$)'')') itmp
write(2,fmt=frmtstr)
& (((rgb(k,i,j),k=3,1,-1),i=1,ihpixf),j=1,jvpixf) ! writing
in BGR order, not RGB.
close(2)
endif
return
end subroutine pixout
* --------------------------------------
* convert number to 8-bit characters
* --------------------------------------
subroutine num2bit4(inum,byt4)
implicit none
integer inum
character*4 byt4
integer itmp1, itmp2
itmp1 = inum
itmp2 = itmp1 / 256**3
byt4(4:4) = char(itmp2)
itmp1 =-itmp2 * 256**3 +itmp1
itmp2 = itmp1 / 256**2
byt4(3:3) = char(itmp2)
itmp1 =-itmp2 * 256**2 +itmp1
itmp2 = itmp1 / 256
byt4(2:2) = char(itmp2)
itmp1 =-itmp2 * 256 +itmp1
byt4(1:1) = char(itmp1)
return
end subroutine num2bit4
* ------
subroutine num2bit2(inum,byt2)
implicit none
integer inum
character*2 byt2
integer itmp1, itmp2
itmp1 = inum
itmp2 = itmp1 / 256
byt2(2:2) = char(itmp2)
itmp1 =-itmp2 * 256 + itmp1
byt2(1:1) = char(itmp1)
return
end subroutine num2bit2
* --------------------------------------------
* fill rgb data array with something
* --------------------------------------------
subroutine mkbitmap(rgb,nframe)
implicit none
integer nframe
integer ihpixf, jvpixf
parameter(ihpixf = 128, jvpixf = 128) ! pixel size
character*1 rgb(3,ihpixf,jvpixf) ! RGB pixel data array
* local
real*8 red, gre, blu
integer ired, igre, iblu
real*8 ofst
parameter(ofst = 0.7D+00)
integer i, j, itmp
real*8 aa, bb, cc, rr, xx, yy, tt
integer ichoice
parameter(ichoice = 1) ! .... choice
real*8 pi
parameter(pi = 3.14159265358979D+00)
if (ichoice .EQ. 0) then
do 100 j = 1, jvpixf
do 100 i = 1, ihpixf
itmp = i*3*nframe + j*2
itmp = mod(itmp,256) ! assuming color depth ranges 0--255
rgb(1,i,j) = char(itmp) ! red
itmp = i*1*nframe + j*3
itmp = mod(itmp,256)
rgb(2,i,j) = char(itmp) ! green
itmp = i*5*nframe + j*7
itmp = mod(itmp,256)
rgb(3,i,j) = char(itmp) ! blue
100 continue
else
do 101 j = 1, jvpixf
do 101 i = 1, ihpixf
* red-ball
tt = dfloat(nframe) / 25.0D+00 ! time/
period
xx = dfloat(i) / dfloat(ihpixf) - 0.33D+00 ! center x
yy = dfloat(j) / dfloat(jvpixf) - 0.25D+00 ! center y
rr = dsqrt(xx**2 + yy**2 + 1.0D-30)
aa = rr / 0.25D+00 ! half-
width
bb =(tt - rr) * pi
cc = dexp(-aa**2) * (dcos(bb))**2
if (cc .LT. ofst) then
red = cc / ofst
gre = 0.0D+00
blu = 0.0D+00
else
red = 1.0D+00
gre =(cc - ofst) / (1.0D+00 - ofst)
blu =(cc - ofst) / (1.0D+00 - ofst)
endif
* green-ball
tt = dfloat(nframe) / 50.0D+00
xx = dfloat(i) / dfloat(ihpixf) - 0.40D+00
yy = dfloat(j) / dfloat(jvpixf) - 0.65D+00
rr = dsqrt(xx**2 + yy**2 + 1.0D-30)
aa = rr / 0.40D+00
bb =(tt - rr) * pi
cc = dexp(-aa**2) * (dcos(bb))**2
if (cc .LT. ofst) then ! here and hereafter, additive rgb
color is simply added.
gre = gre + cc / ofst
else
red = red +(cc - ofst) / (1.0D+00 - ofst)
gre = gre + 1.0D+00
blu = blu +(cc - ofst) / (1.0D+00 - ofst)
endif
* blue-ball
tt = dfloat(nframe) / 12.5D+00
xx = dfloat(i) / dfloat(ihpixf) - 0.75D+00
yy = dfloat(j) / dfloat(jvpixf) - 0.70D+00
rr = dsqrt(xx**2 + yy**2 + 1.0D-30)
aa = rr / 0.30D+00
bb =(tt - rr) * pi
cc = dexp(-aa**2) * (dcos(bb))**2
if (cc .LT. ofst) then
blu = blu + cc / ofst
else
red = red +(cc - ofst) / (1.0D+00 - ofst)
gre = gre +(cc - ofst) / (1.0D+00 - ofst)
blu = blu + 1.0D+00
endif
* yellow-ball
tt = dfloat(nframe) / 16.66666666666D+00
xx = dfloat(i) / dfloat(ihpixf) - 0.75D+00
yy = dfloat(j) / dfloat(jvpixf) - 0.30D+00
rr = dsqrt(xx**2 + yy**2 + 1.0D-30)
aa = rr / 0.25D+00
bb =(tt - rr) * pi
cc = dexp(-aa**2) * (dcos(bb))**2
if (cc .LT. ofst) then
red = red + cc / ofst
gre = gre + cc / ofst
else
red = red + 1.0D+00
gre = gre + 1.0D+00
blu = blu +(cc - ofst) / (1.0D+00 - ofst)
endif
ired = int(red * 255.0D+00)
igre = int(gre * 255.0D+00)
iblu = int(blu * 255.0D+00)
if (ired .GT. 255) ired = 255
if (igre .GT. 255) igre = 255
if (iblu .GT. 255) iblu = 255
if (ired .LT. 0) ired = 0
if (igre .LT. 0) igre = 0
if (iblu .LT. 0) iblu = 0
rgb(1,i,j) = char(ired)
rgb(2,i,j) = char(igre)
rgb(3,i,j) = char(iblu)
101 continue
endif
return
end subroutine mkbitmap
* --------------------------------------------
* end of this file, thank you.
* --------------------------------------------
Gary Scott
> Dear Gary,
>
> Did you mean employing the code open
> (10,file='filename.txt',form='binary').
>
> As far as I compile with my CVF, its does not work.
What did not work? It works ok with my CVF 6.6c
Luu Quang Hung
I also use CVF 6.6c. Of course we could compile it since CVF support
form='binary', but when I conduct it with the real example
EXAMPLE.BMP, it reports error.
If you have any working example to READ BMP file (code+example.bmp),
please send me. I am sorry if there is any misunderstanding around.
Luu Quang Hung
Richard Maine
> I also use CVF 6.6c. Of course we could compile it since CVF support
> form='binary', but when I conduct it with the real example
> EXAMPLE.BMP, it reports error.
I suspect a severe lack of context here. You can't just talk about
single statements out of context. And you need to say exactly what the
error in question is and when you get it.
For example, I note that the write statements in the OP's code are
formatted writes. That probably doesn't go with form='binary'. (I say
probably because form='binary' isn't standard, so maybe strange things
would work, but it doesn't logically go with formatted writes.)
If that's the case, then the problem is in that combination - not in
either one alone. One could presumably do it either way as long as one
was consistent. In fact, the formatted one is the most questionable
case. One can write anything with unformatted stream (which is basically
what form='binary' amounts to). One is more limitted with formatted I/O.
But I'm just making a wild guess. The description "reports error" is
inadequate for any actual diagnosis.
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
Luu Quang Hung
Thank you for your nice comment.
As recommended by many people who join in this talk, the problem due
to the format of OPEN command in Fortran. Thus, since I have the full
code written in the first post in the topic, I just try to modify the
OPEN command in my program.
Gary did propose a OPEN command in his previous mail, so I do not
repeat it fully.
The error of the program compiled in CVF is:
1. Original code ( OPEN
(UNIT=1,FILE=FIN,FORM='UNFORMATTED',ACCESS='TRANSPARENT') ):
Error: "Severe (24). End-of-file during read, unit 1, file
rokmask.bmp"
Detail: http://luuquanghung.googlepages.com/bittockerror1.jpg
2. Code corrected by Gary ( OPEN(UNIT=1,FILE=FIN,FORM='BINARY') ):
Error: "Severe (257). Formatted I/O to unit open for unformatted
transfer, Unit 1, file rokmask.bmp"
Detail: http://luuquanghung.googlepages.com/bittockerror2.jpg
3. Code corrected by Terence ( OPEN
(UNIT=1,FILE=FIN,FORM='BINARY',ACCESS='SEQUENTIAL') ):
Error: "Severe (257). Formatted I/O to unit open for unformatted
transfers, Unit 1, file rokmask.bmp"
Detail: http://luuquanghung.googlepages.com/bittockerror3.jpg
4. Code corrected by Terence ( OPEN
(UNIT=1,FILE=FIN,FORM='UNFORMATTED',ACCESS='TRANSPARENT') ):
Error: "Bittock.f90(25) : Error: Not a valid value for the char-expr
in this connect-spec. ['TRANSPARENT']
open
(unit=1,file=fin,FORM='UNFORMATTED',ACCESS='TRANSPARENT')"
Detail: http://luuquanghung.googlepages.com/bittockerror4.jpg
That is all the cases I have tested with the given code attached in
the first post.
Best regards,
Luu Quang Hung
On 2 Tháng Ba, 13:45, nos...@see.signature (Richard Maine) wrote:
James Van Buskirk
news:24545ddc-910a-4687...@k36g2000pri.googlegroups.com...
> I also use CVF 6.6c. Of course we could compile it since CVF support
> form='binary', but when I conduct it with the real example
> EXAMPLE.BMP, it reports error.
> If you have any working example to READ BMP file (code+example.bmp),
> please send me. I am sorry if there is any misunderstanding around.
Well, if you got CVF to open a stream file, you're pretty much in
like Flint. Except there several possible formats for the bitmap
data which you find out from reading the header. There is also more
than one header format.
You can find this stuff out in a Windows programming book such as
those by Charles Petzold. In fact, if you look in such a tome you
will see how you can ask the OS to load the bitmap for you, so you
don't have to decode the file, just invoke the Win32 API, which CVF
is pretty good at.
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
Luu Quang Hung
1. Original code ( OPEN
(UNIT=1,FILE=FIN,FORM='UNFORMATTED',ACCESS='TRANSPARENT') ):
It should be reads as:
1. Original code ( OPEN (UNIT=1,FILE=FIN) ):
James Van Buskirk
news:ba94fe42-38c9-404b...@y33g2000prg.googlegroups.com...
> 2. Code corrected by Gary ( OPEN(UNIT=1,FILE=FIN,FORM='BINARY') ):
> Error: "Severe (257). Formatted I/O to unit open for unformatted
> transfer, Unit 1, file rokmask.bmp"
> Detail: http://luuquanghung.googlepages.com/bittockerror2.jpg
The error message means just what it says: you are attempting
formatted I/O to a unit opened for unformatted transfer. You have
to open this kind of file for unformatted transfer so you have to
learn you to do unformatted transfer. I have an example at:
http://home.comcast.net/~kmbtib/Fortran_stuff/fire2.f90
that writes a *.BMP file opened as above. Maybe taking a look at
that example will give you an idea of how you are supposed to read
one. The important thing is that a data transfer statement to or
from a file opened for unformatted transfer doesn't have a
FMT= clause in it. After all, what should the compiler do with
a format if it isn't supposed to do formatted transfer?
Richard Maine
> Dear Richard,
>
> Thank you for your nice comment.
>
> As recommended by many people who join in this talk, the problem due
> to the format of OPEN command in Fortran. Thus, since I have the full
> code written in the first post in the topic, I just try to modify the
> OPEN command in my program.
No, the problem is not from just the OPEN. As I said in my post,
statements do not stand alone. That is certainly true of I/O statements.
The OPEN statement is closely tied to the READ statements. They must be
consistent. You cannot diagnose I/O problems by separately looking at
the OPEN and READ statements as though they had nothing to do with each
other.
> Error: "Severe (257). Formatted I/O to unit open for unformatted
> transfer, Unit 1, file rokmask.bmp"
Yes, exactly the problem I mentioned. This is about the READ statement
being formatted, while the OPEN was for unformatted.
nm...@cam.ac.uk
Terence <tbwr...@cantv.net> wrote:
>Glen Herrmannsfeldt wrote:
>
> . . .
>
>Oh dear, Oh Dear!
>I thought I wrote in English. (Even if my editor doubles up or omits
>the odd keystroke)
You did. But that does not mean that what you wrote was sense. Glen
is familiar with those systems, and I have worked within IBM in the
Fortran library area - yes, at the programming level. Indeed, when
I was last there, I was explaining to them the VS Fortran people the
reasons for some of the weirder code in the old MOD II library.
I can't be bothered to continue, so shall just point out that your
diatribe is about equal parts factual, confused and total nonsense.
I believe that the code of the library used for Fortran G and H is
now online, so Isuggest that you look at it and correct your own
misapprehensions.
Regards,
Nick Maclaren.
Glen Herrmannsfeldt
(snip)
> You did. But that does not mean that what you wrote was sense. Glen
> is familiar with those systems, and I have worked within IBM in the
> Fortran library area - yes, at the programming level. Indeed, when
> I was last there, I was explaining to them the VS Fortran people the
> reasons for some of the weirder code in the old MOD II library.
I believe the MOD II library is the one I call the H extended library,
and also one that isn't freely available. It is backwards compatible,
though.
> I can't be bothered to continue, so shall just point out that your
> diatribe is about equal parts factual, confused and total nonsense.
> I believe that the code of the library used for Fortran G and H is
> now online, so Isuggest that you look at it and correct your own
> misapprehensions.
Yes it is now online. I had it available about 35 years ago, and
was some of the sample code I had when learning S/360 assembler.
I remember some stories about the numerical work in the MOD II
library, especially the REAL*16 routines.
Otherwise, the older library has some interesting code, too.
Some is self modifying, such as different entry points for trig
routines modifying later instructions to generate the appropriate
result.
-- glen
nm...@cam.ac.uk
Glen Herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>
>> You did. But that does not mean that what you wrote was sense. Glen
>> is familiar with those systems, and I have worked within IBM in the
>> Fortran library area - yes, at the programming level. Indeed, when
>> I was last there, I was explaining to them the VS Fortran people the
>> reasons for some of the weirder code in the old MOD II library.
>
>I believe the MOD II library is the one I call the H extended library,
>and also one that isn't freely available. It is backwards compatible,
>though.
Yes. We dropped use of the free library very early. Inter alia, the
MOD II library was needed for list-directed I/O.
>> I can't be bothered to continue, so shall just point out that your
>> diatribe is about equal parts factual, confused and total nonsense.
>> I believe that the code of the library used for Fortran G and H is
>> now online, so Isuggest that you look at it and correct your own
>> misapprehensions.
>
>Yes it is now online. I had it available about 35 years ago, and
>was some of the sample code I had when learning S/360 assembler.
>I remember some stories about the numerical work in the MOD II
>library, especially the REAL*16 routines.
Oh, God! That brings it back! Yes, I could give you some horror
stories, from first-hand experience. I told IBM how they could
speed up Fortran REAL*16 division by a factor of 4 without changing
functionality (and by a bit more by reducing the precision to 1 ULP),
but never succeeded in persuading them.
>Otherwise, the older library has some interesting code, too.
>Some is self modifying, such as different entry points for trig
>routines modifying later instructions to generate the appropriate
>result.
There was actually very little difference between the two, and the
Mod II library was really the older one with brass knobs on (and
a few fixes).
Regards,
Nick Maclaren.
Arjan
> please send me.
I just sent you a working example.
Arjan
Jugoslav Dujic
> I agree with you Arjan,
>
> As I mail you, I got the Hayashi code to WRITE the BMP-file with very
> simple commmand
>
> open(unit=2,file=fnameout,status='unknown')
>
> The sucessful code is given as below.
>
> Hoever, I could not using the same declaration to READ the BMP-file.
> It seems to be a harder job. I do not know why.
>
> * convert number to 8-bit characters
> * --------------------------------------
>
> subroutine num2bit4(inum,byt4)
> * --------------------------------------------
> * end of this file, thank you.
> * --------------------------------------------
Because this code is an abomination. This is a hack whereby
the formatted, meant-to-be text file is actually written with
pairs and quartets of characters/bytes, which carry the bit-by-bit
interpretation of numbers. In effect, a binary file in correct
format is obtained. (num2bit4 and others do the same thing as
the TRANSFER intrinsic).
I would understand if something like that were coded in
1980s, but doing it in 1998, as the comment says, is a very
contrived way to do things.
--
Jugoslav
www.xeffort.com
Please reply to the newsgroup.
You can find my real e-mail on my home page above.
Jan Vorbrüggen
>> expects record markers.
>
> Odd. I don't recall the details, but is BMP really a text file format?
Nope.
> That would seem surprising. In particular, I wonder what the nature of
> the record markers is.
Sorry about the miscommunication. What I meant was that, with
UNFORMATTED being the standardized way to open a file for unformatted
record-orientied I/O - which requires some form of record makers or
lengths to work -, it can't be the way to open and read or write a file
that does not have a record structure. That's why DEC et seq. Fortran
compilers chose the non-standard FORM="BINARY" to indicate this kind of
processing.
Incidentally, I'm quite aware of the distinctions between unformatted
and formatted Fortran I/O...
Jan
Gary Scott
> Dear Gary,
>
> I also use CVF 6.6c. Of course we could compile it since CVF support
> form='binary', but when I conduct it with the real example
> EXAMPLE.BMP, it reports error.
>
> If you have any working example to READ BMP file (code+example.bmp),
> please send me. I am sorry if there is any misunderstanding around.
The following is just to provide hints of a common method of interfacing
with BMP format files. I'm not sure what state this is in, I believe
only partially finished. Finished version is at work and not available.
module BMP
type BitMapFileHeader
sequence
character(2) :: bfType !"BM" file format ID
integer(4) :: bfSize !File size in bytes
integer(2) :: bfReserved1 !Unused
integer(2) :: bfReserved2 !Unused
integer(4) :: bfOffBits !Offset to start of pixel data
end type
type BitMapInfoHeader
sequence
integer(4) :: biSize !Header size - must be at least
40 bytes
integer(4) :: biWidth !Image width in pixels
integer(4) :: biHeight !Image depth in pixels
integer(2) :: biPlanes !Number planes - must be 1
integer(2) :: biBitCount !BPP - 1, 4, 8, 16, 24, 32
integer(4) :: biCompression !Compression type -
0=RGB,1=RLE8,2=RLE4,3=BITFIELDS
integer(4) :: biSizeImage !Image Size - May be zero if not
compressed
integer(4) :: biXPelsPerMeter !Preferred resolution in pixels
per meter
integer(4) :: biYPelsPerMeter !Preffered resolution in pixels
per meter
integer(4) :: biClrUsed !Number of entries in the color
map that are actually used
integer(4) :: biClrImportant !Number of significant colors
end type
type BitMapCoreHeader
sequence
integer(4) :: bcSize !Header size - must be 12 bytes
integer(2) :: bcWidth !Image width
integer(2) :: bcHeight !Image height
integer(2) :: bcPlanes !Number of planes - must be 1
integer(2) :: bcBitCount !BPP - 1, 4, 8, 24
end type
type BitMapRGBQuadPallet
sequence
integer(1) :: rgbtBlue !Blue component
integer(1) :: rgbtGreen !Green component
integer(1) :: rgbtRed !Red component
integer(1) :: rgbtReserved !Reserved component
end type
type BitMapPixelData148
integer(1) :: PalletIndex
end type
type BitMapPixelData16
integer(2) :: RGB
end type
type BitMapPixelData24
sequence
integer(1) :: Blue
integer(1) :: Green
integer(1) :: Red
end type
type BitMapPixelData32
sequence
integer(1) :: Blue
integer(1) :: Green
integer(1) :: Red
integer(1) :: Reserved
end type
end module
module Globals
use BMP
type(BitMapFileHeader) FileHeader
type(BitMapInfoHeader) InfoHeader !Windows Format
type(BitMapCoreHeader) CoreHeader !OS/2 format
type(BitMapRGBQuadPallet), allocatable :: RGBQuadPallet(:)
type(BitMapPixelData24), allocatable :: PixelData(:)
end module
Program BMP2Plane
use Globals
integer :: ios
integer :: xbytes
integer(1), allocatable :: Inbuf(:), Outbuf(:)
open(10,file='gary.bmp',iostat=ios,status='old',form='binary')
if (ios .ne. 0) stop
open(20,file='output.txt')
open(31,file='blue.dat',form='binary')
open(32,file='green.dat',form='binary')
open(33,file='red.dat',form='binary')
read(10)FileHeader, InfoHeader
if (InfoHeader.biBitCount .ne. 24) stop "Unsupported BMP Format (not
24BPP)"
if (InfoHeader.biPlanes .ne. 1) stop "Unsupported BMP Format (not
single plane)"
if (InfoHeader.biCompression .ne. 0) stop "Unsupported BMP Format
(not uncompressed)"
xbytes = int(InfoHeader.biWidth * InfoHeader.biBitCount / 8) + 1
allocate(PixelData(xbytes))
allocate(inbuf(1:xbytes))
allocate(outbuf(1:xbytes * 2))
do
read(10,iostat=ios)PixelData
if (ios .ne. 0) exit
! call BMPRLE8(PixelData.Blue,Outbuf,length) !RLE Encode Blue
write(31)PixelData.Blue
! call BMPRLE8(PixelData.Green,OutBuf,Length) !RLE Encode Green
write(32)PixelData.Green
! call BMPRLE8(PixelData.Red,OutBuf,Length) !RLE Encode Red
write(33)PixelData.Red
end do
call BMPLog(20)
stop
contains
subroutine BMPLog(lfn)
use Globals
integer, intent(in) :: lfn
1 format(a,a)
2 format(a,i0)
write(lfn,1)'bfType=',FileHeader.bftype
write(lfn,2)'bfSize=',FileHeader.bfsize
write(lfn,2)'bfReserved1=',FileHeader.bfReserved1
write(lfn,2)'bfReserved2=',FileHeader.bfreserved2
write(lfn,2)'bfOffBits=',FileHeader.bfoffbits
write(lfn,*)
write(lfn,2)'biSize=',InfoHeader.bisize
write(lfn,2)'biWidth=',InfoHeader.biwidth
write(lfn,2)'biHeight=',InfoHeader.biheight
write(lfn,2)'biPlanes=',InfoHeader.biplanes
write(lfn,2)'biBitCount=',InfoHeader.bibitcount
write(lfn,2)'biCompression=',InfoHeader.bicompression
write(lfn,2)'biSizeImage=',InfoHeader.bisizeimage
write(lfn,2)'biXPelsPerMeter=',InfoHeader.bixpelspermeter
write(lfn,2)'biYPelsPerMeter=',InfoHeader.biypelspermeter
write(lfn,2)'biClrUsed=',InfoHeader.biclrused
write(lfn,2)'biClrImportant=',InfoHeader.biclrimportant
! write(lfn,*)
! write(lfn,2)'rgbtBlue=',rgbQuadPallet.rgbtblue
! write(lfn,2)'rgbtGreen=',rgbQuadPallet.rgbtgreen
! write(lfn,2)'rgbtRed=',rgbQuadPallet.rgbtred
! write(lfn,2)'rgbtReserved=',rgbQuadPallet.rgbtreserved
return
end subroutine
subroutine BMPRLE8(inbuffer,outbuffer,length)
integer(1), intent(inout) :: inbuffer(:)
integer(1), intent(inout) :: outbuffer(:)
integer(1) :: P1 = 16#27, P2=16#DA, P3
= 16#DB, P4 = 16#DC
integer, intent(out) :: length
integer(4) :: bufsize, incount,
outcount, i, endval
if (size(outbuffer,1) .lt. size(inbuffer,1)) stop "Output Buffer
too small"
outbuffer(1) = P1
outbuffer(2) = P2
outbuffer(3) = P3
outbuffer(4) = P4
incount = 1
outcount = 4
do
endval = incount + 255
if (endval .gt. size(inbuffer,1)) endval = size(inbuffer,1)
match = 0
do i = incount,endval
if (inbuffer(i) .eq. inbuffer(incount)) then
match = match + 1
else
exit
end if
end do
if (match .gt. 3) then
outcount = outcount + 1
outbuffer(outcount) = P1
outbuffer(outcount+1) = int1(match)
outbuffer(outcount+2) = inbuffer(incount)
length = outcount + 2
outcount = outcount + 2
incount = incount + match
else
outcount = outcount + 1
outbuffer(outcount) = inbuffer(incount)
incount = incount + 1
length = outcount
end if
if (incount .gt. size(inbuffer,1)) exit
end do
return
end subroutine
end
>
> Luu Quang Hung
>
>
>
> On 2 Tháng Ba, 12:31, Gary Scott <garylsc...@sbcglobal.net> wrote:
>
>>Luu Quang Hung wrote:
>>
>>>Dear Gary,
>>
>>>Did you mean employing the code open
>>>(10,file='filename.txt',form='binary').
>>
>>>As far as I compile with my CVF, its does not work.
>>
>>What did not work? It works ok with my CVF 6.6c
>>
>>
>>>Anyway, I appreciate your help. Thank you Gary!
>
>>
Arjan
read and write bmp-files with and without ACCESS='TRANSPARENT'.
The core part of the write-routine is:
IF (UseAccessIsTransparent) THEN
OPEN(ScratchFile,FILE=FName,ACCESS='transparent',
STATUS='replace')
WRITE(ScratchFile) bmp_Header
WRITE(ScratchFile) bmp_Data
CLOSE(ScratchFile)
ELSE
CALL Header2HeaderString(bmp_Header,HeaderString)
OPEN(ScratchFile,FILE=FName,ACCESS='DIRECT', RECL=1,
STATUS='replace')
DO i=1,BMPHeader_length
WRITE(ScratchFile,REC=i) HeaderString(i:i)
ENDDO
Count = BMPHeader_length
DO k = 1,Image_Height
DO j = 1,Columns
DO i=1,3
Count = Count + 1
WRITE(ScratchFile,REC=Count) bmp_Data(i,j,k)
ENDDO
ENDDO
ENDDO
CLOSE(ScratchFile)
ENDIF
The read-routine is fully similar, but with the actions in reversed
order.
It works on a test-dataset/bmp-file...
A.
Richard Maine
> >> UNFORMATTED won't do because the file still contains or the RTL still
> >> expects record markers.
> >
> > Odd. I don't recall the details, but is BMP really a text file format?
>
> Nope.
>
> > That would seem surprising. In particular, I wonder what the nature of
> > the record markers is.
>
> Sorry about the miscommunication. What I meant was that, with
> UNFORMATTED being the standardized way to open a file for unformatted
> record-orientied I/O - which requires some form of record makers or
> lengths to work -, it can't be the way to open and read or write a file
> that does not have a record structure. That's why DEC et seq. Fortran
> compilers chose the non-standard FORM="BINARY" to indicate this kind of
> processing.
You are talking about unformatted sequential - not unformatted in
general. Note that "unformatted" does not imply sequential. There are 2
other possibilities for unformatted, none of which normally involve
record markers. Those are unformatted direct access and unformatted
stream. I'm sure you are aware of those. It is probably just a
terminology confusion in taking "unformatted" to imply "unformatted
sequential". But I think the unstated assumption does cause confusion.
It certainly confused me as to what you were talking about, and I'd be
willing to bet it also confused others.
Note that formatted sequential also requires record markers or lengths,
and for exactly the same reasons. There really is no difference in that
regard. The nature of the usual record markers for formatted and
unformatted is different on most systems (not all, but most).
Unformatted direct access is one of the possible ways to deal with files
like this. It does have potential problems, but record markers are not
among those problems.
I have long found the usage of form="binary" to contribute to
terminology confusions. I think that is part of the problem here. I
consider the so-called form="binary" to be a variant of unformatted.
That's also the way that the f2003 standard treats it. It is different
from unformatted sequential in the area of record structure, which is
more a matter of access, than in whether the data is formatted or not
(it is not formatted) or in whether the data is binary (all current
systems use binary for all data).
Kevin G. Rhoads
IIRC both Fortran-G and Fortran-H ran just fine under PCP, so long as
you had enough core. THe wimpoidal OSes were DOS and TOS and BPS,
although I think Fortran-G could be run under DOS or TOS.
Of course, it has been 4 decades with no refresh (wetware memory
is definitely DRAM) so what I remember is at least slightly suspect.
Glen Herrmannsfeldt
(snip)
> THe wimpoidal OSes were DOS and TOS and BPS,
> although I think Fortran-G could be run under DOS or TOS.
I thought it was Fortran E for DOS, but I never ran DOS.
-- glen
robin
news:gog8uj$j39$1...@s1.news.oleane.net...
> >> UNFORMATTED won't do because the file still contains or the RTL still
> >> expects record markers.
> >
> > Odd. I don't recall the details, but is BMP really a text file format?
>
> Nope.
>
> > That would seem surprising. In particular, I wonder what the nature of
> > the record markers is.
>
> Sorry about the miscommunication. What I meant was that, with
> UNFORMATTED being the standardized way to open a file for unformatted
> record-orientied I/O - which requires some form of record makers or
> lengths to work -, it can't be the way to open and read or write a file
> that does not have a record structure.
You are overlooking DIRECT with a fixed record size,
and it doesn't require record markers nor lengths
(as the record size is fixed).
robin
news:oMyql.566$im1...@nlpi061.nbdc.sbc.com...
> robin wrote:
> > "Richard Maine" <nos...@see.signature> wrote in message
> > news:1ivsldm.3ocdw4a737ngN%nos...@see.signature...
> >
> >>Craig Powers <craig....@invalid.invalid> wrote:
> >>
> >>
> >>>Incidentally, looking through the PGF documentation available on my
> >>>system (for version 7.0-6), I don't see anything that indicates support
> >>>for stream access, so PGF may not support this common extension to F9x.
> >>
> >>If the compiler doesn't support stream directly, about the next best
> >>thing is direct access unformatted. That can run into problems with the
> >>last part of a file if it has a "partial record",
> >
> >
> > Not when the record length is 1.
>
> On some systems, "1" means "1 integer sized unit" not "1 byte sized
> unit", by default.
such as?
robin
> In article <H6wql.24250$cu.1...@news-server.bigpond.net.au>,> >news:1ivsgo3.1be058vqydr5sN%nos...@see.signature...
> >
> >> I'll just repeat and summarize a point mentioned by others in the
> >> thread. Prior to f2003, there is no portable way to deal with files hat
> >> are arbitrary byte streams defined by non-Fortran means.
> >
> >That isn't correct. I've been using Fortran to read and write
> >picture files for 15 years now, various compilers. And the method
> >uses standard constructs.
>
> You have confused "using standard constructs" with "conforming to the
> standard". You will have used only systems derived from Unix,
Don't make ridiculous and false assertions.
DOS is not UNIX-based.
> where
> the trick of using RECL=1 and ACCESS='DIRECT' will usually 'work'.
> But, as Richard said, it is not specified by the standard - and many
> of us know of systems where it will not work.
Such as?
nm...@cam.ac.uk
robin <rob...@bigpond.com> wrote:
>>
>> You have confused "using standard constructs" with "conforming to the
>> standard". You will have used only systems derived from Unix,
>
>Don't make ridiculous and false assertions.
>DOS is not UNIX-based.
None of the first half-dozen DOS's I came across were, true.
MS-DOS was based on CPM, and the Windows NT kernel was derived from
the VMS design, but virtually all aspects of all versions of Microsoft
Windows outside the 'kernel' have been derived from Unix. Often by
imitation, rather than actual copying, but that's their origin.
In particular, it includes all of the filing systems and recent
I/O interfaces.
Regards,
Nick Maclaren.
GaryScott
> "Gary Scott" <garylsc...@sbcglobal.net> wrote in message
>
> news:oMyql.566$im1...@nlpi061.nbdc.sbc.com...
>
>
>
>
>
> > robin wrote:
> > > "Richard Maine" <nos...@see.signature> wrote in message
> > >news:1ivsldm.3ocdw4a737ngN%nos...@see.signature...
>
>
> > >>>Incidentally, looking through the PGF documentation available on my
> > >>>system (for version 7.0-6), I don't see anything that indicates support
> > >>>for stream access, so PGF may not support this common extension to F9x.
>
> > >>If the compiler doesn't support stream directly, about the next best
> > >>thing is direct access unformatted. That can run into problems with the
> > >>last part of a file if it has a "partial record",
>
> > > Not when the record length is 1.
>
> > On some systems, "1" means "1 integer sized unit" not "1 byte sized
> > unit", by default.
>
>
> - Show quoted text -
CVF/IVF - there are options to change it
RECL Specifier
The RECL specifier indicates the length of each record in a file
connected for direct access, or the maximum length of a record in a
file connected for sequential access.
The RECL specifier takes the following form:
RECL = rl
rl
Is a positive numeric expression indicating the length of records in
the file. If necessary, the value is converted to integer data type
before use.
If the file is connected for formatted data transfer, the value must
be expressed in bytes (characters). Otherwise, the value is expressed
in 4-byte units (longwords).
If the file is connected for unformatted data transfer, the value can
be expressed in bytes if compiler option /assume:byterecl is
specified.
Except for segmented records, the rl is the length for record data
only, it does not include space for control information.
The length specified is interpreted depending on the type of records
in the connected file, as follows:
For segmented records, RECL indicates the maximum length for any
segment (including the four bytes of control information).
For fixed-length records, RECL indicates the size of each record; it
must be specified. If the records are unformatted, the size must be
expressed as an even multiple of four.
You can use the RECL specifier in an INQUIRE statement to get the
record length before opening the file.
For variable-length records, RECL indicates the maximum length for any
record.
If you read a fixed-length file with a record length different from
the one used to create the file, indeterminate results can occur.
The maximum length for rl depends on the record type and the setting
of the CARRIAGECONTROL specifier, as shown in the following table:
Maximum Record Lengths (RECL) on Windows, Tru64 UNIX, and Linux
Systems
Record Type CARRIAGECONTROL Formatted (size in bytes)
Fixed-length 'NONE' 2147483647 (2**31-1) 1
Variable-length 'NONE' 2147483640 (2**31-8)
Segmented 'NONE' 32764 (2**15-4)
Stream 'NONE' 2147483647 (2**31-1)
Stream_CR 'LIST' 2147483647 (2**31-1)
'FORTRAN' 2147483646 (2**31-2)
Stream_LF 'LIST' 2147483647 (2**31-1) 2
'FORTRAN' 2147483646 (2**31-2)
1 Subtract 1 if the /vms compiler option is used.
2 U*X only
The default value depends on the setting of the RECORDTYPE specifier,
as shown in the following table:
Default Record Lengths (RECL) on Windows, Tru64 UNIX, and Linux
Systems
RECORDTYPE RECL value
'FIXED' None; value must be explicitly specified.
All other settings 132 bytes for formatted records; 510 longwords for
unformatted records.
Terence
> I can't be bothered to continue, so shall just point out that your
> diatribe is about equal parts factual, confused and total nonsense.
> I believe that the code of the library used for Fortran G and H is
> now online, so Isuggest that you look at it and correct your own
> misapprehensions
Nick, I have no idea what you are talking about because your time at
IBM appears to be way after mine (I left in 1964). E.g. "Fortran
library area" other than the 1620 library paper tape you had to put
through after your program to pull in needed routines. And that was
about 1960.
And where did MOD II library come from? I never mentioned it whatever
it is.
And you broguht up VBS, MVS etcetera all oparting system stuff, not
Fortran (true I mention channel command. to expalin where the
backspacing was actually done).
All this over my statement that I asked IBM why the seuqntial
unformated mode records on tape files were written with a word prefix
and postfix!!!
I never got to use Fortran IV G or H.compilers. I was using PL/1 next
time I was programming for a living, and assembler for process
control.
My experience was with FII, what was probably FIII and whatever
version it was than ran on the 704 in 1963 and whatever version was
what ran on the 1620 and 1401 similar years.
And I came back to Fortran with the HP minicomputers in 1972/73.
But I frequently got to examine and use FORTRAN IV code converted from
earlier code, right as I'm doing now. But all compilations (other than
some CVF 6.6c F90/95) have been F66 and F77.
So you think one third was true, one third we may differ about and one
third you think I got wrong. I think the above eplains why there is
confusion over the last third - we were talking different subjects and
very different years..
nm...@cam.ac.uk
Terence <tbwr...@cantv.net> wrote:
>
>Nick, I have no idea what you are talking about because your time at
>IBM appears to be way after mine (I left in 1964). E.g. "Fortran
>library area" other than the 1620 library paper tape you had to put
>through after your program to pull in needed routines. And that was
>about 1960.
I have no idea how Fortran was implemented on any of IBM's previous
systems to the System/360, but they are completely irrelevant to BMD.
That, as originally written, worked only on the System/360 (because
of the ghastly quality of its code) and, for many years, continued
to be developed on that and left to other people to port.
Glen and I were talking about the System/360 and its Fortran, which
is what is relevant to BMD. Whether or not your statements of how
things worked were true for some previous IBM system, they assuredly
weren't for the System/360 and its successors.
Regards,
Nick Maclaren.
Glen Herrmannsfeldt
(snip)
> Fortran just communicates with the O/S and asks to read, or write a
> (talking about tape) file in a predetermined mode. Fortran has no idea
> about VBS or MVS and so on. The various access methods provided in the
> O/S achieved their desired actions using (in the end) machine
> language.
Yes. But in many cases the OS supports more access methods than
are available to Fortran. Other languages might support them,
or, if not, then assembler.
> But if you take your Fortran-written tape off a mainframe tape drive
> unit and go to a desktop PC with a tape reader (yes, I had one), you
> can find what is actually written on the tape.
> And I'm sure there are sets of standards about writing tapes, starting
> from the past.
Many of those standards came from IBM.
> Initially (at least with IBM) you have a tape header record (which
> names the tape and provides a date and the ID number of the tape and
> usenumber and so on) and a tape marker, followed by the file or files
> you wrote. Some tape drives CAN read backwards but almost NEVER do to
> get data, but backspacing needs the tape drive to read data off the
> tape, backwards, to know when it has finished passing the previous
> record to find the "inter record gap" between records, stops on the
> even-earlier record, or the tape hearder tape marker, and advances
> again to position itself before the inter recored gap. This is done by
> microcode instructions, not programmed in Fortran, nor even the
> operating system as such, but part of the O/S as are say, the machine
> instructions underlying the Kernel functions are in Windows.
Well, there are two different things. For many years, IBM tape
drives could actually read data while going backwards. Among
others, it speeds up many sort algorithms, one popular use for tape
in the early days. Also, physical read and write are done at the
block level, so for blocked records data must be collected in a
buffer until it is ready to write a whole block, or read into a
buffer and then passed to the program a record at a time.
The read backwards operation is not supported in all newer tape
technologies, but backspace (without reading) usually is.
Again that is at the block level. It is usually the library
(or access methods) that have to convert logical backspace within
a block to physical backspace when going to a record in the
previous block.
> But what is written DOES depend on the mode Fortran requested the file
> to be wriiten in.
> If it was sequential formatted data you will get mostly ascii data
> bytes, but possible pure binary words written with A2 format which
> could be any combination of bits and eventually a line teminator group
> (e.g. cr-lf). If you wrote in an unformatted mode you would not have
> the line terminator group unless you actually wrote it was part of
> your data (which I do a lot).
That would be rare for IBM mainframe systems, but yes.
> But IBM wrote data from Fortran programs in the unformated modes with
> a byte count prefix and postfix. Probably a very early design decision
> that stayed around in the impletmentations. It doesn't have to be
> there and isn't on disks files. When I found about about this I asked
> "why"
Nine track tapes don't have a length field. At least for NRZI
(up to 800 BPI), and PE (1600BPI) the drive knows when there are
data bits (magnetic transitions) or not. Blocks are easy to find
that way. 6250 (GCR) is a little more complicated, but even then
I believe that gaps are real gaps. Physical backspace is done by
the drive moving the tape to a gap without bits.
Also, IBM tape drives when reading small blocks (12 bytes or less),
and in the case of a read error will treat the block as noise.
> and The answer I got was it was instrumental in being able to read
> those kinds of files backwards". True or not, I don't know.. But I
> know IBM DID used the reading of file backwards in operations of fast,
> uninterrupted file searching (the data was stored backwards, BY
> KNOWING THE LENGTH OF THE RECORD FROM THE POSTFIX COUNT). That
> explained it to me. And from then on I didn't want extra data in my
> files in case I wanted to process them another way and so never used
> the sequential unformatted mode!.
I don't know the detail before S/360, but S/360 tapes don't have
a count at the end. The buffer is filled from the end toward
the beginning such that the data comes out in the right order.
If the block is short, there will be unread space at the beginning.
The residual count is available from the channel such that the
system can return the number of bytes actually read. Tape
drives can find the beginning or end of a block without a count.
-- glen
Glen Herrmannsfeldt
(snip, I wrote)
>>Yes it is now online. I had it available about 35 years ago, and
>>was some of the sample code I had when learning S/360 assembler.
>>I remember some stories about the numerical work in the MOD II
>>library, especially the REAL*16 routines.
> Oh, God! That brings it back! Yes, I could give you some horror
> stories, from first-hand experience. I told IBM how they could
> speed up Fortran REAL*16 division by a factor of 4 without changing
> functionality (and by a bit more by reducing the precision to 1 ULP),
> but never succeeded in persuading them.
I think my second Fortran program was to print out a square
root table in REAL*16. After trying to get it to run, I finally
found that the system I was using didn't have the H extended
compiler.
Not so much later, were the stories I heard related to the REAL*16
library routines, and the use of carefully selected coefficients
for the polynomials. It may just be that this was the first
implementation of REAL*16, and IBM was trying to guard their
work.
I did have the manual with the algorithms for the math library,
but the coefficients weren't listed for many routines.
Then some years later I had a hex dump of SYS1.SVCLIB. I believe
the SVC for the TIME macro was my first try at hand disassembly,
and IEAXPDXR, the routine for emulating the non-existent
REAL*16 divide instruction, was second.
I believe that IEAXPDXR has the option of producing the exact
(truncated) quotient or one that might be wrong in the LSB
though slightly faster.
* *
* ENTRY POINT - IEAXPDXR *
* *
* INPUT - REGISTER 1 CONTAINS THE POINTER TO A PARAMETER LIST WHICH *
* CONTAINS A PTR TO THE PIE, A PTR TO AN AREA WITH REGS AT *
* INTERRUPT TIME (0-15), A PTR TO A WORK AREA, A PTR TO A BYTE *
* WHICH IS NON-ZERO IF THE LAST BIT OF DXR IS NOT TO BE *
* GUARANTEED. *
* *
Well, that is besides the fact that the 360/91 description includes
that it doesn't generate the truncated quotient defined by the
architecture, but instead the more accurate rounded quotient.
(Another reason not to compare floating point for equality.)
-- glen
nm...@cam.ac.uk
Glen Herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>
>Not so much later, were the stories I heard related to the REAL*16
>library routines, and the use of carefully selected coefficients
>for the polynomials. It may just be that this was the first
>implementation of REAL*16, and IBM was trying to guard their
>work.
Yes, they were. I attempted to use the REAL*16 erf function to
generate some accurate tables of its inverse, and filed three
simultaneous bug reports:
It was less accurate than REAL*4
It returned 1.0 when it should have returned -1.0
For extreme values, it failed with a 0C4/0C5 (i.e. SIGSEGV)
The bugs were fixed surprisingly promptly :-)
>I believe that IEAXPDXR has the option of producing the exact
>(truncated) quotient or one that might be wrong in the LSB
>though slightly faster.
Yup. Unused, as far as I know. It is that which I was referring
to - calling it directly was 4 times faster than by interrupt.
Regards,
Nick Maclaren.
Gary Scott
> Terence wrote:
> (snip)
>
>> Fortran just communicates with the O/S and asks to read, or write a
>> (talking about tape) file in a predetermined mode. Fortran has no idea
>> about VBS or MVS and so on. The various access methods provided in the
>> O/S achieved their desired actions using (in the end) machine
>> language.
>
>
> Yes. But in many cases the OS supports more access methods than
> are available to Fortran. Other languages might support them,
> or, if not, then assembler.
Fortran could call OS system services just like any other language.
There were utilities provided to make this easier.
nm...@cam.ac.uk
Gary Scott <garyl...@sbcglobal.net> wrote:
>Glen Herrmannsfeldt wrote:
>> Terence wrote:
>>
>>> Fortran just communicates with the O/S and asks to read, or write a
>>> (talking about tape) file in a predetermined mode. Fortran has no idea
>>> about VBS or MVS and so on. The various access methods provided in the
>>> O/S achieved their desired actions using (in the end) machine
>>> language.
>>
>> Yes. But in many cases the OS supports more access methods than
>> are available to Fortran. Other languages might support them,
>> or, if not, then assembler.
>
>Fortran could call OS system services just like any other language.
>There were utilities provided to make this easier.
Not packaged together with the compiler or library, there weren't,
and least not when BMD was being written.
However, all of the above is thoroughly confusing for anyone who
doesn't already know the situation! The Fortran library (run-time
system) was written in assembler, and implemented I/O by using the
standard macros. Those macros did some of the work, but Fortran's
run-time system had to do much of it (which including building the
block, and I mean block not record, in the correct format).
So the support of data formats (including blocks on tape) was done
as much by the Fortran product as by the operating system. Indeed,
at one stage, Fortran was almost the only IBM product that could
be used on certain formats (notably RECFM=VBS,LRECL=X and, if I
recall correctly, RECFM=D).
Regards,
Nick Maclaren.
Jan Vorbrüggen
> like this. It does have potential problems, but record markers are not
> among those problems.
Hmmm...I seem to remember that a direct access file on VMS/RMS did have
a byte (or, more likely, a two-byte word, given its descent from the PDP
systems) tacked onto the record to indicate whether the record was valid
or not. I suppose there's nothing in the Fortran standard to forbid such
an implementation, given that it's transparent to the program.
Jan
Larry Gates
> So the support of data formats (including blocks on tape) was done
> as much by the Fortran product as by the operating system. Indeed,
> at one stage, Fortran was almost the only IBM product that could
> be used on certain formats (notably RECFM=VBS,LRECL=X and, if I
> recall correctly, RECFM=D).
>
>
> Regards,
> Nick Maclaren.
Whether you know things about business machines on tape is one of those
generational divides for fortran. I helped my older sister with her
punchcards when she was at college but never really saw punchcards before I
took scientific programming at the university, where they were the constant
occupants of my instructor's shirt pocket.
There they were, every Monday, Wednesday and Friday in the same shirt that
changed colors, but not the location of the shirt pocket, where he kept the
cards in back and the pens in front, in the same order every time.
As far as the original post goes, silverfrost has wonderful, easy
extensions for bitmaps. I don't know if they're still doing business.
--
larry gates
We don't have enough parallel universes to allow all uses of all
junction types--in the absence of quantum computing the combinatorics
are not in our favor...
-- Larry Wall in <20031213210...@wall.org>
Luu Quang Hung
Your code seems to compile without any error on my CVF. It also run
without error. But it does not correctly read all pixels (on my
120x100 bmp, it works only for 40x1 bmp).
Anyway, thank you very much for your advisory!
> -- Henry Ford- Hide quoted text -
Luu Quang Hung
Althought I need to use G95 instead of my CVF, it still nice.
Many mamy thanks!!
Luu Quang Hung
I think using the confusing Win32 API for such case is not so
reasonable.
However, thank you for your help!
On Mar 2, 2:20 pm, "James Van Buskirk" <not_va...@comcast.net> wrote:
> "Luu Quang Hung" <luuquangh...@gmail.com> wrote in messagenews:24545ddc-910a-4687...@k36g2000pri.googlegroups.com...
>
> > I also use CVF 6.6c. Of course we could compile it since CVF support
> > form='binary', but when I conduct it with the real example
> > EXAMPLE.BMP, it reports error.
> > If you have any working example to READ BMP file (code+example.bmp),
> > please send me. I am sorry if there is any misunderstanding around.
>
> Well, if you got CVF to open a stream file, you're pretty much in
> like Flint. Except there several possible formats for the bitmap
> data which you find out from reading the header. There is also more
> than one header format.
>
> You can find this stuff out in a Windows programming book such as
> those by Charles Petzold. In fact, if you look in such a tome you
> will see how you can ask the OS to load the bitmap for you, so you
> don't have to decode the file, just invoke the Win32 API, which CVF
> is pretty good at.
>
> --
> write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
> 6.0134700243160014d-154/),(/'x'/)); end
Luu Quang Hung
Thank you for your correction.
My first attempt is to find the way to modify the code to read the
BMP. But if that work is impossible with CVF, then do you mean that I
should move to another compiler?
On Mar 2, 3:39 pm, nos...@see.signature (Richard Maine) wrote:
> Luu Quang Hung <luuquangh...@gmail.com> wrote:
>
> > Dear Richard,
>
> > Thank you for your nice comment.
>
> > As recommended by many people who join in this talk, the problem due
> > to the format of OPEN command in Fortran. Thus, since I have the full
> > code written in the first post in the topic, I just try to modify the
> > OPEN command in my program.
>
> No, the problem is not from just the OPEN. As I said in my post,
> statements do not stand alone. That is certainly true of I/O statements.
> The OPEN statement is closely tied to the READ statements. They must be
> consistent. You cannot diagnose I/O problems by separately looking at
> the OPEN and READ statements as though they had nothing to do with each
> other.
>
> > Error: "Severe (257). Formatted I/O to unit open for unformatted
> > transfer, Unit 1, file rokmask.bmp"
>
> Yes, exactly the problem I mentioned. This is about the READ statement
> being formatted, while the OPEN was for unformatted.
Gary Scott
> Dear Gary,
>
> without error. But it does not correctly read all pixels (on my
> 120x100 bmp, it works only for 40x1 bmp).
>
> Anyway, thank you very much for your advisory!
Yes, as I said it was unfinished. It was just some early thought
process stuff. It's purpose was to separate the single plane BMP format
into 3 separate planes. Lossless compression algorithms can work better
if you treat the planes separately. It was designed to handle a
specific BMP file. I had not progressed to generalizing it. I also had
not included my "kinds" module. I don't normally hard code kind numbers .
snip
Gary Scott
> Dear Richard,
>
> Thank you for your correction.
>
> My first attempt is to find the way to modify the code to read the
> BMP. But if that work is impossible with CVF, then do you mean that I
> should move to another compiler?
It is very easy with CVF...not impossible at all
>
>
>
> On Mar 2, 3:39 pm, nos...@see.signature (Richard Maine) wrote:
>
>>Luu Quang Hung <luuquangh...@gmail.com> wrote:
>>
>>
>>>Dear Richard,
>>
>>>Thank you for your nice comment.
>>
>>>As recommended by many people who join in this talk, the problem due
>>>to the format of OPEN command in Fortran. Thus, since I have the full
>>>code written in the first post in the topic, I just try to modify the
>>>OPEN command in my program.
>>
>>No, the problem is not from just the OPEN. As I said in my post,
>>statements do not stand alone. That is certainly true of I/O statements.
>>The OPEN statement is closely tied to the READ statements. They must be
>>consistent. You cannot diagnose I/O problems by separately looking at
>>the OPEN and READ statements as though they had nothing to do with each
>>other.
>>
>>
>>>Error: "Severe (257). Formatted I/O to unit open for unformatted
>>>transfer, Unit 1, file rokmask.bmp"
>>
>>Yes, exactly the problem I mentioned. This is about the READ statement
>>being formatted, while the OPEN was for unformatted.
>>
>>--
>>Richard Maine | Good judgment comes from experience;
>>email: last name at domain . net | experience comes from bad judgment.
>>domain: summertriangle | -- Mark Twain
>
>
robin
So, then, you made a false statement, as I said.
|>> where
|>> the trick of using RECL=1 and ACCESS='DIRECT' will usually 'work'.
|>> But, as Richard said, it is not specified by the standard - and many
|>> of us know of systems where it will not work.
|>>Such as?
Still no answer to support your claim?
robin
news:3fc65ef3-4b6d-451e...@h5g2000yqh.googlegroups.com...
|On Mar 2, 4:53 pm, "robin" <robi...@bigpond.com> wrote:
|> "Gary Scott" <garylsc...@sbcglobal.net> wrote in message
|
|> news:oMyql.566$im1...@nlpi061.nbdc.sbc.com...
|>
|> > robin wrote:
|> > > "Richard Maine" <nos...@see.signature> wrote in message
|> > >news:1ivsldm.3ocdw4a737ngN%nos...@see.signature...
|>
|> > >>Craig Powers <craig.pow...@invalid.invalid> wrote:
|>
|> > >>>Incidentally, looking through the PGF documentation available on my
|> > >>>system (for version 7.0-6), I don't see anything that indicates support
|> > >>>for stream access, so PGF may not support this common extension to F9x.
|>
|> > >>If the compiler doesn't support stream directly, about the next best
|> > >>thing is direct access unformatted. That can run into problems with the
|> > >>last part of a file if it has a "partial record",
|>
|> > > Not when the record length is 1.
|>
|> > On some systems, "1" means "1 integer sized unit" not "1 byte sized
|> > unit", by default.
|
|> such as?
| CVF/IVF - there are options to change it
To byte.
Gary Scott
Of course, the concern was about the default which may be a surprise in
some cases.
robin
> >I don't think there was a Fortran compiler for PCP,
>
> IIRC both Fortran-G and Fortran-H ran just fine under PCP, so long as
> you had enough core. THe wimpoidal OSes were DOS and TOS and BPS,
> although I think Fortran-G could be run under DOS or TOS.
DOS was intended for use on small memory systems like 32K.
In that memory, I very much doubt that the Fortran G compiler would run.
E might have.
robin
> I don't think there was a Fortran compiler for PCP, so what system
> are you referring to?
There was.
One was the E compiler. G also ran.
As well as PL/I.
robin
> Kevin G. Rhoads wrote:
> (snip)
> > THe wimpoidal OSes were DOS and TOS and BPS,
> > although I think Fortran-G could be run under DOS or TOS.
>
Fortran E ran under OS/360 PCP.
Until Release 13, when it came with bug(s) and it didn't work
at all.
robin
> In article <gocklc$b9i$1...@aioe.org>,
> Glen Herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>
> >I presume Fortran G would run on a PCP system with enough memory.
>
> Yes, but would the library?
That too.
robin
> nm...@cam.ac.uk wrote:
> (snip)
>
> >>I presume Fortran G would run on a PCP system with enough memory.
>
> > Yes, but would the library?
>
> As far as I know, PCP can do everything that OS/360 is supposed
> to do with only one task running. Some SVCs don't do anything,
> especially ones related to multitasking. Also, I believe that
> there is no timer so date and time don't work.
>
> PCP is supposed to be able to run PL/I (F), which usually
> requires more of the OS than Fortran does. Among others,
> it does a lot of GETMAIN/FREEMAIN and LINK macros.
Indeed it could.
Look, PCP ran all of the IBM software, the only requirement
being that there be sufficient memory (which would apply to
any of the OS's, of course).
For systems with 128K or less memory,
MFT could not feasibly be run, and PCP was the only choice.
For really small memories, DOS was available.