Why do people hate BMP files?

SDL Development
1

flame suit on

Why are some people so “anti-bmp”? Is it because the
format is simply “old”? Is it because of “Microsoft”?
Geez. It is just a file format.

What next; outlaw PCX and XPM?

Also, in which situations would someone care that
sdl_image increases by 100K (pure guess) to support
BMP RLE decompression and the extra file format save
options? I can see file size of a shared object
becoming an issue on an embedded system of floppy disk
system. In those cases, wouldn’t the developer have
pruned down all of the libraries by hand anyway?

On another note: I’ve been using “jasper” to do
jpeg2000 images. Jpeg2000s are much smaller than
regular jpegs and they look really nice. “jasper” is
a open source reference implementation.

http://www.ece.uvic.ca/~mdadams/jasper/

Anyway, jasper solves the “how do I pass options to
the compressor” problem by placing them into a
delimited string. You write something like this:

jas_image_encode(jp2_image, jas_stream, nFormat,
“rate=0.01,optionB=someValue”);

Maybe the “save” functions in sdl_image or
sdl_saveimage could take their specialized arguments
like that.

Also, my personal preference would be to place all
loading and saving functions into a single library.
In the cases where someone wants to statically link,
the linker will skip the unused functions. If the
developer uses a shared object or DLL, then they can
compile a custom DLL if they want it as small as
possible.

I think that having lots of small libraries that do
related things is troublesome. SDL_image is an
interface between SDL surfaces and various image
formats. Why split it into many pieces?

Does anyone propose that we have an SDL_image_bmp, an
SDL_image_jpeg, SDL_image_jpeg2000, SDL_image_xpm,
SDL_image_png, etc… ??? I would hope not.=====
Dennis Jenkins

2

— Dennis Jenkins <dennis.jenkins at sbcglobal.net>
wrote:

flame suit on

Why are some people so “anti-bmp”? Is it because
the
format is simply “old”? Is it because of
"Microsoft"?
Geez. It is just a file format.

Simple: there are better alternatives (read: smaller
sized files).__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail

3

Simple: there are better alternatives (read: smaller
sized files).

Yeah, better alternatives when you need smaller files. But loading
uncompressed files is faster (read: takes fewer cpu cycles). And if
there are better formats than BMP, why is it just BMP that’s being
dropped? If “there are better alternatives” is a reason to drop support
for formats, we end up with just PNG or so.

Now, am I the only one who thinks this just doesn’t seem right?

SDL has support for BMP. With the RLE BMP patch, SDL has support for
more BMP types. Tell me why that’s a bad thing, but leave these reasons
out:

  1. Library bloat

You can already compile SDL yourself with only parts you need. You can
drop aalib output. You can drop esd output. --disable-rle-bmp fits into
this scheme

  1. It’s Microsoft

I fail to see why this reason is a valid one. BMP specs are free, it’s
legal to have support for them. Supporting BMP doesn’t support Microsoft
per se. Supporting BMP doesn’t sell your soul to the devil of closed
source.

  1. There are better formats

Support for all possible file formats is a good thing. We can’t force
everyone to use format foo. There is no need. There are valid reasons to
choose BMP for a project. You can’t think of all of them and counter
them, someone will always figure out more reasons.

  1. RLE encoded BMP loading belongs to SDL_image

Why is that? If a user has a .bmp file, and SDL has SDL_LoadBMP(), why
can’t he combine them? What’s so special about certain types of BMP?–
Petri Latvala

4

I don’t feel there’s any reason not to have it natively supported.
Strictly speaking, BMP is the
easiest format to make images for and to code for (IMO). I don’t see it
as bloat for this reason. It
is, however, a large file format. Because of this, I choose not to use
it. For example, if Digital
Cameras did not support JPGs, your hard drive would fill up VERY fast
(not to mention you could
probably only take one or two pictures). I like PNG, myself, because it
has alpha channel support
builtin to the file format, and is small. Unfortunately alpha blitting
is not very fast with the current
SDL, but I thought I saw someone say that would change soon.

Petri Latvala wrote:>>Simple: there are better alternatives (read: smaller

sized files).

Yeah, better alternatives when you need smaller files. But loading
uncompressed files is faster (read: takes fewer cpu cycles). And if
there are better formats than BMP, why is it just BMP that’s being
dropped? If “there are better alternatives” is a reason to drop support
for formats, we end up with just PNG or so.

Now, am I the only one who thinks this just doesn’t seem right?

SDL has support for BMP. With the RLE BMP patch, SDL has support for
more BMP types. Tell me why that’s a bad thing, but leave these reasons
out:

  1. Library bloat

You can already compile SDL yourself with only parts you need. You can
drop aalib output. You can drop esd output. --disable-rle-bmp fits into
this scheme

  1. It’s Microsoft

I fail to see why this reason is a valid one. BMP specs are free, it’s
legal to have support for them. Supporting BMP doesn’t support Microsoft
per se. Supporting BMP doesn’t sell your soul to the devil of closed
source.

  1. There are better formats

Support for all possible file formats is a good thing. We can’t force
everyone to use format foo. There is no need. There are valid reasons to
choose BMP for a project. You can’t think of all of them and counter
them, someone will always figure out more reasons.

  1. RLE encoded BMP loading belongs to SDL_image

Why is that? If a user has a .bmp file, and SDL has SDL_LoadBMP(), why
can’t he combine them? What’s so special about certain types of BMP?

–
Petri Latvala

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

5

Personally, I like XPM because you could write the whole thing in ASCII,
but I’m funny like that. BMP is pretty easy to muck with to, and is
supported by everything, sooooo…
I guess some people are just religious about such small things.

$.02,
Jason.> ----- Original Message -----

From: sdl-bounces+jclark=ccpu.com@libsdl.org
[mailto:sdl-bounces+jclark=ccpu.com at libsdl.org] On Behalf Of Dennis
Jenkins
Sent: Wednesday, June 30, 2004 1:31 PM
To: SDL at libsdl.org
Subject: [SDL] Why do people hate BMP files?

flame suit on

Why are some people so “anti-bmp”? Is it because the
format is simply “old”? Is it because of “Microsoft”?
Geez. It is just a file format.

What next; outlaw PCX and XPM?

Also, in which situations would someone care that
sdl_image increases by 100K (pure guess) to support
BMP RLE decompression and the extra file format save
options? I can see file size of a shared object
becoming an issue on an embedded system of floppy disk
system. In those cases, wouldn’t the developer have
pruned down all of the libraries by hand anyway?

On another note: I’ve been using “jasper” to do
jpeg2000 images. Jpeg2000s are much smaller than
regular jpegs and they look really nice. “jasper” is
a open source reference implementation.

http://www.ece.uvic.ca/~mdadams/jasper/

Anyway, jasper solves the “how do I pass options to
the compressor” problem by placing them into a
delimited string. You write something like this:

jas_image_encode(jp2_image, jas_stream, nFormat,
“rate=0.01,optionB=someValue”);

Maybe the “save” functions in sdl_image or
sdl_saveimage could take their specialized arguments
like that.

Also, my personal preference would be to place all
loading and saving functions into a single library.
In the cases where someone wants to statically link,
the linker will skip the unused functions. If the
developer uses a shared object or DLL, then they can
compile a custom DLL if they want it as small as
possible.

I think that having lots of small libraries that do
related things is troublesome. SDL_image is an
interface between SDL surfaces and various image
formats. Why split it into many pieces?

Does anyone propose that we have an SDL_image_bmp, an
SDL_image_jpeg, SDL_image_jpeg2000, SDL_image_xpm,
SDL_image_png, etc… ??? I would hope not.

=====
Dennis Jenkins

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.708 / Virus Database: 464 - Release Date: 6/18/2004

Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.708 / Virus Database: 464 - Release Date: 6/18/2004

6

You could consider me anti-bmp, not because Microsoft made it. Because
its old and make HUGH files.

I understand the ease of it. The simmpletes to program and the easy to
create. Bmp though shows no advantages over some other formates, other
than there easier to program. I would rather to put in the extra time
to program them and make my bin. that much smaller…

Thats my though…

AndrewOn Wed, 30 Jun 2004 14:06:25 -0700, TomT64 wrote:

I don’t feel there’s any reason not to have it natively supported.
Strictly speaking, BMP is the
easiest format to make images for and to code for (IMO). I don’t see it
as bloat for this reason. It
is, however, a large file format. Because of this, I choose not to use
it. For example, if Digital
Cameras did not support JPGs, your hard drive would fill up VERY fast
(not to mention you could
probably only take one or two pictures). I like PNG, myself, because it
has alpha channel support
builtin to the file format, and is small. Unfortunately alpha blitting
is not very fast with the current
SDL, but I thought I saw someone say that would change soon.

Petri Latvala wrote:

Simple: there are better alternatives (read: smaller
sized files).

Yeah, better alternatives when you need smaller files. But loading
uncompressed files is faster (read: takes fewer cpu cycles). And if
there are better formats than BMP, why is it just BMP that’s being
dropped? If “there are better alternatives” is a reason to drop support
for formats, we end up with just PNG or so.

Now, am I the only one who thinks this just doesn’t seem right?

SDL has support for BMP. With the RLE BMP patch, SDL has support for
more BMP types. Tell me why that’s a bad thing, but leave these reasons
out:

  1. Library bloat

You can already compile SDL yourself with only parts you need. You can
drop aalib output. You can drop esd output. --disable-rle-bmp fits into
this scheme

  1. It’s Microsoft

I fail to see why this reason is a valid one. BMP specs are free, it’s
legal to have support for them. Supporting BMP doesn’t support Microsoft
per se. Supporting BMP doesn’t sell your soul to the devil of closed
source.

  1. There are better formats

Support for all possible file formats is a good thing. We can’t force
everyone to use format foo. There is no need. There are valid reasons to
choose BMP for a project. You can’t think of all of them and counter
them, someone will always figure out more reasons.

  1. RLE encoded BMP loading belongs to SDL_image

Why is that? If a user has a .bmp file, and SDL has SDL_LoadBMP(), why
can’t he combine them? What’s so special about certain types of BMP?

–
Petri Latvala

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

7
  1. It’s Microsoft

I fail to see why this reason is a valid one. BMP specs are free, it’s
legal to have support for them. Supporting BMP doesn’t support Microsoft
per se. Supporting BMP doesn’t sell your soul to the devil of closed
source.

In a sense it dose support Microsoft. If you chose to use BMP over a
different file format, you chose Microsoft over the others…

AndrewOn Wed, 30 Jun 2004 18:30:39 -0700, Andrew Balmos <@Andrew_Balmos> wrote:

You could consider me anti-bmp, not because Microsoft made it. Because
its old and make HUGH files.

I understand the ease of it. The simmpletes to program and the easy to
create. Bmp though shows no advantages over some other formates, other
than there easier to program. I would rather to put in the extra time
to program them and make my bin. that much smaller…

Thats my though…

Andrew

On Wed, 30 Jun 2004 14:06:25 -0700, TomT64 wrote:

I don’t feel there’s any reason not to have it natively supported.
Strictly speaking, BMP is the
easiest format to make images for and to code for (IMO). I don’t see it
as bloat for this reason. It
is, however, a large file format. Because of this, I choose not to use
it. For example, if Digital
Cameras did not support JPGs, your hard drive would fill up VERY fast
(not to mention you could
probably only take one or two pictures). I like PNG, myself, because it
has alpha channel support
builtin to the file format, and is small. Unfortunately alpha blitting
is not very fast with the current
SDL, but I thought I saw someone say that would change soon.

Petri Latvala wrote:

Simple: there are better alternatives (read: smaller
sized files).

Yeah, better alternatives when you need smaller files. But loading
uncompressed files is faster (read: takes fewer cpu cycles). And if
there are better formats than BMP, why is it just BMP that’s being
dropped? If “there are better alternatives” is a reason to drop support
for formats, we end up with just PNG or so.

Now, am I the only one who thinks this just doesn’t seem right?

SDL has support for BMP. With the RLE BMP patch, SDL has support for
more BMP types. Tell me why that’s a bad thing, but leave these reasons
out:

  1. Library bloat

You can already compile SDL yourself with only parts you need. You can
drop aalib output. You can drop esd output. --disable-rle-bmp fits into
this scheme

  1. It’s Microsoft

I fail to see why this reason is a valid one. BMP specs are free, it’s
legal to have support for them. Supporting BMP doesn’t support Microsoft
per se. Supporting BMP doesn’t sell your soul to the devil of closed
source.

  1. There are better formats

Support for all possible file formats is a good thing. We can’t force
everyone to use format foo. There is no need. There are valid reasons to
choose BMP for a project. You can’t think of all of them and counter
them, someone will always figure out more reasons.

  1. RLE encoded BMP loading belongs to SDL_image

Why is that? If a user has a .bmp file, and SDL has SDL_LoadBMP(), why
can’t he combine them? What’s so special about certain types of BMP?

–
Petri Latvala

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

8

I would rather to put in the extra time
to program them and make my bin. that much smaller…

Note the magical word “I” here. Someone could choose BMP over other
formats for various reasons. You on the other hand could just recompile
SDL to not have BMP loading code at all.

It’s the case of “We only support foobar because it’s the best, use
that” versus “We have support for any format you can think of”. Imagine
which one makes it easier for developers? And which one widens the
possible user base to the area of developers who have to choose BMP?–
Petri Latvala

9

In a sense it dose support Microsoft. If you chose to use BMP over a
different file format, you chose Microsoft over the others…

An application developer chooses BMP over others. SDL developers choose
BMP alongside other formats.

If we are to ban Microsoft’s format, let’s ban Windows backends as well.
After all, it’s choosing Microsoft alongside others.–
Petri Latvala

10

DAMN! We’re STILL arguing about this? Just put the damned RLE code in there,
and a compile-time option to disable it, to make sticklers happy, and be
done with it! Sheesh! :wink:

(Not directed specifically to you, Petri, but to everyone who’s been dragging
this thread on for the last day or two :^) )

-bill!On Thu, Jul 01, 2004 at 04:55:37AM +0300, Petri Latvala wrote:

It’s the case of “We only support foobar because it’s the best, use
that” versus “We have support for any format you can think of”. Imagine
which one makes it easier for developers? And which one widens the
possible user base to the area of developers who have to choose BMP?

11

If we are to ban Microsoft’s format, let’s ban Windows backends as well.
After all, it’s choosing Microsoft alongside others

I’m on that wagon, I choice Linux over Windows, I am using Windows
right now, but thats not normally, ever one could do out with closed
sourced applications. Open source covers its all and it works better,
there more people working on it…

AndrewOn Wed, 30 Jun 2004 19:13:16 -0700, Bill Kendrick wrote:

On Thu, Jul 01, 2004 at 04:55:37AM +0300, Petri Latvala wrote:

It’s the case of “We only support foobar because it’s the best, use
that” versus “We have support for any format you can think of”. Imagine
which one makes it easier for developers? And which one widens the
possible user base to the area of developers who have to choose BMP?

DAMN! We’re STILL arguing about this? Just put the damned RLE code in there,
and a compile-time option to disable it, to make sticklers happy, and be
done with it! Sheesh! :wink:

(Not directed specifically to you, Petri, but to everyone who’s been dragging
this thread on for the last day or two :^) )

-bill!

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

12

— Petri Latvala wrote:

Simple: there are better alternatives (read:
smaller
sized files).

Yeah, better alternatives when you need smaller
files. But loading
uncompressed files is faster (read: takes fewer cpu
cycles).

I’d actually think the extra time spent in disk access
would take much longer than a few more cpu cycles
spent decompressing. This is assuming of course a
decent cpu, and enough RAM to not cause program memory
to be swapped to/from disk…

And if
there are better formats than BMP, why is it just
BMP that’s being
dropped?

Dunno. Ask the people who want it dropped.

snips out the rest because he agrees with it

(Shoulda put a disclaimer… I’m pro-rle code
insertion myself…)__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail

13
  1. Library bloat
    This is actually a pretty important reason. This debate has already happened several times on the kernel mailing list, though, so I think it’s safe to just refer anyone interested in flaming about bloat and why it’s bad–even if you can disable it at compile-time–over there. Suffice it to say that although every individual particle of dirt on my car is minute, there are enough particles that my already not-so-impressive ride positively looks like a junk heap.
  1. It’s Microsoft
    Perhaps I’m a bit too practical, but I think that it shouldn’t matter if it’s from MS or not. Leaving my low, low opinion of the company out of this, it’s not such a bad format. It’s a very simple format, and in that it fills a niche.

The issue here is RLE-encoding. The positive attribute of the BMP is its simplicity. RLE is an attempt to make BMP something it isn’t. It destroys the only good thing about the format. If you want a compressed image, you have JPEG, PNG, and a host of other formats. If you want a simple binary format, there is nothing inherently wrong with a BMP; it’s raw pixel data with a header at the beginning.

So, while BMP files fill a need, RLE-encoded ones do not, and they complicate the main SDL library, which (and it would seem that this is a design issue, and an intelligent decision) has only very limited support for images. The fact that some BMPs are supported whereas some are not should not confuse anybody smart enough be writing code. The fact that it’s not already supported should indicate that there was a reason, and it wouldn’t appear to be the laziness or lack of time that accompanies a quick hack to just get it running.

Pete–

Check out the latest SMS services @ http://www.linuxmail.org
This allows you to send and receive SMS through your mailbox.

Powered by Outblaze

14

And if
there are better formats than BMP, why is it just
BMP that’s being
dropped?

Dunno. Ask the people who want it dropped.

BMP is dropped from my life, I never use and despise upon when its
used. I convert to a different file format when ever possible.

This is a subject that will never be argued upon, like the Microsoft -
Linux argument.

Choice your side and stay there, or move if you want, this post will
never go away because people will continue to fight. Let it be the way
you want, there are ways to complete remove BMP files from SDL or just
keep them.

I am done fighting though…

P.S. to answer your question, it will never be because there are
people that want it to stay, which keeps it there…On Wed, 30 Jun 2004 20:14:44 -0700 (PDT), Michael Rickert wrote:

— Petri Latvala wrote:

Simple: there are better alternatives (read:
smaller
sized files).

Yeah, better alternatives when you need smaller
files. But loading
uncompressed files is faster (read: takes fewer cpu
cycles).

I’d actually think the extra time spent in disk access
would take much longer than a few more cpu cycles
spent decompressing. This is assuming of course a
decent cpu, and enough RAM to not cause program memory
to be swapped to/from disk…

And if
there are better formats than BMP, why is it just
BMP that’s being
dropped?

Dunno. Ask the people who want it dropped.

snips out the rest because he agrees with it

(Shoulda put a disclaimer… I’m pro-rle code
insertion myself…)

Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!

http://promotions.yahoo.com/new_mail

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

15

i agree, i say bmp is good to support, rle bmp is no good myself.> ----- Original Message -----

From: pete_elmore@linuxmail.org (Pete Elmore)
To: "A list for developers using the SDL library. (includes SDL-announce)"

Sent: Wednesday, June 30, 2004 8:37 PM
Subject: Re: [SDL] Why do people hate BMP files?

  1. Library bloat
    This is actually a pretty important reason. This debate has already
    happened several times on the kernel mailing list, though, so I think it’s
    safe to just refer anyone interested in flaming about bloat and why it’s
    bad–even if you can disable it at compile-time–over there. Suffice it to
    say that although every individual particle of dirt on my car is minute,
    there are enough particles that my already not-so-impressive ride positively
    looks like a junk heap.
  1. It’s Microsoft
    Perhaps I’m a bit too practical, but I think that it shouldn’t matter if
    it’s from MS or not. Leaving my low, low opinion of the company out of
    this, it’s not such a bad format. It’s a very simple format, and in that it
    fills a niche.

The issue here is RLE-encoding. The positive attribute of the BMP is its
simplicity. RLE is an attempt to make BMP something it isn’t. It destroys
the only good thing about the format. If you want a compressed image, you
have JPEG, PNG, and a host of other formats. If you want a simple binary
format, there is nothing inherently wrong with a BMP; it’s raw pixel data
with a header at the beginning.

So, while BMP files fill a need, RLE-encoded ones do not, and they
complicate the main SDL library, which (and it would seem that this is a
design issue, and an intelligent decision) has only very limited support for
images. The fact that some BMPs are supported whereas some are not should
not confuse anybody smart enough be writing code. The fact that it’s not
already supported should indicate that there was a reason, and it wouldn’t
appear to be the laziness or lack of time that accompanies a quick hack to
just get it running.

Pete

Check out the latest SMS services @ http://www.linuxmail.org
This allows you to send and receive SMS through your mailbox.

Powered by Outblaze

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

16

On another note: I’ve been using “jasper” to do
jpeg2000 images. Jpeg2000s are much smaller than
regular jpegs and they look really nice. “jasper” is
a open source reference implementation.

http://www.ece.uvic.ca/~mdadams/jasper/

I hope that one makes it to SDL_Image. JPEG isn’t evil today, right?

17

Because bitmap is copy right from microsoft ® and we they dont like to
be illegal.On Thu, 2004-07-01 at 10:07, Gabriel Gambetta wrote:

On another note: I’ve been using “jasper” to do
jpeg2000 images. Jpeg2000s are much smaller than
regular jpegs and they look really nice. “jasper” is
a open source reference implementation.

http://www.ece.uvic.ca/~mdadams/jasper/

I hope that one makes it to SDL_Image. JPEG isn’t evil today, right?

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

18

Piero B. Contezini <piero lsc.com.br> writes:

Because bitmap is copy right from microsoft ® and we they dont like to
be illegal.

You may be wrong or right.
I think you are wrong…
But if you are right, why you, honest citizen, make use of SDL?
SDL implements LoadBitmap, and is “illegal” since the beginning.

Shhhhht… don’t tell Redmond.

19

Pete Elmore <pete_elmore linuxmail.org> writes:

It’s a very simple format, and in that it
fills a niche.
Agreed.

So, while BMP files fill a need, RLE-encoded ones do not, and they complicate
the main SDL library, which (and it would seem that this is a design issue, and
an intelligent decision) has only very limited support for images.

Also agreed, except that the algorithm is about 20 lines of code.
But, yes, that can be a slippery path.

20

Pierre G. Richard wrote:

Piero B. Contezini <piero lsc.com.br> writes:

Because bitmap is copy right from microsoft ® and we they dont like to

be illegal.

You may be wrong or right.
I think you are wrong…
But if you are right, why you, honest citizen, make use of SDL?
SDL implements LoadBitmap, and is “illegal” since the beginning.

Shhhhht… don’t tell Redmond.

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Keep in mind BMP’s are a waste of space
786486 Jul 1 09:36 kgb.bmp
291149 Jun 28 00:28 kgb.png

Same texture files just one is saved as a BMP and one is saved as a
PNG… If your distrubuting software full of BMP’s such as a Game…
You’ll waste alot of space on the end users system, which is certainly
not acceptable in our company and many others I know.

Thx
Varmint