DIB_BLOCK limits

I have noted Steve's request and will see if the task can be fitted in before the next release.

Wilfred,

My problem has not been reducing the number of colours displayed as a general problem, but modifying the colour pallete to include the 130 rgb colours that I use in the .gif colour table. .gif supports a set of 256 colours, which can be described as 24bit colours in a look-up table. The default set of colours provided does not support the distorted set of colours I use. I modify this set to suit my requirements. An associated aspect of the clearwin graphics display is that when writing text, pixels near the text change their rgb values. I don't know why, but I can end up with up to 900 different rgb colour values displayed on a screen. I have been testing ways of including some of these in the palette and removing others, while remaining at the 256 limit then supply this palette to the .gif write routine. I'm at the stage where my latest colour review attempt is the slowest part of the process, so I'm looking at an alternative/better approach to search for and change these other colours.

Thanks for your assistance with this, as I don't yet know where my final solution approach will be.

John

John,

you wrote 'An associated aspect of the clearwin graphics display is that when writing text, pixels near the text change their rgb values. I don't know why...'.

I think the funny colours at the fonts are a result from a font smoothing process which is standard in Windows. You can de-activate it in the system settings, performance > visual effects, then something like 'Smooth edges of screens fonts' (sorry, my system is in German, I don't know the exact English expression).

May be that de-activating the smoothing, the funny effect will be killed.

Regards - Wilfried

I think that Wilfried is right - this is a type of anti-aliasing to improve the readability of screen fonts. If you don't want this, and cannot find a setting to turn it off (or you have users whose machine settings you have no control over) then you may have to create and/or use a 'stick font' such as was used by plotters and which you can use to draw your text.

FTN77 with DBOS used to support vector stick fonts from the 'Hershey' collection.

I wrote routines to draw vectors from outlines of my own, including some Greek characters. I could dig the code out. I know it works with FTN95. However, the editor for new fonts was written to use a bizzare Dodo graphics system called GSX, so the chances of creating new fonts are about nil.

Eddie

Following on from Steve's request for more information about library routines for GIF images, here is a summary of what I have to date.

1. export_image@ is documented and exports from the current drawing surface to a GIF file.

2. import_image@ is documented and imports from an image file to the current drawing surface but does not currently handle GIF files and resources. I have now extended this routine so that it will display the first image of a GIF file or resource.

3. import_gif@ already exists but is not documented. It works like import_bmp@ and provides a DIB handle as in the documented example for import_bmp@ except that import_gif@ has the interface

   C_EXTERNAL IMPORT_GIF@ '__import_gif'(INSTRING,VAL,REF,REF) :INTEGER*4

where the first VAL is the integer number of the image in the file and the first REF is returned as the number of images in the file.

Based on comments in a post on 'Problem Displaying JPG File', I wrote some simple code to read a JPG file:

  program Flinders_video_data_jpg_read_v01

  include <windows.ins>

  character *1 ch_rsp

  character *180 flnm

  character, Allocatable :: ch_refl_P_L ( : , : , : )

  flnm = 'CH201201_062_060028_P_1358_PS.jpg'

  call GET_DIB_SIZE@ ( flnm, 
 1                     npxl, nlne,
 2                     nbpp, nerr )

  write ( 6, '(/ '' jpeg width, height, # bytes : '', 3i6 )' )
 1                  npxl, nlne, nbpp

  Allocate ( ch_refl_P_L ( 3, npxl, nlne ) )

  nzr = 0

  nerr = 0

  call GET_DIB_BLOCK@ ( flnm, ch_refl_P_L, 
 1                         npxl, nlne,
 2                         nzr, nzr,
 3                         npxl, nlne,
 4                         nzr, nzr, nerr )

The code returns 0s for npxl and nlne, and 24 for # bytes (the latter is correct). The actual values are 3168 L x 4752 P.

When I read the file into Photoshop and export it, the PS-exported file reads correctly.

Any suggestions?

Paul, can I email the file to you (~ 6 MB) so that you can find out why GET_DIB_SIZE is returning 0s?

Norm

Norm,

The two main advances that have occured with this thread is

1. the increase in size limit for DIB blocks to above 2048, and
2. the inclusion of .png formats to replace .gif

I am not sure at what version of FTN95 this occurred, as I had a look in cwplus.enh, but could not find it documented.

You should check which version of ftn95 you have as the error you are finding could be associated with the 2048 size limit.

John

PS: I have adapted the sample program I provided earlier and it failed for get_dib_size@ for a large .jpg file. The error mesaage was: 'Curly bracket/integer form is not available in this context' ?? I will email the test problem.

Thanks John

I'm in the process of upgrading to the latest version.

But it's interesting that the code runs fine on the Photoshop-exported version of the same file. This makes me think that it is something to do with the interaction with the internal file structure, and not necessarily the size per se.

Norm

I've now installed the very latest Fortran version, but the main problem persists.

The code now returns 4752 and 3168 for npxl and nlne (0 previously), and 24 for # bytes (these are correct).

However, it gives error code 2 when trying to read the actual byte values.

Paul, can I email the file to you (~ 6 MB) so that you can find out why GET_DIB_BLOCK is not reading the correct values?

Remember that the code runs when I use a Photoshop-exported version of the same file.

Norm

Paul

I've sent the file again.

Norm

ClearWin+ does not recognise the header of this jpg file.

If I open the file in Microsoft Paint and 'Save As' a different jpg file then the header is changed and is now recognised by ClearWin+.

If I allow the original header in ClearWin+ then this simply delays the failure till the data is processed.

So although the file is accepted as valid by Microsoft Paint, it does not have a form that can be processed by ClearWin+ at the moment.

In the longer term it may be possible to update the jpeg handling code in ClearWin+ using the same approach as the new code for png files. Hopefully this would fix the problem.

In the mean time it will be necessary to process files of this kind so that the header is accepted by ClearWin+.

Paul and Norm, I had the same problem a while ago for photos taken with a Konica Minolta camera. The solution was similar, but I used the batch processing facility of Irfanview to modify the files in bulk. Ian

Thanks Ian

That's good to know, as I have 400+ photos to run through the illumination-adjustment code that I've written.

I was going to hassle Paul about trying to get something done sooner rather than later, as I couldn't face loading in the images one-at-a-time, but now I'll use your solution.

Norm