forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

GIF file from %og graphics ?
Goto page Previous  1, 2, 3, 4  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+
View previous topic :: View next topic  
Author Message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Thu Oct 23, 2014 9:33 pm    Post subject: Re: Reply with quote

DanRRight wrote:
Wilfried, i'd also add the deallocate to your first code

Sorry I meant Erwin but wrote Wilfried, I'd add deallocate to your code, few large files repeated many times may take huge chunk of RAM making a memory leak
Back to top
View user's profile Send private message
EKruck



Joined: 09 Jan 2010
Posts: 224
Location: Aalen, Germany

PostPosted: Fri Oct 24, 2014 8:31 am    Post subject: Reply with quote

Thank Dan,

according to FORTRAN rules local allocated memory has to be de-allocated automatically after return from the subroutine. However, it does not work - I checked it. Memory usage will be increased after each call.

I have to check my other programs as well.

Erwin
Back to top
View user's profile Send private message Visit poster's website
EKruck



Joined: 09 Jan 2010
Posts: 224
Location: Aalen, Germany

PostPosted: Fri Oct 24, 2014 11:03 am    Post subject: Reply with quote

Paul,

as you see from my last post, size of the occopied memory of my program is increasing after each call of the subroutine. Of course I will deallocate the arrays.

I tried the same when calling the subroutine with the parameters (...,iSizeX,iSizeY) and use automatic allocation like in the code from John Horspool, or as shown below. The occupied memory is still increasing after each call of the subroutine.

Code:

 PROGRAM MemTest1
    IMPLICIT   NONE
    INTEGER*4  I, J, K
    DO I= 1, 100000
       J = 2000
       K = 2000
       WRITE(*,'(i10)') I
       CALL Sub1 (J, K)
    ENDDO
    END PROGRAM MemTest1

    SUBROUTINE Sub1 (M, N)
    IMPLICIT   NONE
    INTEGER*4  M, N
    INTEGER*4  Large(M,N)
    Large(1,1) = 123456789
    Large(M,N) = Large(1,1)
    RETURN
    END  SUBROUTINE Sub1


In the example above everything works fine as well if I use allocate without deallocate.
There seems to be a terrible bug for larger code ?!

Erwin
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Fri Oct 24, 2014 1:42 pm    Post subject: Reply with quote

Thanks. I have logged this for investigation.
Back to top
View user's profile Send private message AIM Address
EKruck



Joined: 09 Jan 2010
Posts: 224
Location: Aalen, Germany

PostPosted: Sat Oct 25, 2014 12:14 pm    Post subject: Reply with quote

Paul,

after introduction of an deallocate, the occupied memory of my program is still increasing after each creation of a GIF file.

Therefore I reduced the program to a minimum which I would like to send to you by email for further evaluation (no exe-file).

Erwin
Back to top
View user's profile Send private message Visit poster's website
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Sat Oct 25, 2014 12:30 pm    Post subject: Reply with quote

I finally had time to look at what Wilfred posted last Thursday. The following change, using FTN95 Ver 7.10.0 works ok, at least up to exporting the 3 images. I did not look at the BMP import, as I am not familiar with these routines.
As I have demonstrated, export_image@ works well. I think support for .png was introduced recently in Ver 6.35; not sure when .gif was supported.
Hopefully if this example works for you, the difference between .gif and .png shows the limited colour palette.
Code:
      winapp
       program test
       implicit none
       include <windows.ins>

       integer*4      i,j,A
       character*1    image(1450000)
       character*256  ifile,ofile, gfile,pfile

       c_external bmp_imp '__import_bmp'(STRING,REF) : integer*4
       c_external gif_exp '__export_gif'(VAL,STRING,REF)

       ifile = 'test.bmp'//char(0)
       ofile = 'test.gif'//char(0)
       gfile = 'test_02.gif'
       pfile = 'test_02.png'

!    create 24-bits test image

       do i = 1,600
         A = (i-1)*2400
         do j = 1,2400,3
           image(A+j  ) = char(mod(j,255))
           image(A+j+1) = char(mod(i,255))
           image(A+j+2) = char(mod(i+j,255))
         end do
       end do

!    off-screen graphics & export to BMP

       j = create_graphics_region@(4L,800L,600L)
       j = select_graphics_object@(4L)
       call display_dib_block@(0,0,image,800L,600L,0,0,800L,600L,0,0,i)
       if (i == 0) then
         j = export_image@ (ifile)
         j = export_image@ (gfile)
         j = export_image@ (pfile)
       end if
       j = delete_graphics_region@(4L)

!    import of BMP and export to GIF

       A = bmp_imp(ifile,i)
       if (i == 0) call gif_exp(A,ofile,i)   !! here the program failes
       end


Last edited by JohnCampbell on Sat Oct 25, 2014 1:00 pm; edited 1 time in total
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Sat Oct 25, 2014 12:59 pm    Post subject: Reply with quote

Erwin,

I am trying to understand your memory leak problem. I can't identify which code sample has the problem.
If it relates to reading a .bmp file into a DIB handle, then there is memory associated with the handle, which has to be released.
I have also seen some memory leak associated with some .gif routines, but I recall this was not a large amount of memory.
I think Fortran's use of ALLOCATE is more robust than C's malloc, as the deallocate is now implicitly required.

In the production version of your code, how many .gif files do you need to create ?

John
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Sat Oct 25, 2014 1:26 pm    Post subject: Reply with quote

If deallocation works by default (or should work) when exit the sub - great, i did not check that lately because having eternal problem with lack of memory i always deallocate. As to how many files - we sometimes output 1000 files for making movies of process dynamics
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Sat Oct 25, 2014 2:23 pm    Post subject: Reply with quote

Yes. As I recall, the standard requires an automatic DEALLOCATE on return.
Back to top
View user's profile Send private message AIM Address
EKruck



Joined: 09 Jan 2010
Posts: 224
Location: Aalen, Germany

PostPosted: Sun Oct 26, 2014 11:52 am    Post subject: Reply with quote

Dan, John,

I tried of course to return the memory by setting the DIB handle to zero und calling window_update@. There was no enhancement.

The purpose of the GIF files in this program is to rotate the graphics and make series of GIF files and play it later. For several 3D point cloud objects you can recognize the structure only, when the object will be rotated. Because this is a new feature in the program, I do not know how many shots will be made.

In the other 5 graphics programs - using %gr - the memory is as well increasing but the amount is only 30 to 40 KB per shot and therefore neglectable.

Erwin

BTW: I have sent the source to Paul.
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Sun Oct 26, 2014 1:21 pm    Post subject: Reply with quote

Looks like you need

Code:
    CALL Release_Screen_Dib@(iBMP_Handle)
Back to top
View user's profile Send private message AIM Address
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Sun Oct 26, 2014 11:38 pm    Post subject: Reply with quote

I modified the code to produce 100 progressively larger .bmp, .png and .gif images.
It all appears to have worked, until the exit read, which did not work.
It generates about 1,000 mb of graphics files and finishes with little memory usage. I did not use the .bmp import.
At the end, memory usage was 12 mb.

John
Code:
      winapp
       program test
       implicit none
       include <windows.ins>

       character*1, allocatable, dimension(:,:,:) :: DIB_image

       integer*4     n, i,j,k, nx, ny, screen_handle
       character*256 ifile, gfile,pfile

       do n = 0,99
         write (ifile,fmt='(a,i2.2,a)') 'test_',n,'.bmp'
         write (gfile,fmt='(a,i2.2,a)') 'test_',n,'.png'
         write (pfile,fmt='(a,i2.2,a)') 'test_',n,'.gif'

!    create 24-bits test image
         nx = 800+n*25  ! increased from 10 to test larger DIB images
         ny = 600+n*20  ! was 15
         allocate ( DIB_image(3,nx,ny), stat=j )
          if ( j /= 0 ) then
            write (*,*) 'stop at ALOOCATE for n=',n
            stop
          end if
         do i = 1,ny
           do j = 1,nx
             k = (j*3-2)
             DIB_image(1,j,i) = char(mod(k,255))
             DIB_image(2,j,i) = char(mod(i,255))
             DIB_image(3,j,i) = char(mod(i+k,255))
           end do
         end do

!    off-screen graphics & export to BMP
         screen_handle = 4
         j  = create_graphics_region@ (screen_handle, nx, ny)
          if ( j /= 1 ) then
            write (*,*) 'stop at create_graphics_region@ for n=',n
            stop
          end if
         j  = select_graphics_object@ (screen_handle)
          if ( j /= 1 ) then
            write (*,*) 'stop at select_graphics_object@ for n=',n
            stop
          end if
!
         call display_dib_block@ (0,0,              &  ! the position (X, Y) on the current graphics device
                                  DIB_image,nx,ny,  &  ! the DIB array
                                  0,0,nx,ny,        &  ! position on the current graphics device
                                  0,0,j)               ! FUNCTION,MODE,ERCODE )
          if ( j /= 0 ) then
            write (*,*) 'stop at display_dib_block@ for n=',n
            stop
          end if
!
         if (j == 0) then
           j = export_image@ (ifile)
            if ( j == 0 ) write (*,*) 'unable to create ',trim(ifile)
           j = export_image@ (gfile)
            if ( j == 0 ) write (*,*) 'unable to create ',trim(gfile)
           j = export_image@ (pfile)
            if ( j == 0 ) write (*,*) 'unable to create ',trim(pfile)
         end if
!
         j = delete_graphics_region@ (screen_handle)
         deallocate ( DIB_image )
       end do
       write (*,*) 'test completed; check memory usage'
       read  (*,*) n

       end
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Mon Oct 27, 2014 8:43 am    Post subject: Reply with quote

John,
I think it is not what was needed. Can you make the same creation of graphics files not in main program but **in the subroutine/function** calling it 100 times with and without deallocate inside the subroutine/function?
Back to top
View user's profile Send private message
EKruck



Joined: 09 Jan 2010
Posts: 224
Location: Aalen, Germany

PostPosted: Mon Oct 27, 2014 10:11 am    Post subject: Reply with quote

Thank Paul,

using "CALL Release_Screen_Dib@(iBMP_Handle)" the memory is not increasing anymore - as well without deallocate.

Erwin
Back to top
View user's profile Send private message Visit poster's website
EKruck



Joined: 09 Jan 2010
Posts: 224
Location: Aalen, Germany

PostPosted: Fri Nov 07, 2014 11:33 am    Post subject: Reply with quote

John,

I have implemented your code. It works fine and faster. Thank you as well for your private hint.
I decided to allow users to apply GIF or PNG files. You are right: Using Clearwin+ the PNG files have perfect colors - GIF files are not as good, as well if you have just a few different colors.
The reason is the mode in Clearwin+: Export_Image@ uses with high probability a fixed color palette. When I make a screen copy with Ctrl+Print and create a GIF file in Photoshop, my colors in the file are perfect. Photoshop can use a flexible color palette.

Paul,

change request: Please allow a flexible color palette for GIF files in Export_Image@, because GIF files are for line graphics much smaller then PNG files.

Erwin
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+ All times are GMT + 1 Hour
Goto page Previous  1, 2, 3, 4  Next
Page 3 of 4

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group