Prev: User Defined Data Type --- Please HELP!!!!
Next: Multiple icons in exe
From: Mike Williams on 23 Nov 2007 06:57
On 23 Nov, 09:03, not.t...(a)address.spam.no (beginner) wrote:

> That page, however, [the VBAccelerator page]
> talks about the colour reduction algorithms
> and show a picture with lossless compression,
> which seems to imply that they are doing
> something more than just replace a pixel
> colour with a simpler colour.

You keep swapping about from one thing to another. Of course it is
possible to have lossless compression of an image, or of any other
data for that matter, but colour reduction algorithms (for example
converting a 24 bit Windows bmp file to a 4 bit Windows bmp file,
which is what you have asked for) are not generally lossless, not
unless the number of unique colours in the original 24 bit image is
less than or equal to 16, which is highly unlikely in most images.
Clever colour reduction algorithms can minimise the loss so that it
looks okay to the naked eye, especially if you are going down from 24
bit to 16 bit for example (which isn't really worth doing of course),
but no algorithm in the world can create a lossless standard 4 bit
Windows bmp file from a full colour Windows bmp file without losing
colour information unless the number of unique colours in the original
is 16 or less. It simply is not possible! At the moment you have asked
for an output that is a standard Windows 16 colour (4 bit) bmp file,
and I have told you something about how to perform that task and I
have also offered you some other alternative options (metafiles, for
example), none of which you have so far taken me up on, and there are
further options that I have not yet told you about (lossless
compression of 256 colour images into the Gif format, for example).
But so far the only thing you have specifically asked for is
conversion from a standard Windows 24 bit bmp file to a standard 4 bit
Windows bmp file. If you want something else then you need to ask for
something else! But you need to remember that your current requirement
of doing everything in standard VB code that you are able to fully
understand yourself and doing it without using any Windows API
functions and without using any external controls or even any code
that you can download from sites like VBAccelerator is going to
severely limit your choices!

> OK. There are several things I am trying
> to do, but none of them are with any rigid
> priorities which is why my standpoint
> varies with time. I am interested in the
> "better way" also. From all this discussion,
> it looks like SendKeys is not a good thing
> to learn or use, so I can forget about it,
> and may be learn some alternatives.

Right. Now we're getting somewhere.

> OK. Are there better ways of running
> other programs from VB?

Running them is easy, but I take it that you really mean controlling
them. If that's what you mean then you should only consider programs
which expose methods that can be accessed by VB (things like Microsoft
Word or Excel and lots of other Microsoft and non Microsoft
applications), but that's an entire "whole book" subject in its own
right and at your current stage you appear to have lots of other
things to learn before you take a walk down that road. I don't
normally get into that aspect of programming myself, but I would
suggest that controlling applications by sending them keystrokes to
access menu items should be seen as a last resort.

> I don't have problems learning new things,
> and APIs seem a bit advanced but I can
> learn that as well. I actually read up
> about metafiles yesterday, and it seems
> to be good.

Yes. They are very good. And of course I would be prepared to tell you
all about them and all about how to create them if you wish, but some
of the API functions required to do so are quite complex and I really
think you should dip your toe into the API pool on some easier stuff
first.

> I have no deadlines and nothing is waiting
> because I am not able to reduce bmp files,
> so I can comfortably learn at my own pace.
> It would be good to tell me of some Internet
> sites where I can read up, and some keywords
> I should understand.

There probably are some good sites around that might explain how to
perform your current task, although I don't know of any offhand. One
site that has the details of most file formats is http://www.wotsit.org
where you'll find the bmp file format and lots of others. At first
sight the bmp format might look complicated to you because it is
capable of storing all sorts of different kinds of bmp, but the format
of standard Windows 24 bit and 4 bit bmp files is very simple in both
cases and very easy to understand so you shouldn't have any trouble
with them. Also, in your own specific case where your original full
colour bmp contains no more than 16 unique colours, it will be very
easy to convert to a 4 bit bmp file with no loss of colour and no loss
of detail whatsoever, completely lossless as far as the resultant
image is concerned. I'll post an explanation of the two file formats
and how to go about converting from one to the other probably later
today or this evening. Also, in any code I post I will stick purely to
standard VB methods, using no API or other functions at all. Then
later, once you have understood that, you can use it as a "tool" with
which to step into the API pool you will not only start learning how
to use the API functions but will also realise just how powerful even
the simplest of them can be when you see just how much speed
improvement it gives to the project.

> The thing I am aiming at is learning while
> also doing something that could be useful
> to me. I don't need to avoid APIs if they
> are worthwhile, but a lot of people seem
> to use API even when the same thing can
> be done in a couple of lines in VB less
> efficiently. For me, simplicity of the
> code will take preference until I am a more
> advanced beginner.

That's fine. But after you have learned how to convert your 24 bit bmp
into a 4 bit bmp using only native VB methods (which will be over the
next day or two and by which time you will have learned quite a lot)
you will be totally amazed at how much faster you can make the code
run by adding just a few API calls. Not just a little bit faster. In
this specific case I'm talking about possibly hundreds of times
faster!

> Yes, I would like to store pictures in
> relatively small space (not as much bmp
> or tiff consumes).

As with most things, it's "horses for courses". If you're talking
about typical photographs then jpg is definitely the way to go. It is
of course a "lossy" format, but it is possible to choose the amount of
compression you use (and therefore the amount of "loss of detail" you
end up with), trading file size for quality. Normal photos look really
excellent as jpg images when the compression is such that they are
perhaps eight or ten times smaller than their bmp equivalents, and of
course you can make them very much smaller still if you are prepared
to accept slightly lower quality.

> The pictures are typically technical
> material - plots or schematic diagrams

In that case a metafile is the best choice. Metafiles of such drawings
are extremely small and they can contain as many colours as you wish,
all with total accuracy. Furthermore, when a metafile is displayed or
printed it takes full advantage of the resolution of the device on
which you are displaying or printing it, which gives absolutely
excellent results on the printed page for example. But, as I said
earlier, you might be better leaving metafiles until you've finished
your bitmap code.

> There is no hurry, and please do not write
> the code for me. That is not a good way to
> teach someone. Tell me instead the commands
> I should read up about, or the APIs I should
> read up about . . .

Okay. But for the time being forget all about the APIs. Do it first
using standard VB stuff and in that way you will learn the full
details about the file formats you are using. Firstly, download a MS
Word document describing the bmp file format from:

http://www.wotsit.org/download.asp?f=bmpfrmat&sc=249109959

.. . . and have a look at it. Then check out the following UDT which
I've created and which shows the header data of a 4 bit bmp file in a
way that should be simpler to see, because it is specifically for just
that one file format (4 bit bmp). I assume that you're aware of Visual
Basic UDTs (User Defined Types) and that you have used them in your
programs before. If not then this is the time to start looking at
them, because you'll use them all over the place. There are some
commonly used standard "Types" for parts of the full bmp file header
and it is common practice to "string the required sub types together"
into one larger type to form the complete header. However, I thought
it might be simpler (at least at first) to show you the entire header
UDT in "one go" which is specifically set up as the header for a
standard Windows 4 bit bmp file. So, you won't actually see this
particular UDT in precisely this way on the web or in the help files.
Anyway, have a look at it and study it *after* you have studied the MS
Word document that you download from the link. The UDT is actually
easier to understand when you see the code that goes with it, but I'll
leave that for the time being until you tell me you are ready. Here's
the UDT:

Private Type BmpHeader4Bit
bfType As String * 2
bfSize As Long '
bfReserved1 As Integer
bfReserved2 As Integer
bfOffBits As Long
biSize As Long
biWidth As Long
biHeight As Long
biPlanes As Integer
biBitCount As Integer
biCompression As Long
biDataSize As Long
biXPelsPerMeter As Long
biYPelsPerMeter As Long
biClrUsed As Long
biClrImportant As Long
palette(0 To 15) As Long
End Type

An actual 4 bit bmp file on disk is simply the above block of data (a
total of exactly 118 bytes with the appropriate entries containing the
correct values to specify the size, type, etc of the bitmap) and with
that 118 byte block of data immediately followed by sufficient data
bytes to contain the actual pixel data. The pixel data contains one
byte for every two pixels in the bitmap, with the hi nibble containing
the colour information for one pixel and the lo nibble containing the
colour information for the other pixel. The contents of each nibble (4
bits) can, as I'm sure you'll be aware, hold a value in the range 0 to
15. The actual value it holds acts as a "pointer" to an entry in the
palette (see palette(o to 15) in the above UDT). Each of those palette
entries is a Long, as you will see in the UDT, and so each can hold a
full 32 bit value. Only 24 of those bits are of interest in standard
bmps, with the other 8 bits being ignored except in special cases. In
other words, you can have any specific colours you like in your 4 bit
bmp file, as long as there are no more than sixteen of them. There are
two other things worthy of note, and they are:

1. The pixel data for each "scan line" (each horizontal line in the
bitmap) must be an exact multiple of four bytes, with the data in any
"unused nibbles at the end of the scan line data" being ignored. For
example, if a 4 bit bitmap is 400 pixels wide then each "scan line" of
data will contain 200 bytes (because 200 is enough to hold the data
and it is also an exact multiple of 4). However, If the bitmap is 393
bytes wide then the data would require 393/2 = 196.5 bytes. The value
196.5 is of course not an exact multiple of 4 and so you need to
"round up" the number of bytes to the next highest exact multiple of
4, which is 200. So the 393 pixel wide bitmap requires exactly the
same number of data bytes per horizontal scan line as does the 400
pixel bitmap.

2. The data in the bmp file is in "top to bottom" order, so the first
part of the data (the first scan line data) represents the bottom line
of the bitmap and the next scan line data represent the next scanline
up, and so on until youi reach the top of the bitmap.

Phew! That's a lot of stuff! Time for a coffe and some eggs and bacon
now, for sure ;-)

By the way, forgive any "typos" in this post. There are bound to be a
few the way I've been bashing these keys!

Mike


From: Mike Williams on 23 Nov 2007 09:00
On 23 Nov, 09:03, not.t...(a)address.spam.no (beginner) wrote:

> Tell me instead the commands I should
> read up about, or the APIs I should
> read up about, and I will try . . .

By the way, the second link in my last response is coming up with a
"bad link" message on the site, so instead of using it just go
straight to http://www.wotsit.org and look for the BMP format and
download the document called "Windows BMP Format (MS Word)".


Mike


From: beginner on 1 Dec 2007 12:57
In article <5ca9d5ed-9852-4d74-bdf0-048b8a1b4956(a)e4g2000hsg.googlegroups.com>,
Mike Williams <gagamomo(a)yahoo.co.uk> wrote:
>On 23 Nov, 09:03, not.t...(a)address.spam.no (beginner) wrote:
>
>> That page, however, [the VBAccelerator page]
>> talks about the colour reduction algorithms
>> and show a picture with lossless compression,
>> which seems to imply that they are doing
>> something more than just replace a pixel
>> colour with a simpler colour.
>
You keep swapping about from one thing to another. Of course it is
>possible to have lossless compression of an image, or of any other
>data for that matter, but colour reduction algorithms (for example
>converting a 24 bit Windows bmp file to a 4 bit Windows bmp file,
>which is what you have asked for) are not generally lossless, not
>unless the number of unique colours in the original 24 bit image is
>less than or equal to 16, which is highly unlikely in most images.
>Clever colour reduction algorithms can minimise the loss so that it

This is precisely what I don't like. Microsoft's software also wants
to do a lot of things which one does not need, but wants to do a lot
of good to us. I would prefer a simpler algorithm which can lose
colour information but not sharpness for my purposes. But, now this is
besides the point. See the lower part of this message.

looks okay to the naked eye, especially if you are going down from 24
>bit to 16 bit for example (which isn't really worth doing of course),
>but no algorithm in the world can create a lossless standard 4 bit
>Windows bmp file from a full colour Windows bmp file without losing
>colour information unless the number of unique colours in the original
>is 16 or less. It simply is not possible! At the moment you have asked
>for an output that is a standard Windows 16 colour (4 bit) bmp file,
>and I have told you something about how to perform that task and I
>have also offered you some other alternative options (metafiles, for
>example), none of which you have so far taken me up on, and there are
>further options that I have not yet told you about (lossless
>compression of 256 colour images into the Gif format, for example).
>But so far the only thing you have specifically asked for is
>conversion from a standard Windows 24 bit bmp file to a standard 4 bit
>Windows bmp file. If you want something else then you need to ask for
>something else! But you need to remember that your current requirement
>of doing everything in standard VB code that you are able to fully
>understand yourself and doing it without using any Windows API
>functions and without using any external controls or even any code
>that you can download from sites like VBAccelerator is going to
>severely limit your choices!

I think I have not made my objectives very clear.

>
>> OK. There are several things I am trying
>> to do, but none of them are with any rigid
>> priorities which is why my standpoint
>> varies with time. I am interested in the
>> "better way" also. From all this discussion,
>> it looks like SendKeys is not a good thing
>> to learn or use, so I can forget about it,
>> and may be learn some alternatives.
>
>Right. Now we're getting somewhere.
>
>> OK. Are there better ways of running
>> other programs from VB?
>
>Running them is easy, but I take it that you really mean controlling
>them.

Yes.

If that's what you mean then you should only consider programs
>which expose methods that can be accessed by VB (things like Microsoft
>Word or Excel and lots of other Microsoft and non Microsoft
>applications), but that's an entire "whole book" subject in its own
>right and at your current stage you appear to have lots of other
>things to learn before you take a walk down that road. I don't
>normally get into that aspect of programming myself, but I would
>suggest that controlling applications by sending them keystrokes to
>access menu items should be seen as a last resort.

OK.

I don't have problems learning new things,
>> and APIs seem a bit advanced but I can
>> learn that as well. I actually read up
>> about metafiles yesterday, and it seems
>> to be good.
>
>Yes. They are very good. And of course I would be prepared to tell you
>all about them and all about how to create them if you wish, but some
>of the API functions required to do so are quite complex and I really
>think you should dip your toe into the API pool on some easier stuff
>first.

I have read up some basics.

>
>> I have no deadlines and nothing is waiting
>> because I am not able to reduce bmp files,
>> so I can comfortably learn at my own pace.
>> It would be good to tell me of some Internet
>> sites where I can read up, and some keywords
>> I should understand.
>

There probably are some good sites around that might explain how to
>perform your current task, although I don't know of any offhand. One
>site that has the details of most file formats is http://www.wotsit.org
>where you'll find the bmp file format and lots of others. At first
>sight the bmp format might look complicated to you because it is

I knew roughly what is in graphics file formats, but read through the
bmp and .emf/.wmf again, so I have a fair idea.


capable of storing all sorts of different kinds of bmp, but the format
>of standard Windows 24 bit and 4 bit bmp files is very simple in both
>cases and very easy to understand so you shouldn't have any trouble
>with them. Also, in your own specific case where your original full
>colour bmp contains no more than 16 unique colours, it will be very
>easy to convert to a 4 bit bmp file with no loss of colour and no loss
>of detail whatsoever, completely lossless as far as the resultant
>image is concerned. I'll post an explanation of the two file formats
>and how to go about converting from one to the other probably later
>today or this evening. Also, in any code I post I will stick purely to
>standard VB methods, using no API or other functions at all.

That would be good. People here tend to overestimate all problems and
recommend using something much more complicated and idiot proof than is
necessary for simple purposes.

Then
>later, once you have understood that, you can use it as a "tool" with
>which to step into the API pool you will not only start learning how
>to use the API functions but will also realise just how powerful even
>the simplest of them can be when you see just how much speed
>improvement it gives to the project.

OK.

>
>> The thing I am aiming at is learning while
>> also doing something that could be useful
>> to me. I don't need to avoid APIs if they
>> are worthwhile, but a lot of people seem
>> to use API even when the same thing can
>> be done in a couple of lines in VB less
>> efficiently. For me, simplicity of the
>> code will take preference until I am a more
>> advanced beginner.
>
>That's fine. But after you have learned how to convert your 24 bit bmp
>into a 4 bit bmp using only native VB methods (which will be over the
>next day or two and by which time you will have learned quite a lot)
>you will be totally amazed at how much faster you can make the code
>run by adding just a few API calls. Not just a little bit faster. In
>this specific case I'm talking about possibly hundreds of times
>faster!

Then speed could be an issue. Otherwise, simplicity of the code takes
preference for me over its efficiency and speed.

>
>> Yes, I would like to store pictures in
>> relatively small space (not as much bmp
>> or tiff consumes).
>
>As with most things, it's "horses for courses". If you're talking
>about typical photographs then jpg is definitely the way to go. It is
>of course a "lossy" format, but it is possible to choose the amount of
>compression you use (and therefore the amount of "loss of detail" you
>end up with), trading file size for quality. Normal photos look really
>excellent as jpg images when the compression is such that they are
>perhaps eight or ten times smaller than their bmp equivalents, and of
>course you can make them very much smaller still if you are prepared
>to accept slightly lower quality.

Yes, my intention is to use it for simple technical material.

>
>> The pictures are typically technical
>> material - plots or schematic diagrams
>
>In that case a metafile is the best choice. Metafiles of such drawings
>are extremely small and they can contain as many colours as you wish,
>all with total accuracy. Furthermore, when a metafile is displayed or
>printed it takes full advantage of the resolution of the device on
>which you are displaying or printing it, which gives absolutely
>excellent results on the printed page for example. But, as I said
>earlier, you might be better leaving metafiles until you've finished
>your bitmap code.

I read up the formats of *.bmp as well as .emf and .wmf. At one time,
I had written raw PostScript to plot simple graphs, so I am also
slightly familiar with the kind of algorithms which might be necessary
to write *.emf.

>
>> There is no hurry, and please do not write
>> the code for me. That is not a good way to
>> teach someone. Tell me instead the commands
>> I should read up about, or the APIs I should
>> read up about . . .
>
>Okay. But for the time being forget all about the APIs. Do it first
>using standard VB stuff and in that way you will learn the full
>details about the file formats you are using. Firstly, download a MS
>Word document describing the bmp file format from:
>
>http://www.wotsit.org/download.asp?f=bmpfrmat&sc=249109959
>
>. . . and have a look at it. Then check out the following UDT which
>I've created and which shows the header data of a 4 bit bmp file in a
>way that should be simpler to see, because it is specifically for just
>that one file format (4 bit bmp). I assume that you're aware of Visual
>Basic UDTs (User Defined Types) and that you have used them in your
>programs before. If not then this is the time to start looking at
>them, because you'll use them all over the place. There are some

I knew about UDTs but never used them. Now I can see a good utility of
it.

>commonly used standard "Types" for parts of the full bmp file header
>and it is common practice to "string the required sub types together"
>into one larger type to form the complete header. However, I thought
>it might be simpler (at least at first) to show you the entire header
>UDT in "one go" which is specifically set up as the header for a
>standard Windows 4 bit bmp file. So, you won't actually see this
>particular UDT in precisely this way on the web or in the help files.
>Anyway, have a look at it and study it *after* you have studied the MS
>Word document that you download from the link. The UDT is actually
>easier to understand when you see the code that goes with it, but I'll
>leave that for the time being until you tell me you are ready. Here's
>the UDT:
>
>Private Type BmpHeader4Bit
> bfType As String * 2
> bfSize As Long '
> bfReserved1 As Integer
> bfReserved2 As Integer
> bfOffBits As Long
> biSize As Long
> biWidth As Long
> biHeight As Long
> biPlanes As Integer
> biBitCount As Integer
> biCompression As Long
> biDataSize As Long
> biXPelsPerMeter As Long
> biYPelsPerMeter As Long
> biClrUsed As Long
> biClrImportant As Long
> palette(0 To 15) As Long
>End Type
>

...

>
>By the way, forgive any "typos" in this post. There are bound to be a
>few the way I've been bashing these keys!
>
>Mike
>
>

Are you thinking that one could read in the 24 bit bmp in VB and then
write it as 4 bit bmp? This is also an option, but in that case, I
would write a small stand-alone program to do this, and use Shell to
run it from VB, where the file name is available. Alternatively, I
could have some code which picks up all bmp file names and then puts
them in 4 bit.

Are there simple ways of writing .emf files from VB, say for example,
to draw a rectangle and an arrow?
























































































































..
First  |  Prev  | 
Pages: 1 2 3 4 5
Prev: User Defined Data Type --- Please HELP!!!!
Next: Multiple icons in exe