.pcx support

Paul,

I have recently been upgraded to Microsoft Office 2003, which does not appear to support .pcx files. While clearwin+ also supports .jpg files, I have not liked the set_jpeg_quality options that .jpg provide and .bmp files are too big. The .pcx files appear more suited to engineering diagrams with a limited palette. ( Am I wrong with these generalities ? )

Is there support for any other graphics formats being contemplated ?

I think we have asked before, but I also use .gif files for importing images into word documents. These also don't appear to have the quality problems that .jpg files have and are very compact for graphs.

John

John,

Some easy-to-program options include:

HPGL (HP graphics language, originally for vector pen plotters, but with some raster capability). SVG (Scalable Vector Graphics) - an XML option again with vector and raster capabilities PostScript (there are downloadable Fortran packages for doing this).

I could let you have some basic SVG generating routines.

Why is BMP too big?

Eddie

Eddie,

Thanks for your reply. My experience of .bmp files is they are very large. I opened a .gif file of an excel chart (15kb) in Microsoft paint and saved it as a 24 bit .bmp file (3,297kb). As a general rule I find: .gif files are about 30kb to 100kb ( but with a restricted colour palette) .pcx files are about 300kb to 500kb .bmp files are about 3,000kb to 4,500kb

Most of my graphics is excel charts or some finite element colour shading, but not photos. My graphics is rater based, so vector would need to be regenerated. .jpeg applies a quality (bluring) to these and it works badly with both these types of images. My understanding is both .pcx and .gif use repetition for compression but do not apply a bluring, as in the case of .jpeg We need a public domain version of .gif

Why is BMP so big?

John

Hi John,

BMP files are uncompressed (OK, a runlength compression is possible but unusual). Therefore you have maximum quality with BMP but also maximum size: [No. of lines]*[No. of pixels per line]*bit/8 bytes plus the header (54 bytes / 24 bit, 1078 bytes / 8 bit). I think that in some of your cases a colour depth of 8 bit will be sufficient.

It would be of interest to create a runlegth compressed BMP and to see if standard software can read this.

Regards, Wilfried

Wikipedia http://en.wikipedia.org/wiki/Graphics_Interchange_Format has an interesting article on GIFs, stating that the patents have lapsed. There doesn't seem to be any reason, therefore, apart from the hellish complexities of implementing it, why FTN95 shouldn't have a 'save to GIF' format ...

Eddie

All we need is a volunteer to write the save to .gif in ftn95. We have the ability to get each colour and map it to a 256 colour palette and the ability to dump to a general format binary file. The only bit missing is the 'Lempel-Ziv-Welch (LZW) lossless data compression technique'

John

Lempel-Ziv-Welch Just pronoucing that is enough to put me off!

A google search reveals C source code , but this may as well be double-dutch to me!

But an excellent idea if someone wishes to take this up and list the ftn95 code here.

Well... I have some good news for you. GIF support has been in Clearwin for many years, but has simply not been documented or included in the headers due to the patent issues. I was not aware they had lapsed (the last time I looked at this they were still in force). Anyway, all you should need to do is update your headers with:

  C_EXTERNAL IMPORT_GIF@ '__import_gif' (INSTRING,REF) :INTEGER*4
  C_EXTERNAL EXPORT_GIF@ '__export_gif'(VAL,INSTRING,REF)      
  C_EXTERNAL WRITE_GRAPHICS_TO_GIF@ '__write_graphics_to_gif'       
 &(INSTRING,REF)   

The above routines should behave in much the same way as IMPORT_BMP@, IMPORT_PCX@ etc.. There is no explicit EXPORT_IMAGE@ support for GIF, but that can go in for the next release. EXPORT_IMAGE@ simply calls the appropriate EXPORT_XXX routine anyway depending on file extension.

There is also %GI, which has been documented before and is in the help file.

I have no idea of the state of these routines as they have not been dusted off in a very long time, but feel free to see how things go.

Andrew,

Your e mail is excellent news, and I am glad I turned to Wikipedia!

My understanding is that LZW compression is simply yet another form of Huffman encoding, which is covered (Huffman, not LZW) in Anton Kruger's 'Efficient Fortran Programming'. On the other hand, isn't it likely that Silverfrost's C compiler SCC could compile a standard chunk of code?

Eddie

Andrew,

I currently use the routine :

WRITE_GRAPHICS_TO_PCX@( FILENAME, ERROR )

can I simply change it to the following with the appropriate declaration ?

WRITE_GRAPHICS_TO_GIF@ ( FILENAME, ERROR )

It is great news if I can, as my images all have less than 256 colours and should be suited to gif compression.

I will probably try it before your reply !!

John

Postscript :

I got the following message that the symbol '__write_graphics_to_gif' was missing. Could you please email me an updated salflibc.dll which has this available.

My screen dump routine, cloned from .pcx and .jpg is:

    Subroutine Dump_gif_func (message)
!
!  dumps a gif file from active selected region
!
!    use mswin
    include <clearwin.ins>
!
    C_EXTERNAL IMPORT_GIF@ '__import_gif' (INSTRING,REF) :INTEGER*4 
    C_EXTERNAL EXPORT_GIF@ '__export_gif'(VAL,INSTRING,REF) 
    C_EXTERNAL WRITE_GRAPHICS_TO_GIF@ '__write_graphics_to_gif' (INSTRING,REF) 
!
    integer*4 error_gif, file_nn, nx, ny
    integer*4 lu, get_file_unit
    character file_gif*12, message*(*)
    external  get_file_unit
    data file_nn / 0 /
!
!    develop a screen dump file name
!
      lu = get_file_unit (90)
      close (unit=lu)
!
   11 file_nn = file_nn + 1
      if (file_nn.gt.999) then
         error_gif = 1
         goto 100
      end if
!
      write (file_gif,'(a,i3.3,a)') 'dump',file_nn,'.gif'
      open  (unit=lu,file=file_gif,status='new',err=11)
      close (unit=lu,status='delete')
!
      call write_graphics_to_gif@ (file_gif, error_gif)
!
  100 call get_graphical_resolution@ ( nx, ny )
      write (98,1000) file_gif, nx, ny, lu, error_gif
 1000 format ('gif DUMP file ',a,  &
              ' Size :',i6,' x',i6,' (lu',i3,' error',i4,')')
!
      if (error_gif.eq.0) then
         message = 'gif dump to '//file_gif
      else if (error_gif.eq.1) then
         message = 'Unable to open '//file_gif
      else if (error_gif.eq.3) then
         message = 'Unable to dump to '//file_gif
      else
         message = 'Unable to use '//file_gif
      end if
!
      end subroutine Dump_gif_func
 

I do apologise.

__write_graphics_to_gif

is not implemented in the release thats currently out, sorry I missed that. However, you can download a build of salflibc from:

[link removed]

Which does have the routine in. The other routines I mentioned were already in the release build of salflibc.dll.

Andrew,

I tried the download you indicated but winzip does not recognise the file. Is it corrupt ?

John

John,

Use 7-Zip , it works!

regards, John

Andrew,

I managed to get 7-zip and extracted the new .lib and .dll

I replaced my old version and ran the program selecting .gif, rather than .pcx

I now get an error message 'Error 376, Attempt to delete unallocated storage'. when calling write_graphics_to_gif@

I am working on my notebook at home, which has FTN95 Ver 4.9.1 installed. I was hoping the .dll and .lib would be upward compatible. Could this explain the error ?

In the past, I've been running two different versions of the compiler to test if any unusual errors are different between compiler versions. Should I install ver 5.3 to fix the problem ?

John

I've now installed 5.3.0 and I still get the same error. Are the arguments the same as for .pcx ?

The arguments are the same, and I don't know why off hand you are seeing that error, however it may simply be a symptom of other problems with the routines.

As I said in a previous post, this code has not been looked at in a long time and it appears there were some issues with it. The main problem was that if the graphics block was of greater depth that 8 bit (everything these days), then the GIF would not save as the colour depth was wrong. I have added a function to auto-convert to 8 bit before saving the GIF and it indeed does appear to save correctly for me now. There was also an issue with a comment being embedded in the GIF, which also broke the format.

I will get another build of salflibc up for you to try as soon as possible.

A new build is now available for download from:

http://www.ftn95.co.uk/ftn95/salflibc.zip

This is working in my test setup for a simple image using:

WRITE_GRAPHICS_TO_GIF@

Andrew,

The latest version works. Thank you very much for the prompt fix.

I have pcx, jpg and gif file dumping selected and get .gif is 68kb, .pcx is 177kb and .jpg is 396kb. The gif and pcx look identical, but the jpg has some background distortion behind black text. Certainly .gif is a good solution for technical charts, while jpg may be better for other types of pictures.

John

There is the function:

SET_JPEG_QUALITY@

Which could affect the results with JPG (and would also affect the size of the image).

My understanding of .gif graphics file format is that it supports 256 different colour settings. Unfortunately they appear to be different from my program's colour settings. I have been using .gif files as screen dumps which I can easily import into other packages (eg Word) for printing and reports. For my schematic diagrams, the .gif format works very well in terms of compactness and where there are few colours. I also have a program which generates a colour palette of about 140 different colours. Unfortunately when I dump this to a .gif file, my colour pallette does not match well the .gif file's 256 available colours. As a consequence, my colours are maped to near colours, with a lot of different colours in my rainbow becoming the same colour. What options might I have available ?

• Can I change the colour palette in the .gif file to include all of mine, or
• Can I get the list of 256 standard colours to see what I may be able to better use in my program, or
• Can we support a .png file, which I understand is the updated version of .gif with a larger colour palette ?

I'd appreciate any ideas on how to improve my graphics result

John

Yea, bmp creates huge files, pcx is outdated, jpg is lossy, and gif is proprietary and due to that is essentially not available. If developers add PNG at some point it would be great.

I also miss gif, if allowed the living gifs (animations) would be next step with this compiler but the whole gif usage was killed by greedy patent holder.