Re: VB3 is making my head spin!

<no.addr@xxxxxx> wrote in message news:df3qhb$1jv@xxxxxxxxxxxxxx

> Well, I have learnt to use API now, and it really results in
> shorter code than writing things yourselves. Like Frank said,
> external routines are used in most languages, not just in VB.

Good. That's what I've been trying to tell you all along. Using the APIs
usually makes your job easier, not harder, and in some cases you would
need a couple of pages of VB code to achieve something than you could
otherwise achieve with a single API function call.

> All RGB (0 to 255, 0 to 255, 0 to 255) are in use for displaying
> on the screen [in response to my question "What colour depth
> are you running at by the way"]

That's not what I meant. Perhaps I should explain. When you want to draw
a line on your VB Form at a specific colour (gold, for example) you
might use:

Me.Line (100, 100)-(500, 500), RGB(189, 159, 92)

In your code you are asking for three very specific levels of red, green
and blue and Windows will do its best to use that exact colour when it
draws the line. The only time you will get a guaranteed result, however,
is when your computer happens to be running its display in full colour
mode (check Control Panel / Display / Settings to see what you are
running at). If you are running at less than full colour depth (16 bit
perhaps) then Windows will not be able to use those exact colours
(because a full RGB colour set requires 3 x 8 = 24 bits and your own
machine only has 16 bits). So, Windows will draw the line in "the
nearest 16 bit colour it can find". That's not usually a problem (except
in certain very specific cases) but you need to be aware that it also
means when you save a picture you have drawn (using the SavePicture
method) such a machine will save it as a 16 bit bmp file (whereas a
machine running at full colour depth will save it as a 24 bit bmp file).
It is this "what would the depth be of a bitmap that you saved to disk
using SavePicture on your own development machine" question that I would
like an answer to. In other words, when you go to Control Panel /
Display / Settings is your own machine set to 32 bit (full colour) or 16
bit (high colour)?

> Yes. However, to start with, a simple algorithm reducing the
> millions of colours to 8 bits is enough.

That's the point I'm making. Such an algorithm isn't that simple
(although it is of course "doable"). There are various "standard"
algorithms for doing the job (floyd-stucci and Octree are two such
algorithms) and although it is certainly possible to write them in VB3
it certainly isn't a trivial matter and it does require some thought.
There is some "ready made" code at the VB Accelerator site that shows
you some of these algorithms in action. In fact you can use it "as is"
to do your "convert to 8 bit" if you wish. The code doesn't handle RLE
compression though. Also, even though it can load an original full
colour bitmap from disk and convert it to 8 bit bitmap it suffers from
the same problem as their "count the colours" code that i posted a link
to the other day (in that it "loses" much of the original 24 bit colour
information before it even starts converting to 8 bit). That's not a
problem in this case though, because the porocess of converting to 8 bit
is usually going to lose mnuch more colour information anyway. The code
does a really good job, and at some settings it is difficult to tell the
"8 bit copy" from the "24 bit original". Check it out. If you decide to
use it then it'll save me a job ;-) Mind you, having said that, the VB
Accelerator code doesn't handle RLE compression (which I think your own
"drawn Forms" can benefit from a lot), so maybe we'd best stick to
"rolling our own". Anyway, download the VB Accelerator code and check it
out:

http://www.vbaccelerator.com/home/VB/Code/vbMedia/Image_Processing/Colour_Depth_Reduction/article.asp

> curves are plotted in 10 of the VBColor (0 to 15).

Fine. If you are using less than a total 256 different colours in your
drawing then our first job (reducing the 24 bit bmp to an 8bit bmp) will
be very easy.

> The background maps poorly to 8 bit, but that is not so important.

Perhaps you have misunderstood the 8 bit colour palette business. I
don't know what colour you are using for the background, but whatever it
is you can map it *exactly* to an 8 bit bmp file (at least as far as the
bmp file itself is concerned). At a guess I'd say that you have loaded a
24 bit bitmap of your VB Form (or whatever) into Microsoft Paint and
then saved it from MS Paint as an 8 bit bitmap. Is that what you did? If
so then you will have seen that the Form's background in the 8 bit bmp
file is nothing like the original colour. But that's a fault of
Microsoft Paint, which is *naff* at doing such jobs! I don't know
exactly how MS Paint performs that task, but I imagine that is uses the
standard "Windows default" 8 bit palette and maps every colour to the
nearest colour it can find in that palette. That is where it is going
wrong.

I'll explain briefly (I do sometimes tend to "go on a bit", but I think
you'll be in a better position to decide where to go with your program
if yopu know a little about this stuff). When you write an 8 bit .bmp
file to disk you write various header information and a colour palette
and the bitmap data itself. Each "pixel" in the bitmap data is
represented by a single byte which "points to" a specific entry in the
colour palette (the palette itself can contain full 24 bit colour
information for up to 256 different colours). So, as long as your
original bitmap uses fewer than 256 different colours then each one of
them can be represented *exactly* by an entry in the colour palette. It
is up to *you* to decide which specific colours you include in the
palette. When someone else then loads that specific 8 bit bitmap onto
their own machine, Windows will display it *exactly* as it was when you
originally created it (if their own machine is running at full colour
depth mode), and it will display it *almost exactly* on machines running
at 16 bit colour depth. You don't even have to consider what happens on
machines running at only 8 bit colour depth, because I don't think such
a machine exists any more!

To cut it short, if your original full colour bitmap uses less than 256
different colours then you can produce an *exact* 8 bit .bmp file from
it. Windows Paint "gets it wrong" because it tries to map things to the
default palette, but you can "get it right" by mapping the colours to a
specific palette that you have created yourself and that contains an
entry that exactly matches every colour in the original.

> Then there is one page where millions of colours are always
> used, but it would be stupid to try to put that in RLE.

Yes. Of course. RLE would gain you nothing. You could still convert it
to 8 bit uncompressed format though, but it would require a fairly good
"24 bit to 8 bit" colour translation algorithm, and then you would only
reduce iots size to one third of the original size. Ideally, I would
suggest that if you want to compress a full colour picture you should
convert it to a jpg file. This, as you obviously already know, is a
"lossy" format, but if you use fairly low compression ratios you can
still get an extremely good copy of the original that is about one tenth
of the original file size.

For the time being I would advise that you concentrate on saving your
"drawn graphics" as 8 bit RLE compressed bitmaps. If that's the way you
want to go then post again. I haven't actually written any RLE
compression code, so for the time being we could initially concentrate
simply on producing a standard 8 bit non compressed bitmap file from
your original "drawn" Form and then after we've done that we'll take it
to the next step. Since I've already written the code to load a raw 24
bit bmp file from disk (the code I posted the other day) then perhaps we
could use that as a starting point. That code (as it currently exists)
would require that you first save your Form bitmap out to disk as a
temporary 24 bit .bmp file, and then use my routine to load it in again.
Is that okay with you? (You'll need to ensure that your own machine is
running at full colour depth for it to work). Otherwise, we can write
the code again in a different way, such that it handles the bitmap data
dirdctly from your Formn (where it is drawn). Which would you prefer?

Unless of course you don't want top get involved in any of this stuff?
Post again if you do.

Mike





.

Relevant Pages

  • Re: VB3 is making my head spin!
    ... >machine running at full colour depth will save it as a 24 bit bmp file). ... >It is this "what would the depth be of a bitmap that you saved to disk ... >Accelerator code doesn't handle RLE compression (which I think your own ... define a new palette (I did not know that bitmap definer could also ...
    (comp.lang.basic.visual.misc)
  • Re: Converting a GDI+ 24-bit RGB Bitmap to an Indexed Format Bitmap
    ... I created and populated a new palette and an array of indexed pixel ... method to create the new GDI+ "indexed" Bitmap. ... Is a stride necessary with indexed pixel data? ...
    (microsoft.public.win32.programmer.gdi)
  • Re: Creating a GDI+ Bitmap from an 8-bit Bitmap
    ... the BITMAPINFO structure to the colors of the captured palette? ... CreateDIBSection creates an empty bitmap. ... given to GDI+, ... You could also try to create your screen capture with a bitmap created ...
    (microsoft.public.win32.programmer.gdi)
  • Re: The ColorPalette class has no constructor so how does one use
    ... You can write an unmodified Bitmap with the GIF encoder and keep the Bitmap ... would fail to change the palette. ... Dim bm As New Bitmap(_gifImage.Width, _gifImage.Height, ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Displaying Long Binary Data in a Report
    ... in Acess you are inserting the BMP file as an OLE Object. ... Rather than saving a Bitmap file, ... StudentSign field is being populated with students' signatures (captured ...
    (microsoft.public.access.reports)