Re: VB3 is making my head spin!
- From: no.addr@xxxxxx
- Date: 1 Sep 2005 15:26:58 +0300
In article <df4c3g$uv3$1@xxxxxxxxxxxxxxxxxxxx>,
Mike Williams <Mike@xxxxxxxxxxxxxxxxx> wrote:
><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.
Yes.
>
>> 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)
>
>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)?
I have a nice flat screen with all the millions of colours it can produce,
and have set it to show all those millions of colours. However, I have to
assume that users will also (today) have good enough screens and will try
to see everything in millions of colours.
>"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
>
I think that should be good enough, because colour accuracy is not that
important for engineering results, mainly plots of various kinds.
However, since we rarely use more than 12 colours, it would be good to
define a new palette (I did not know that bitmap definer could also
define a palette with any colours), and then the rest should be a
simple code. I certainly do not want anyone to write a lot of code for
us.
>> 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.
Yes, the colours are simple except for the background which is
RGB(0,201,170). Others are from VBColor(0 to 15).
>
>> The background maps poorly to 8 bit, but that is not so important.
>
>Perhaps you have misunderstood the 8 bit colour palette business.
I did.
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?
No, from Microsoft Photo Editor, which allows RLE compressed saving. I
think Paint does not. It will simplify the colours if you store in 8 bit
and will write uncompressed 8 bit bitmaps pixel by pixel.
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).
I did not know that the palette could record in 24 bit. Yes, I have a
rough idea of how normal and RLE compressed bitmap formats are like.
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!
Yes, that is clear.
>
>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.
I think bitmaps are also written pixel by pixel in 8 bit colour
information, which is what Paint does. They are not RLE compressed, I
think.
>
>> 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.
It will turn too ugly, and these pictures are used rarely, so it is not
necessary to think about this.
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.
That is clear to me. I don't want to consider lossy compression.
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.
I do not wish anyone to put in a lot of effort for me. I understand that
you enjoy writing code and guiding people on this newsgroup, but do this
only if it is quite simple and straightforward, or if you can give me
simple instructions to find my way.
I am trying to learn these little features, which are not very
important from an engineering point of view. Other people who use this
software are not likely to appreciate this very much, otherwise I
would have long gotten it done.
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?
At present, the pictures of the screens are being saved in 24 bit bmps
on the disk (same folder as the code). I have code for loading plain
24 bit bitmaps in VB3 also. If there is some code on the Internet (in
VB6 or VB3) for converting the bitmap to RLE compressed, I think I can
adapt it to fit the rest of the code. I have searched a lot, but I
find thousands of sites with the same keywords, but the first several
not having what I am looking for.
(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?
I think as far as possible, software should reused. Unlike hardware,
second hand software can often be better than first hand. It often
gets polished with every reuse. So, if it is not difficult, we should
find it on the Internet. I have looked at a lot of sites, but perhaps
all the wrong ones.
>
>Unless of course you don't want top get involved in any of this stuff?
>Post again if you do.
>
>Mike
>
>
>
>
>
..
.
- Follow-Ups:
- Re: VB3 is making my head spin!
- From: Mike Williams
- Re: VB3 is making my head spin!
- From: Mike Williams
- Re: VB3 is making my head spin!
- Prev by Date: Re: Writing text at an angle on a VB Form
- Next by Date: Repaint problem on small images?
- Previous by thread: Re: Writing text at an angle on a VB Form
- Next by thread: Re: VB3 is making my head spin!
- Index(es):
Relevant Pages
|
