Hi!
I want to create a coloured overlay over a (geographical) map. I do have the map as a bitmap and I wrote a fpc program, creating informations for the map (ASCII file with coordinates and values for each point on the map). I don't have experience in manipulating bitmaps, yet. Does someone know a fpc-tool, to generate a new bitmap from that? Or another little "bitmap-manipulater-program" (freeware), that I can call? Thanks for help!

Hi!

Linux or Windoze?

When Linux, I will be very interested on how you did it. I am searching for _usable_ units since half a year or more, but find nothing. PasJpeg is possibly nice, but not usable (only Windoze) and I found no unit which acts a s wrapper for already existing C libraries. (And doing that from scratch is too much work for my purposes.)

Good luck... :-/

On Fri, 17 Oct 2003, Rudolf Harney wrote:

| Hi!
| I want to create a coloured overlay over a (geographical) map. I do have the map as a bitmap and I wrote a fpc program, creating informations for the map (ASCII file with coordinates and values for each point on the map). I don't have experience in manipulating bitmaps, yet. | Does someone know a fpc-tool, to generate a new bitmap from that? | Or another little "bitmap-manipulater-program" (freeware), that I can call? | Thanks for help!
|

mfg

Ing. Rainer Hantsch

Did you tried SDL (www.libsdl.org)?
I don't know if it's exactly what you want but it's cross platform and supports alpha blending.
Parsing the ascii coords. to make the bitmap overlay should be pretty easy.

ciao, Ivan

Hello Rudolf,

Did you check the 'fly' program? I've use it to create something like you want to do. It's stand-alone, but from pascal you can generate a series of simple instructions into a text file, the have 'fly' execute them.

According to my docs, the URL is http://martin.gleeson.com/fly/

Another possibility is to use the ImageMagick library you probably have installed on your machine. Using its 'convert' and other commands you can combine images, scale, apply effects, even draw on them. If on Unix, type 'man convert'.

John

Thanks Rainer and Ivan! I reply to both answers:

Rainer Hantsch wrote

Hi! Linux or Windoze?

both - but I have more pressure with the windows thing, right now!

...

When Linux, I will be very interested on how you did it. I am searching for _usable_ units since half a year or more, but find nothing.

I'll let You know, when I found s.th.!

Good luck... :-/

Thanks!!!

Ivan Montes wrote

Did you tried SDL (www.libsdl.org)?

I tried, after You wrote to me and installed a fpc version from http://www.grulic.org.ar/~dmoisset/sdl4fp/english.html
- but I got a windows error "sdl.dll" not found, when I tried the examples that were in the archive ... so I didn't try any further.

I don't know if it's exactly what you want but it's cross platform and supports alpha blending.

what's alpha blending?

Parsing the ascii coords. to make the bitmap overlay should be pretty easy.

pretty easy is, what I need ;) I'm sitting here nearly all day now, trying bitmap stuff!

ciao, Ivan

From: "Rudolf Harney"

that were in the archive ... so I didn't try any further.

>I don't know if it's exactly what you want but it's cross platform and >supports alpha blending. what's alpha blending? >Parsing the ascii coords. to make the bitmap overlay should be pretty

easy.

pretty easy is, what I need ;) I'm sitting here nearly all day now, trying

bitmap stuff!

The SDL is installed with most Linux distributions, however in Windows you need to download the library and put it somewhere on your path (c:/windows/system32 for example). The compiled library can be downloaded here http://www.libsdl.org/release/SDL-1.2.6-win32.zip

Alpha blending is when drawing and image on top of another it makes a translucent effect. You can see the "under" image thru the "top" image. It's like transparency on PhotoShop layers.

ciao, Ivan

There is a large amount of Delphi-related graphics stuff on Earl F. Glynn's website, but I don't know if there is anything that can be used with with Free Pascal:

http://efg2.com/Lab/Library/Delphi/Graphics/ImageProcessing.htm http://efg2.com/Lab/Library/ImageProcessing/index.html http://efg2.com/Lab/Library/Kylix/index.html

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com

Hi!

What I am really wondering about, is the following:

There exist a lot of ready made C-libraries for manipulating images, but there exists nothing which uses them. Most issues I could find in the past are more or less Windoze-related and do not even compile, not to talk about if they would I heared that there are some things available for DELPHI style programming, but this does only work with newest FPC versions which surely will not work on old Linux any more (i.e. SuSE 5.2), so they are in fact useless. (I like to use very old computers to give them a second life for minimalistic things, but this machines are too weak for fat new Linuxes...)

Also I am afraid that
a.) this new FPC classes (again) will not use this libraries but do all this data fiddleing together by themselves. :-/
b.) be therefore much more unstable because the self-knitted code has to be tested again, what is already finished with this C libraries.

I asked some time ago for a wrapper and got the laconic answer that I would only have to do a header translation and then do this and that... :-( Why is there nothing available which does at least the simpler things of that?

Mostly required will be those functions which reading/writing images from/to files and putting them somewhere unpacked into memory for further manipulation, but even this is not really available.

Would be nice to receive some information about where I could get a unit which works with FPC 1.0.4 (this one works with SuSE 5.2, too) and is NOT in Delphi Style.

But I am afraid that this will not happen. Shall I really change to "C"? Hope, not!

On Sat, 18 Oct 2003, Jeff Pohlmeyer wrote:

| There is a large amount of Delphi-related graphics stuff | on Earl F. Glynn's website, but I don't know if there is | anything that can be used with with Free Pascal: |
| http://efg2.com/Lab/Library/Delphi/Graphics/ImageProcessing.htm | http://efg2.com/Lab/Library/ImageProcessing/index.html | http://efg2.com/Lab/Library/Kylix/index.html
|
|
|
| __________________________________
| Do you Yahoo!?
| The New Yahoo! Shopping - with improved product search | http://shopping.yahoo.com
|
| _______________________________________________
| fpc-pascal maillist -
| http://lists.freepascal.org/mailman/listinfo/fpc-pascal |

mfg

Ing. Rainer Hantsch

(headers also need testing)

c.) keeps the dependancies down.

I asked some time ago for a wrapper and got the laconic answer that I would only have to do a header translation and then do this and that... :-( Why is there nothing available which does at least the simpler things of that?

Nobody submitted one yet.

We only have the tool that was used for the windows unit translation.

Mostly required will be those functions which reading/writing images from/to files and putting them somewhere unpacked into memory for further manipulation, but even this is not really available.

There is pasjpg, there is a libpng header, some bmp fiddling.

Would be nice to receive some information about where I could get a unit which works with FPC 1.0.4 (this one works with SuSE 5.2, too) and is NOT in Delphi Style.

Obtain the latest source archive of FPC, and grep on some picture formats. You'll have to do the retrofitting of those sources to 1.0.4 yourself, but that shouldn't be too hard.

Hi!

On Mon, 20 Oct 2003, Marco van de Voort wrote:
| > will not work on old Linux any more (i.e. SuSE 5.2), so they are in fact | > useless. (I like to use very old computers to give them a second life for | > minimalistic things, but this machines are too weak for fat new Linuxes...) | >
| > Also I am afraid that
| > a.) this new FPC classes (again) will not use this libraries but do all | > this data fiddleing together by themselves. :-/ | > b.) be therefore much more unstable because the self-knitted code has to | > be tested again, what is already finished with this C libraries. | (headers also need testing)
|
| c.) keeps the dependancies down.

Possibly you are right. But it helps nothing when dependences are kept such low that there exists only some trivial sub-sets but nothing useful. Wouldn't it be better to supply something basic which is working in poorest environments before doing something high sophisticated?

| > I asked some time ago for a wrapper and got the laconic answer that I | > would only have to do a header translation and then do this and that... | > :-( Why is there nothing available which does at least the simpler things | > of that?
|
| Nobody submitted one yet.

I see that, but I can't believe that! :-)

| We only have the tool that was used for the windows unit translation.

Wrong OS. I only develop for Linux.

| > Mostly required will be those functions which reading/writing images | > from/to files and putting them somewhere unpacked into memory for further | > manipulation, but even this is not really available. |
| There is pasjpg, there is a libpng header, some bmp fiddling.

Great. 'pasjpg' does not even compile on Linux. And as you already said: There is some **fiddleing**, but nothing of it is really useful. Some strength should be made here to build/extend the graphics unit (or add another unit, let's say "imagefile", which should allow and supply a standardized set of procedures/functions for both: Windoze and Linux. Nothing in OOP/CLASS style, only very basic functions which can also be used/embedded later within/into Delphi style classes, but they must work procedural, too.

BMP and PNG are very trivial and therefore possibly supported in some unreliable versions. But they are extremely uncommon. Most important is JPEG, TIFF, ... in all flavours. I am sure they are not supported directly, because there are so many minor variations and therefore it is very complicated. So why not offer interfaces which act as wrappers to standard libjpeg.so libtiff.so, .... instead? Most C programs interface with these libraries, so they should be relatively standard. Isn't it? So it would save a lot of work when a wrapper is made, instead of re-inventing not the wheel, but the complete car.

| > Would be nice to receive some information about where I could get a unit which | > works with FPC 1.0.4 (this one works with SuSE 5.2, too) and is NOT in Delphi | > Style.
|
| Obtain the latest source archive of FPC, and grep on some picture formats. | You'll have to do the retrofitting of those sources to 1.0.4 yourself, but | that shouldn't be too hard.

I decided to develop in Pascal at CP/M times, because this gave me the possibility to write programs without any need to do low-level things. At DOS this continued and allowed simple graphics, too. The logical next step would be that the same should be available on Linux, too, and there FPC is my "TurboPascal for Linux".

Some years ago I had the hope that FPC would become a 100% replacement for TP/BP for DOS/LINUX/..., where I could do basically the same on every platform without any code modification. But I still see that Linux is not very well supported in some parts, especially graphics. Why is there still no graph-unit available which does the same as TP.GRAPH /DOS? Is it really such complicated to make some code into the graph unit which opens one X11-Window and paints there as a DOS program paints on a VGA screen?
I hear the answers in advance: This will not be satisfying, this is causing dependices, ... -- Ok, but X11 is a standard on any graphical Unix. And there is still some option to possibly allow to choose between using X11 and some kind of svgalib for direct access to the graphics card. And it is even better to have *something* which runs pherhaps slow and/or does not support more than a minimalistic set of X11, than having *nothing* at all.

I do not want to start now with low-level things to be able to do simplest things which were absolutely no problem with TP/BP. It is hard enough to accept that even the graph unit is not existing to me, because it does not work on Linux, and I see that FPC goes more and more into a direction which does not make life very easy. Often it is enough to be able to switch into "graphics mode" and draw some trivial graphs. This was absolutely no problem with DOS and TP/BP, but it is impossible with Linux if you do not start with extreme lowlevel coding. -- Hope you understand what I mean.

mfg

Ing. Rainer Hantsch

We usually depend on extern initiatives. We can only choose to integrate it with the core distro, or refer to the contributed units page.

| We only have the tool that was used for the windows unit translation. Wrong OS. I only develop for Linux.

I for FreeBSD. Problem is that Unix headers are dirtier than Microsoft headers, they use more macro's, and an awfully large amount of conditional code. Michael succeed in a libc translation recently.

When you've made this, please add it to the contributed units page, and maintain it. Preferably support multiple OSes.

The core team is chronically short on manpower, and has no time for an active role in this kind of sideways related stuff if we want to release 2.0 this decade.

TIFF, ... in all flavours. I am sure they are not supported directly, because there are so many minor variations and therefore it is very complicated. So why not offer interfaces which act as wrappers to standard libjpeg.so libtiff.so, .... instead?

We didn't get them submitted.

Most C programs interface with these libraries, so they should be relatively standard. Isn't it? So it would save a lot of work when a wrapper is made, instead of re-inventing not the wheel, but the complete car.

The "reinventing the wheel" phrase is the most overused phrase in IT, please don't fall for that trap.

In the real world, taking a new part is easier than fixing the old. Why would it be different in IT ? :-)

It is. There are some things lacking (personally I would like to see the textmode IDE get a new maintainer and see it make fundamental progress), but all are manpower related.

It is not that we don't know these things. However we have to make choices, and that means that some things will end up at the bottom line of a A0 format to-do list. We make these choices based on 7 years day-in day-out experience with the project AND our own needs.

Some years ago I had the hope that FPC would become a 100% replacement for TP/BP for DOS/LINUX/..., where I could do basically the same on every platform without any code modification. But I still see that Linux is not very well supported in some parts, especially graphics.

Like everywhere, most users (and so contributions) focus on the GUI. Lazarus is quite far on *nix.

Why is there still no graph-unit available which does the same as TP.GRAPH /DOS?

A combination of being not directly needed for the core system and not getting external submissions.

Is it really such complicated to make some code into the graph unit which opens one X11-Window and paints there as a DOS program paints on a VGA screen?

I don't know, but I think using a widget set (GTK) would be easier. Trying it yourself is the easiest way of answering this.

I hear the answers in advance: This will not be satisfying, this is causing dependices, ... -- Ok, but X11 is a standard on any graphical Unix.

Yes, but "graph" is a console program. OTOH win32 also uses the GUI subsystem for graph. So I guess the lack of submissions remains as cause again.

And there is still some option to possibly allow to choose between using X11 and some kind of svgalib for direct access to the graphics card.

There is no problem if we had a unit as you described. I don't have a fundamental grudge about a X11 dependancy.

Except maybe that I'd reserve the "unit graph" unitname for the most compatible and generic one. But there is no such choise to make since we don't have multiple TP compatible Linux graph units.

The problem is that FPC is mainly driven by a couple core developpers, and an crowd of 10-30 people that regularly submit bugs, units and/or made and maintain FPC packages on the contributed units page. (which I always call the "outer core" by myself). And of course there is lazarus.

We don't have fulltime employees like some linux distributions and projects, and no thousands of submitters like the larger volunteer driven Open Source projects. This is not a FPC problem. All middlesize projects suffer from this. (too little people with long term commitments)

The core's schedule is pretty full, they are all volunteers, so they work on what they need themselves, or what they see as really hard needed improvements. If you want to see what happened to the core system after 1.0, see http://www.freepascal.org/future.html

For the rest we rely on external submissions, which are (except from that wellknown longterm bug and code submitting "outer core", most of which are regulars on this list) low to very low.

If you want change, a constructive way would be to create it and submit it.

I succeed to compile pasjpeg with -dWindows compiler option in Linux and few changes in sources :)

Pavel Kanzelsberger

On the packages\extra folder from a recent cvs copy of fpc 1.1 branch, I've found several interfaces to *nix graphic libraries: GGI, imlib, libGd, libPng.
LibGd (http://www.boutell.com/gd/) seems to be what you're looking for.

ciao, Ivan

Hi Marco!

There is pasjpg, there is a libpng header, some bmp fiddling.

... You wrote to Rainer ... Did You / someone get pasjpeg to work? I tried (from http://www.nomssi.de/pasjpeg/pasjpeg.html
) but with fpc 1.0.10 on win2000 I couldn't even run the demo. Or does someone know a fpc-working glib / unit, that can load a bitmap, edit a few points and save it again?

( The output from pasjpeg demo.pas:
jerror.pas(116,49) Warning: Procedure type FAR ignored
jerror.pas(295,53) Warning: Procedure type FAR ignored
jerror.pas(319,68) Warning: Procedure type FAR ignored
jerror.pas(351,74) Warning: Procedure type FAR ignored
jerror.pas(418,54) Warning: Procedure type FAR ignored
jerror.pas(438,31) Error: Wrong amount of parameters specified
jerror.pas(439,35) Error: Wrong amount of parameters specified
jerror.pas(440,39) Error: Wrong amount of parameters specified
jerror.pas(441,39) Error: Wrong amount of parameters specified
jerror.pas(442,41) Error: Wrong amount of parameters specified
jerror.pas(461) Fatal: There were 5 errors compiling module, stopping
)
Thanks, RUDOLF

There are some procedures assigned, find the lines with "Wrong amount of parameters" and change them to as follows:

something:=something;

change to

;

regards, Pavel Kanzelsberger

Or use -Sd or -So.

I tried pasjpg11 and it compiled fine with one of these parameters with 1.0.10.

On FreeBSD (Unix) I also had to add -Sg, but that could be my setup file. (FPC 1.1)

Hi!

So what is the actual status for handling images *now*?

* How do I load a JPEG image into memory (uncompressed, of course, and in a usable format, i.e. separated into RGB layers or CMYK layers)?

* How do I write a JPEG back to a file (with a selectable compression)?

I do not talk about displaying, I only talk about moving images between file and memory in a reliable and EASY way.

This is basically all I am searching for since a lot of months. But this must work with FPC 1.0.4, too, because this is the last one which runs out of the box on old SuSE 5.2 systems.

A compiling and working code sample would be great.

On Mon, 20 Oct 2003, Pavel Kanzelsberger wrote:
| I succeed to compile pasjpeg with -dWindows compiler option in Linux and | few changes in sources :)
|
| Pavel Kanzelsberger

mfg

Ing. Rainer Hantsch