Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2013-04

FCL-Image and OS/2 BMP support

7 messages · 3 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Graeme Geldenhuys

Hi,

Having had a quick look at the FPReadBMP.pp unit, the only BMP format FCL-Image supports is the Windows BMP format. I need to read OS/2 BMP files too.

Here is a very brief comparison between the two formats. Note that OS/2 Bitmaps can be larger, multiple images per file, different compression algorithms, different file headers etc.

OS/2 Bitmap:
http://www.fileformat.info/format/os2bmp/egff.htm

Windows Bitmap:
http://www.fileformat.info/format/bmp/egff.htm

I'm doing the work for fpGUI's DocView, but would like to share the code with FPC too. What would be the suggested way of doing this?

1) extend the existing FPReadBMP.pp unit. This could be messy.

2) create a whole new unit specific to OS/2 Bitmaps.

I would opt for (2). But that raises another problem, but probably not relevant to others here. If option (2) is used, your application can't simply assume a *.bmp can be read with FPReadBMP, it needs to check the file header first, then determine the correct unit & class to use to read the bitmap.

A shot in the dark.... Has anybody else created a Object Pascal unit they could share that can read OS/2 Bitmap files? I've got the basics down, but need lots of testing and debugging still.

Regards,
- Graeme -

fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/

Reply by email

Michael Van Canneyt
to Graeme Geldenhuys
Graeme Geldenhuys wrote 31 lines
Hi, Having had a quick look at the FPReadBMP.pp unit, the only BMP format FCL-Image supports is the Windows BMP format. I need to read OS/2 BMP files too. Here is a very brief comparison between the two formats. Note that OS/2 Bitmaps can be larger, multiple images per file, different compression algorithms, different file headers etc. OS/2 Bitmap: http://www.fileformat.info/format/os2bmp/egff.htm Windows Bitmap: http://www.fileformat.info/format/bmp/egff.htm I'm doing the work for fpGUI's DocView, but would like to share the code with FPC too. What would be the suggested way of doing this? 1) extend the existing FPReadBMP.pp unit. This could be messy. 2) create a whole new unit specific to OS/2 Bitmaps. I would opt for (2). But that raises another problem, but probably not relevant to others here. If option (2) is used, your application can't simply assume a *.bmp can be read with FPReadBMP, it needs to check the file header first, then determine the correct unit & class to use to read the bitmap.

That's why, unfortunately, I think 1) is better.

A second problem is the 'multiple images per file'.

You will need an image number when loading.
That will need a change in the reader or in TFPCustomImageHandler. (a property, default set to 0, so it reads the first image (zero based))

Michael.

Reply by email

Sven Barth
to Michael Van Canneyt
Michael Van Canneyt wrote 43 lines
On Fri, 5 Apr 2013, Graeme Geldenhuys wrote: > Hi, > > Having had a quick look at the FPReadBMP.pp unit, the only BMP format > FCL-Image supports is the Windows BMP format. I need to read OS/2 BMP > files too. > > > Here is a very brief comparison between the two formats. Note that OS/2 > Bitmaps can be larger, multiple images per file, different compression > algorithms, different file headers etc. > > OS/2 Bitmap: > http://www.fileformat.info/format/os2bmp/egff.htm > > Windows Bitmap: > http://www.fileformat.info/format/bmp/egff.htm > > > I'm doing the work for fpGUI's DocView, but would like to share the code > with FPC too. What would be the suggested way of doing this? > > 1) extend the existing FPReadBMP.pp unit. This could be messy. > > 2) create a whole new unit specific to OS/2 Bitmaps. > > > I would opt for (2). But that raises another problem, but probably not > relevant to others here. If option (2) is used, your application can't > simply assume a *.bmp can be read with FPReadBMP, it needs to check the > file header first, then determine the correct unit & class to use to > read the bitmap. That's why, unfortunately, I think 1) is better. A second problem is the 'multiple images per file'. You will need an image number when loading. That will need a change in the reader or in TFPCustomImageHandler. (a property, default set to 0, so it reads the first image (zero based))

With support for multiple images per file we could add *.ico support to fcl-image as well (currently this is implemented in the LCL). And this could also benefit *.gif :)

Regards,
Sven

Reply by email

Michael Van Canneyt
to Sven Barth
Sven Barth wrote 47 lines
Am 05.04.2013 12:07, schrieb Michael Van Canneyt: > > > On Fri, 5 Apr 2013, Graeme Geldenhuys wrote: > >> Hi, >> >> Having had a quick look at the FPReadBMP.pp unit, the only BMP format >> FCL-Image supports is the Windows BMP format. I need to read OS/2 BMP >> files too. >> >> >> Here is a very brief comparison between the two formats. Note that OS/2 >> Bitmaps can be larger, multiple images per file, different compression >> algorithms, different file headers etc. >> >> OS/2 Bitmap: >> http://www.fileformat.info/format/os2bmp/egff.htm >> >> Windows Bitmap: >> http://www.fileformat.info/format/bmp/egff.htm >> >> >> I'm doing the work for fpGUI's DocView, but would like to share the code >> with FPC too. What would be the suggested way of doing this? >> >> 1) extend the existing FPReadBMP.pp unit. This could be messy. >> >> 2) create a whole new unit specific to OS/2 Bitmaps. >> >> >> I would opt for (2). But that raises another problem, but probably not >> relevant to others here. If option (2) is used, your application can't >> simply assume a *.bmp can be read with FPReadBMP, it needs to check the >> file header first, then determine the correct unit & class to use to >> read the bitmap. > > That's why, unfortunately, I think 1) is better. > > A second problem is the 'multiple images per file'. > > You will need an image number when loading. That will need a change in the > reader or in TFPCustomImageHandler. > (a property, default set to 0, so it reads the first image (zero based)) With support for multiple images per file we could add *.ico support to fcl-image as well (currently this is implemented in the LCL). And this could also benefit *.gif :)

Well I alread had .gif in mind when proposing this, I didn't know about .ico. So much the better :-)

Michael.

Reply by email

Sven Barth
to Michael Van Canneyt
Michael Van Canneyt wrote 58 lines
On Fri, 5 Apr 2013, Sven Barth wrote: > Am 05.04.2013 12:07, schrieb Michael Van Canneyt: >> >> >> On Fri, 5 Apr 2013, Graeme Geldenhuys wrote: >> >>> Hi, >>> >>> Having had a quick look at the FPReadBMP.pp unit, the only BMP format >>> FCL-Image supports is the Windows BMP format. I need to read OS/2 BMP >>> files too. >>> >>> >>> Here is a very brief comparison between the two formats. Note that >>> OS/2 >>> Bitmaps can be larger, multiple images per file, different compression >>> algorithms, different file headers etc. >>> >>> OS/2 Bitmap: >>> http://www.fileformat.info/format/os2bmp/egff.htm >>> >>> Windows Bitmap: >>> http://www.fileformat.info/format/bmp/egff.htm >>> >>> >>> I'm doing the work for fpGUI's DocView, but would like to share the >>> code >>> with FPC too. What would be the suggested way of doing this? >>> >>> 1) extend the existing FPReadBMP.pp unit. This could be messy. >>> >>> 2) create a whole new unit specific to OS/2 Bitmaps. >>> >>> >>> I would opt for (2). But that raises another problem, but probably not >>> relevant to others here. If option (2) is used, your application can't >>> simply assume a *.bmp can be read with FPReadBMP, it needs to check >>> the >>> file header first, then determine the correct unit & class to use to >>> read the bitmap. >> >> That's why, unfortunately, I think 1) is better. >> >> A second problem is the 'multiple images per file'. >> >> You will need an image number when loading. That will need a change >> in the reader or in TFPCustomImageHandler. >> (a property, default set to 0, so it reads the first image (zero >> based)) > With support for multiple images per file we could add *.ico support > to fcl-image as well (currently this is implemented in the LCL). And > this could also benefit *.gif :) Well I alread had .gif in mind when proposing this, I didn't know about .ico.

It was rather a niche before Windows Vista, but since then multiscale icons are rather common and are also supported by Lazarus. [And in theory one could add (animated) *.cur support as well of which the only difference to *.ico is that there is a "hotpoint" declared somewhere...]

So much the better :-)

Indeed.

Regards,
Sven

Reply by email

Graeme Geldenhuys
to Sven Barth: It was rather a niche before Windows Vista, but since then multiscale icons are rather…
Sven Barth wrote
It was rather a niche before Windows Vista,

I used many apps where the .ico file had multiple sizes - back in the days of Win2k I believe.

but since then multiscale icons are rather common and are also supported by Lazarus.

Yeah, hence the huge 140Kb default project1.ico file in every Lazarus project - rather annoying, but luckily I don't really create LCL apps. ;-)

difference to *.ico is that there is a "hotpoint" declared somewhere...]

I'm reading up a bit more on OS/2 Bitmap - thank goodness I kept a very old "Real-World programming for OS/2" book around. :) There are 2 OS/2 Bitmap formats, and size variations... Icons, Pointers, Bitmaps, Bitmap Array, Color Pointer etc. All in one file format - that's IBM optimization for you. :)

I'm been playing with OS/2 Warp 4.5 in a VM too - damn that brought back good memories, and still features I miss in that OS that simply doesn't exist anywhere else (even in todays OSes). They should port the Workplace Shell to Linux or FreeBSD, and I'll switch in a heartbeat!

Regards,
- Graeme -

fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/

Reply by email