DIB_BLOCK limits

Having already spent a great deal of time fixing the problem of the limit and given the complexity of the library and of your questions, I find it very difficult to provide any insight for you.

I am aware of changes in the rgb and grb order depending on the context. The only comment I can add at the moment is to note that I did find it helpful to look at the PARRAY by viewing the memory with SDBG.

I hope that you will understand that there is always one more question after the last and there are many demands upon my time.

Thanks to Paul for identifying the reported problem - and huge thanks also to John for the detailed investigation! I think I now have a couple of workable solutions for the immediate future - indeed three workable solutions if the new salflibc.dll will remove the 2048 X limitation.

In summary -

• I can generate SVG which operates entirely independently of the Clearwin+ graphics and generates externally viewable graphics files - but not as standard images like jpeg or gif. Based on coding in the public domain I am now building my own simple SVG library which ultimately may be useful to make generally available, as it seems there isn't one already (well there is a Fortran SVG library from FENIA but at first glance this one seems unnecessarily complex).

• Using the Clearwin+ graphics enbvironment I can directly export GIF files without the 2048 x-pixels limit, using the current salflibc.dll

• If the the next salflibc.dll removes the limit, then I can use this to generate jpg files too.

I understand John's further questions and agree that it would be good to know in more detail just how the Clearwin+ graphics works, but I think that is the subject for another discussion thread!

I do not like the mess around GIFs patented functionality but it is still good to create animations from numerical simulations for Powerpoint presentations.

Question to Paul: Clearwin+ can now take GIF files as a resource. Any chance we will get put_dib_block@ to save in GIF format?

Question to ALL: -Do you know library which we can call from Fortran to automate creation of living GIFs ? -and Fortran callable library which transforms pcx (or BMP which are lossless format in Clearwin suitable for animation purposes) into gif? (i have used one 20 years ago with DOS and Salford FTN77 call to DOS prompt)

Question to OP: Can SVG do the functionality of living gifs?

Hello, Dan - I'm not an expert on graphics formats, but when researching it, I'm sure I saw some animated SVG images. The real beauty of SVG, though, is that it's an open XML format that requires no special coding to export - you just use ordinary Fortran sequential writes. I've put together a small subroutine library that does what I need, and happy to send you a copy, or there are a couple of published fortran SVG libraries (source available free on the web) though these are both much more complex (and comprehensive) than I needed. -Steve ... ps - just googled and got this - http://en.wikipedia.org/wiki/SVG_animation which answers your question, I think!

Dan

There is an undocumented routine EXPORT_GIF@ which has the same arguments as EXPORT_BMP@. The interface is

C_EXTERNAL EXPORT_GIF@ '__export_gif'(VAL,INSTRING,REF)

Dan,

I do not know what 'living GIFs' are, but I do create single .gif images using the following code. Subroutine Dump_gif_func (message, prefix) ! ! dumps a gif file from active selected region ! ! use mswin include <clearwin.ins> include <JDC_menu.ins> ! C_EXTERNAL IMPORT_GIF@ '__import_gif' (INSTRING,REF) :INTEGER4 C_EXTERNAL EXPORT_GIF@ '__export_gif' (VAL,INSTRING,REF) C_EXTERNAL WRITE_GRAPHICS_TO_GIF@ '__write_graphics_to_gif' (INSTRING,REF) ! integer4 error_gif, file_nn, nx, ny character file_gif80, message(), prefix() integer4 ncol, rgb_values(1024) data file_nn / 0 / ! ! develop a screen dump file name ! call get_next_dump_file (file_nn, file_gif, prefix, '.gif') if (file_nn > 999) then error_gif = 1 goto 100 end if ! call write_graphics_to_gif@ (file_gif, error_gif) ! 100 call get_graphical_resolution@ ( nx, ny ) write (98,1000) file_gif, nx, ny, error_gif !z write ( *,1000) file_gif, nx, ny, error_gif 1000 format ('gif DUMP file ',a, & ' Size :',i6,' x',i6,' (error=',i4,')') ! if (error_gif == 0) then message = 'gif dump to '//file_gif else if (error_gif == 1) then message = 'Unable to open '//file_gif else if (error_gif == 3) then message = 'Unable to dump to '//file_gif else message = 'Unable to use '//file_gif end if ! !zz call report_region_colours ! Test of colours on screen ! call get_screen_colour_table (ncol, rgb_values) ! end subroutine Dump_gif_func

The existing routines use a fixed 256 colour table. I am at present working with Robert at Silverfrost to provide a more flexible colour table, which has been the basis of all my recent questions about direct addressing. The functionality will be to put the colour table review before the .gif dump, possibly revising both the colour table that is used by the .gif dump and revising the screen colours to a reduced 256 colour set. I am going to get this working with a DIB interface and see how well it works.

John

Great that gif export is there.

I had in my code outputs in BMP & PCX already programmed in and adding GIF option was just 1 min work. I also added c_external declaration but by some reason the output creates the file of zero size...BMP and PCX work fine. What the heck this could be? An older Salflibc ?

'Living gif' i've heard people call GIF89a (or something like that) standard for animated gif files . Living GIF is still used because uses 8bits per color instead of 24 which is useful to reduce size when compressed. Here is an example

All of the gif stuff has been in salflibc.dll for a long time but not exposed because of earlier copyright limitations.

A very simple way to export to GIF is the (also undocumented?) function EXPORT_IMAGE@(file_name). The output format is given by the extension of the file name (BMP, PCX, JPG or GIF).

INTEGER FUNCTION EXPORT_IMAGE@(file_name) CHARACTER*(*) file_name

file_name is the name of a file. The file name extension determines the type of image file to be created and must be one of: .jpg, .jpeg, .bmp, .pcx (or .gif!). The function returns a non-zero value when successful.

and

The quality of a JPEG image exported by EXPORT_IMAGE@ can be changed by calling the new function SET_JPEG_QUALITY@ as follows:

REAL8 FUNCTION SET_JPEG_QUALITY@(Q) REAL8 Q

Q is an input value in the range from 0.01D0 to 1.0D0 (use steps of 0.01). The function returns the old value should you wish to restore it afterwards. The default value of Q is 0.75D0.

Citations from cwplus.enh

Regards - Wilfried

Your way of GIF creation works, Wilfried. I do not know what's wrong with the other way...may be something is corrupt in my code. Thanks to all anyway, will find the bug eventually.

John, How specifically do you think palettes have to be implemented with only 256 colors so that it wil be simple to use them? 6R * 6G * 6B + 40?

Also, do anyone know the utilities which already implemented different palettes for 24bit RGB so that you change value from 0 to 1 and the color goes from darker end of palette to bright one? I have done several my own like those ones but will be happy to get something new too. here red palette is very simple, but rainbow already need some programming. Or may be somebody realized something like 'Universal Clearwin Palette Builder' when you can make arbitrary ones with just few mouse clicks?

Dan,

Robert from Silverfrost has been providing new routines to manage the colour palette for .gif files, as there are only 256 colours available in the .gif format. .gif is a very compact format that is still generally supported. To better manage the palette, there are new routines to:

• Get the default palette,
• Update the palette, or
• Reset to the default palette You would find that dumping the graphic you have presented above to a .gif file would result in loosing many of the close peach colours. I am testing how to revise the colour palette by:
• importing the image to a DIB array,
• choose the 256 colours that occur most often in the display, and
• providing this colour palette, before calling write_graphics_to_gif@

I've now got the DIB importing and am now trying to choose the best palette. Hope to have this complete soon, between other crises !

John

Just a remark: I don't think that the reduction of colours from 24 to 8 bits is good via selecting the 256 colours that most often occur. Perhaps it is better to implement methods like Floyd-Steinberg.

Regards - Wilfried

I'd also prefer to consider (but not insist in any way) the same straightforward, transparent and simple utility like 24bit colors has:

rgb256@(ir,ig,ib) where ir,ig,ib = 0....5

It will cover 216 colors. The rest could be any preset colors like ones from 4-bit palette, black and white palette or no any.

If you want substantially more than 256 colours, then .png is the updated version of .gif. However, my graphics typically has a 128 colour palette. For some reason unknown to me, I can get an additional 100 to 800 additional colours in pixels near to text. I'm not sure of the source of this shading around text. I've been writing a view cleanup routine to reduce the number of colours back to less than 256 and to also provide my new palette to the .gif writer. If I do a light source shading view of the surface, I have a lot of close colours, which the default .gif palette reduces to about 3 or 4 colours. Anyway, I'm near the end of this. My other problem with this project is that I'm using a fairly large model (20 million polygons) which is challenging the amount of free memory available. Keep getting the same types of problems in a variety of projects.

John

How do you plot your 20M polygons?

Dan, I dump them to my virtual screen where each pixel has both colour and depth. The polygons are very simple, only 3 or 4 sided, assumed as a flat surface, with colour and depth at the corners as reals. (paint each pixel on a series of straight lines) At the end of the plot I dump to the clearwin graphics region, then follow with the more difficult text etc drawn direct to the graphics region. It works realy well. Surprisingly fast. No Opengl, although I think Opengl is more suited to more complex surfaces. Most plots are smaller, as I zoom in to pick up the detail. Struggling with stack problems lately as I am running out of memory and the get_filtered_file@ stack error is also limiting capacity. For motion, I first paint a series of stored views then cycle through displaying them to the screen. (Have not confirmed the available stack for this on a big model. I only have limited functionality for the realy big model, which is a surface model for the sea-bed) Clearwin+ is very good for this.

John

I also do something similar. Clearwin and graphics libraries are really powerful and fast.

But its OpenGL just blows you out of the water. Do you see the picture i posted above with OpenGL example? I made its matrix 4500x4500 = 20M and ran the test. I do not have 20Megapixels monitor yet to put the whole 20M polygons on screen. But on 4 and 8M pixels of two-monitor screens (combined) this gigantic surface still rotates with the 20 frames per second without even hardware acceleration!

I have progressed with the use of DIB and educated myself on some performance issues with my graphics code. My large polygon drawing routine is a bit slower than I recalled to Dan, taking about 5 seconds to prepare polygons and paint the screen, although I've never considered the delay unacceptable. ( I might have made a mistake by choosing this as my testing example.) As for the colour review of the screen for a .gif dump, the slowest parts are the review of the colour tablet (.13 sec) and reporting the colour palette to the OUTPUT screen (.11 sec) (surpriningly slow for a write statement) while the accessing of the DIB block is very fast (.01 sec) I'm now only reporting results to a file. DIB appears to be a viable alternative to direct addressing for the approach I am using. I look forward to the /DEBUG and enlarged DIB support in the new update.

Thanks very much Paul and Robert for all your assistance with this as I have made some progress. The change to Windows 7 has resulted in much more work than I origionally intended.

John

May be someone can use it: A way to reduce colours and create an 8-bit image from a 24-bit one.

c     image_1: input, 24 bits, size = rows*cols
c     image_2: output, 8 bits, same size

      integer*4     A,B,C,i,j,k,l,m,n,o,p,dsp
      real*8        r
      character*1   rgb_a(3,0:255)

c     reduce number of colours (Floyd-Steinberg method)

      dsp = 3*cols

      do i = 1,rows-1
        A = (i-1)*dsp
        B = A+dsp
        do j = 4,dsp-3,3
          do n = 0,2
            o = j+n
            k = ichar(image_1(A+o))
            if (k .gt. 0) then
              l = 50*int(k/50.)
              image_1(A+o) = char(l)
              r = dble(k-l)
              p = ichar(image_1(A+o+3))
              if (p .gt. 0) then
                C = min(p+nint(.4375*r),255)
                image_1(A+o+3) = char(C)
              end if
              p = ichar(image_1(B+o-3))
              if (p .gt. 0) then
                C = min(p+nint(.1875*r),255)
                image_1(B+o-3) = char(C)
              end if
              p = ichar(image_1(B+o  ))
              if (p .gt. 0) then
                C = min(p+nint(.3125*r),255)
                image_1(B+o  ) = char(C)
              end if
              p = ichar(image_1(B+o+3))
              if (p .gt. 0) then
                C = min(p+nint(.0625*r),255)
                image_1(B+o+3) = char(C)
              end if
            end if
          end do
        end do
        image_1(A+1)   = image_1(A+4)
        image_1(A+2)   = image_1(A+5)
        image_1(A+3)   = image_1(A+6)
        image_1(dsp  ) = image_1(dsp-3)
        image_1(dsp-1) = image_1(dsp-4)
        image_1(dsp-2) = image_1(dsp-5)
      end do

      A = (rows-2)*dsp
      do j = 1,dsp
        image_1(A+dsp+j) = image_1(A+j)
      end do

c     create colour palette

      rgb_a = char(255)
      A = 0
      do k = 0,255,63
        do l = 0,255,63
          do m = 0,255,63
            rgb_a(1,A) = char(k)
            rgb_a(2,A) = char(l)
            rgb_a(3,A) = char(m)
            A = A+1
          end do
        end do
      end do

c     create 8 bit image

      do i = 1,rows
        A = (i-1)*dsp
        B = (i-1)*cols
        do j = 1,dsp,3
          k = ichar(image_1(A+j  ))/50
          l = ichar(image_1(A+j+1))/10
          m = ichar(image_1(A+j+2))/2
          n = (j+2)/3
          image_2(B+n) = char(max(k+l+m,1))
        end do
      end do

Regards - Wilfried

There's a lot of work that has gone into this, by users - John, Wilfried, Dan - and clearly also by Silverfrost.

Quick question - will Silverfrost be documenting the GIF-related library additions and perhaps also providing some demo examples, in the next compiler update? This is something that would be extremely useful, and not only to the few who have participated in this thread.