forums.silverfrost.com

silicondale · Posted: Wed Feb 15, 2012 1:50 pm Post subject: DIB_BLOCK limits

I am trying to use the DIB_BLOCK subroutines to generate JPG files, but I seem to have encountered a size limitation. No problem with images up to 2048 x 2048 pixels, but larger than this, although I have (so far) found no limit in the vertical (Y) direction, anything beyond 2048 pixels in the X direction displays as black. So how do I generate a 4096 x 4096 image? Is the 2048 horizontal extent an absolute limitation of the CREATE_GRAPHICS_REGION@ function?

I'm using CLEAR_SCREEN_AREA@, GRAPHICS_WRITE_MODE@, and multiple calls to DRAW_LINE@, to generate the graphics, then RECOVER_DIB_BLOCK@ and PUT_DIB_BLOCK@ to write the JPEG file. I tried with a .BMP file but found exactly the same 2048 pixels limit in the x direction.
_________________
(Steve Henley)

PaulLaidler · Posted: Wed Feb 15, 2012 3:13 pm Post subject:

If you will put this into a short sample program, I will see if I can find any limitation within the library.

silicondale · Posted: Wed Feb 15, 2012 4:47 pm Post subject:

Hi, Paul -
Many thanks for the offer. I've extracted the following (fixed-format fortran) from my code and it shows the problem:

winapp 'resource.rc'
program testplot
use mswin
INTEGER WVM,HVM,VMHANDLE,FUNC,ICOLR
CHARACTER*1 PARRAY(3,4000,4000)
WVM = 4000
HVM = 4000
IOPEN = CREATE_GRAPHICS_REGION@( VMHANDLE,WVM,HVM )
ierr = select_graphics_object@(VMHANDLE)
call use_rgb_colours@ (VMHANDLE,1)
ICOLR = RGB@(255,255,255)
call draw_filled_rectangle@ (0,0,WVM,HVM,ICOLR)
ICOLR = RGB@(127,127,127)
call draw_filled_rectangle@ (500,500,3500,3500,ICOLR)
call graphics_write_mode@ (1)
ICOLR = RGB@(0,0,255)
call draw_line@ (200,200,200,3800,icolr)
call draw_line@ (200,3800,3800,3800,icolr)
call draw_line@ (3800,3800,3800,200,icolr)
call draw_line@ (3800,200,200,200,icolr)
ICOLR = RGB@(255,255,0)
call draw_line@ (3000,1000,1000,3000,icolr)
call draw_line@ (1000,1000,3000,3000,icolr)
ICOLR = RGB@(127,127,0)
call draw_filled_rectangle@ (1500,1500,2500,2500,ICOLR)
FUNC = 0
MODE = 0
IX = 0
IY = 0
call RECOVER_DIB_BLOCK@(IX,IY,PARRAY,WVM,HVM,IX,IY,WVM,HVM,
1 FUNC,MODE,IERCODE )
call PUT_DIB_BLOCK@( 'test.jpg',PARRAY,WVM,HVM,IX,
1 IY,WVM,HVM,NBPP,IERCODE )
stop
end

One odd thing I noticed - when compiling and linking this on its own it occupies 47 megabytes, yet when I use the same coding within a big and complex application the size is only 1.3 megabytes. The complex application has PARRAY etc in a common block - so would that explain the difference?
_________________
(Steve Henley)

JohnCampbell · Joined: 16 Feb 2006 Posts: 2554 Location: Sydney

I have also noted limits on the size of windows that can be used, but I thought it was greater than you have found.

An alternative approach that I use, not using DIB, is to dump the active window direct to file, using either:

silicondale · Posted: Thu Feb 16, 2012 9:16 am Post subject: Thanks - will try

Hi, John - Many thanks for these suggestions.

Everything has to be done as 'virtual' screens, not real graphics windows, because it's a web application so that all output must go to files, not to a physical screen. ASP coding in the webpage then spools the transcript file to the user in a dynamic webpage, and provides a link to the generated jpeg file.

Have tried the export_image route with jpeg format, still the same limit, 2048 pixels in the x direction. Also, even on highest JPG quality the image is much worse than going via the DIB_BLOCK route.

PCX and BMP images come out with the same 2048 pixels limit in the x direction. The files are both enormous (and exactly the same size), but BMP image quality is better.

Conclusion - the limit is nothing to do with how the graphics are exported, but seems to be an internal storage liimit.

Question... I am using F95 version 3.0 - is this possibly a known bug that may have been fixed in a later version? I'm not willing to try and install the free personal F95 over the licensed 3.0 - I've done this before and had problems getting back to the licensed version. However, if I can be assured that the problem is fixed in the latest version, then willing to buy an upgrade.

Another thought. Much (most) of what I am doing is conversion of old vector-plotting programs, with some filled rectangles, some text, but not a lot else, so perhaps the SVG format is more appropriate. Will experiment a little with this. Any ideas on a suitable (ideally free!) SVG library?
_________________
(Steve Henley)

PaulLaidler · Posted: Fri Feb 17, 2012 10:39 am Post subject:

There have been changes that could affect the result.

Try downloading the personal edition to a different machine and then copy salflibc,dll across (making sure to keep a copy of the old dll).

silicondale · Posted: Fri Feb 17, 2012 10:46 am Post subject: Will do

Hi, Paul - many thanks for the suggestion: will try this.

I have also experimented with SVG and that also seems to work, though it needs a bit more programming. Huge advantage that it's an XML format so can do the whole thing as simple writes to a file. However, the optimum will be to give users the choice of JPG or SVG formats.
_________________
(Steve Henley)

JohnCampbell · Joined: 16 Feb 2006 Posts: 2554 Location: Sydney

I have changed to using .gif files. They appear to offer advantages compared to .jpg, especially for scientific or vector images.
I did use .pcx, until it's support in windows reduced.
John

silicondale · Posted: Sat Feb 18, 2012 10:29 am Post subject: svg works

I have implemented an SVG solution which seems to work just fine. Neither PCX nor BMP is suitable for web applications. SVG has the huge advantage that being XML it can use ordinary Fortran writes. I started from the coding by Fabio Pietrucci (http://sites.google.com/site/fabiopietrucci/Home/downloads) which does all I need.

As for the JPG version, I tried the new version of salflibc.dll with the JPG coding and hit exactly the same limit. Wondering now whether this is actually a memory limit: my development machine is an old computer running Windows 2000 (nice and stable) but with just 512M memory. However, I haven't hit any memory limits elsewhere and would be a little surprised if it were constrained by such a limit without giving any error messages.

I shall now try GIF, but expect that it will have just the same problem (as with JPG, BMP, and PCX) because it seems not to be a function of the output format but the PARRAY graphics area itself.
_________________
(Steve Henley)

JohnCampbell · Joined: 16 Feb 2006 Posts: 2554 Location: Sydney

Steve,

I've updated your example so that different values of WVM (x_max) can be more easily tested. The example does confirm your problem and I did not find any problem with your code, except for my interpretation of the PARRAY offsets, which I am probably wrong.
I think you should provide a value of VMHANDLE.
As PARRAY is not being used in the code, I'd expect it can be dimensioned to anything large enough.
All error responses indicate success at each call.

silicondale · Posted: Sat Feb 18, 2012 4:44 pm Post subject:

Many thanks for the reworking, John. Will keep on chipping away at this one. I guess the next is to try the executables on computers with different memory sizes, though if you've tried it and reproduced the error that box is probably already ticked. By the way, not sure what you mean by PARRAY not being used in the code - I thought this was the array that actually held the graphics area data, and so is used by the DIB_BLOCK subroutines. Maybe I misunderstood.

By the way, the SVG version is now working smoothly, and neatly complements another program I have, which exports 3D data as VRML2format .wrl files.
_________________
(Steve Henley)

JohnCampbell · Joined: 16 Feb 2006 Posts: 2554 Location: Sydney

Steve,

When I said "As PARRAY is not being used in the code" I meant to say the dimension of PARRAY. It could also have been declared integer*4 PARRAY(12000000), which is about 48 mb, as it's dimensions are not being used.

Another thought is that clearwin+ imposes a drawing limit on the drawing surface. I can't recall the routine to change the drawing limit. Although we can select a drawing surface with X > 2048, there may be a limit on X to 2048 for drawing. I need to find this routine.

John

JohnCampbell · Joined: 16 Feb 2006 Posts: 2554 Location: Sydney

I tried a direct export of the graphics surface to a .gif file and it appears to work. This may be a good solution.
I also tested PARRAY for colours, indicating not being set when X > 2048
I think there is a problem with the dimension (X limit) of the DIB interface.
Try this alternative:

JohnCampbell · Joined: 16 Feb 2006 Posts: 2554 Location: Sydney

... The test routine (we need a better forum post limit)

silicondale · Posted: Sun Feb 19, 2012 9:42 am Post subject:

Thank you very much indeed for all this help, John! It never ceases to amaze me how helpful the Fortran community is.

I agree about the preference for GIF. A 256-colour palette is not a problem for me, as it's a considerable expansion on the 16 and 64 colour palettes that my 'legacy' applications have been limited to in the past.
_________________
(Steve Henley)