From: Mike D Sutton on 1 Sep 2006 12:29
> I found this sampling page last night:
> It seems like the bilinear is noticeably faster
> and noticeably lower quality. Of the other methods,
> I'm hard-pressed to see a significant difference
> at any reasonable enlargement.
> Unfortunately, the person who made the sample page
> used a sharpen filter after resizing, so the samples
> are a bit deceptive. But they all stil look remarkably
> clear enlarged by a factor of about 6.
Yeah, I found the same page while trying to find examples for my prior post, however due to the post-processing this
page's results are next to useless. One of the features of Lanczos3 interpolation is that it performs sharpening as
part of the interpolation process, which makes it very good at preserving detail, where as bicubic tents to smooth these
details out. This is more apparent when scaling down, however also plays a part when scaling up also.
> So then what about StretchBlt? Is that just dumb pixel
> addition in the case of interpolation? And how would that
> apply to shrinking? Do the different methods change
> in their efficiency in that case?
For COLORONCOLOR mode, it uses 'nearest neighbour' interpolation, which simply means no interpolation (in the page you
cited you'll see this right up at the top under the original image thumbnail.) For HALFTONE mode, you're looking at
Lanczos3 interpolation (although I'm not sure whether the one on the previous page uses Lanczos2 or Lanczos3 - The
latter being slower but higher quality due to it's larger sample kernel.)
Hope this helps,
- Microsoft Visual Basic MVP -
From: Mike Williams on 1 Sep 2006 18:02
"Mike D Sutton" <EDais(a)mvps.org> wrote in message
> the bmBits member should be filled indicating that the image is a DIB
The original post was about picture quality, and one of the points raised in
the thread concerned the current colour depth of the system. You said, "Is
the problem really in loading the JPEG off disk or displaying it in the
picture box?". You went on to say, "At least when VB returns the image in a
StdPicture object it appears to be a DIB, which should mean it has no
problems loading the image".
Although you didn't specifically say so, the clear implication (as
reinforced below) was that you were saying the VB method of loading the jpeg
into a StdPicture object would not degrade the colour quality on a system
running at 16 bit colour depth, whereas of course displaying it in a Picture
Box on such a system would. But, contrary to what you clearly implied, that
does not in fact appear to be the case. The main point of my own response
was to in a way "defend" VB Picture Boxes (which I know you are not keen on,
at least in their Autoredraw state!) and to tell you that, contrary to what
you implied, it is the act of VB loading the jpeg into the StdPicture Object
on such a system that reduces the quality, whether you eventually place the
image in a Picture Box or not.
I think I was quite right in making the assumption above regarding the
implications of what you said because I notice that in some of your own
projects provided on http://edais.mvps.org/ you use the VB method of loading
a picture into a StdPicture object in a program whose specific task is to
perform some operation on an image without degrading its colour quality, and
I wanted to point out to you the problems of doing that on a system running
at 16 bit colour depth.
If I use the VB LoadPicture method to load a jpg (or a 24 bit bmp file) into
a StdPicture object (which is something you do yourself in your own
programs) when my system is running at 16 bit colour depth I end up with
only 16 bits per pixel in the StdPicture object instead of 24. Whether it is
in the form of a DIB or not effectively makes no difference to the fact that
the colour of the original jpg (or 24 bit bmp) file has been degraded to 16
bits by the act of "VB returning the object in a StdPicture object". So your
implied statement that it is the picture box that would degrade the image
and not the act of VB loading into the StdPicture object is not actually
true. That is the point I was trying to make, particularly as you have used
that method in some of your own programs and I make no apologies whatsoever
for pointing out my observations so that you can if necessary amend your
Here is some test code I used. You need to set your system to 16 bit colour
depth (and possibly also perform a restart just to make sure) before running
it. Obviously you will need to change the hard coded picture path to a 24
bit bmp file on your own system. The code gets both the BITMAP and the
DIBSection information (just to make sure) from the StdPicture object after
using the VB method to load a 24 bit full colour bitmap from file and it
displays the resultant bit depth in both cases in two message boxes. In both
cases the returned result is 16 bits per pixel on such a system, even though
the bitmap file itself has 24 bit colour depth . Since you use that method
yourself in your own code and also since you made the rather sarcastic
remark that "my system (again) appears to be operating differently to your
own" perhaps you might like to try the code for yourself on your own system.
Perhaps Mayayana (the original poster) might also like to try it on his
MVP Visual Basic
Private Declare Function GetObject Lib "gdi32" _
Alias "GetObjectA" (ByVal hObject As Long, _
ByVal nCount As Long, lpObject As Any) As Long
Private Type Bitmap
bmType As Long
bmWidth As Long
bmHeight As Long
bmWidthBytes As Long
bmPlanes As Integer
bmBitsPixel As Integer
bmBits As Long
Private Type BitmapInfoHeader
biSize As Long
biWidth As Long
biHeight As Long
biPlanes As Integer
biBitCount As Integer
biCompression As Long
biSizeImage As Long
biXPelsPerMeter As Long
biYPelsPerMeter As Long
biClrUsed As Long
biClrImportant As Long
Private Type DIBSection
dsBm As Bitmap
dsBmih As BitmapInfoHeader
dsBitfields(0 To 2) As Long
dshSection As Long
dsOffset As Long
Private Sub Command1_Click()
Dim myDib As DIBSection
Dim p1 As StdPicture
Dim myBmp As Bitmap
Dim retval As Long
Set p1 = LoadPicture("c:\tulips.bmp")
retval = GetObject(p1.Handle, Len(myBmp), myBmp)
MsgBox myBmp.bmBitsPixel & " bits per pixel"
retval = GetObject(p1.Handle, Len(myDib), myDib)
MsgBox myDib.dsBmih.biBitCount & " bits per pixel"
From: mayayana on 1 Sep 2006 19:14
> > So then what about StretchBlt? Is that just dumb pixel
> > addition in the case of interpolation? And how would that
> > apply to shrinking? Do the different methods change
> > in their efficiency in that case?
> For COLORONCOLOR mode, it uses 'nearest neighbour' interpolation, which
simply means no interpolation (in the page you
> cited you'll see this right up at the top under the original image
thumbnail.) For HALFTONE mode, you're looking at
> Lanczos3 interpolation (although I'm not sure whether the one on the
previous page uses Lanczos2 or Lanczos3 -
I see. Thanks. It's helpful to get an idea
of the landscape - where Windows API
From: Mike D Sutton on 3 Sep 2006 14:11
<yadda yadda, snip..>
I must admit, I very nearly lost the will to live half way through your post so you may have made some good points in
the second half but I doubt it - Just regurgitated the same rubbish.
Let's get a couple of things straight:
1) In the original question the OP mentioned nothing about image quality, only that large files wouldn't load - a
problem associated with using DDBs as opposed to DIBs. Indeed, his only concern was drawing to the screen so it's
_completely pointless_ arguing about the bit-depth of the image in memory since higher depths won't be used!
2) I never made any claims of LoadPicture() and the depth it returns the image at, only that it returns a DIB, which you
still seem to have an inability to comprehend and waffle on for _paragraphs_ about even after I explicitly clarify that
it's not the point. If my own examples use it, it's only for the convenience of supporting GIF and JPEG, I make no
claims about the call's device independence (without knowing how the call's implemented internally how could I, or you
for that matter?)
Lets also not forget all the points you've been incorrect on in this thread which you seem to just gloss over, while
endlessly hammering away at my posts. I have no problem helping people out who have programming problems on this group,
but your problems are of a different kind.
Quite frankly I've wasted far too much of my life already on you and I'm bored of it.
- Microsoft Visual Basic MVP -
From: Mike Williams on 3 Sep 2006 17:22
"Mike D Sutton" <EDais(a)mvps.org> wrote in message
> I must admit, I very nearly lost the will to
> live half way through your post . . .
Only nearly? That's sad Michael. Was it too much for you to read all in one
sitting? I hope you're feeling better now. Remember that if you ever feel
like that again you can always go to:
> In the original question the OP mentioned nothing
> about image quality, only that large files wouldn't load
If you were really concerned ONLY with the OP's ORIGINAL question then you
would have restricted yourself to answering just that one question. But you
didn't. You also answered a lot of other questions the OP posted in the same
thread, including the one in which he said, "Now I also want to do resizing.
From my research it appears that setting HALFTONE mode for StretchBlt is the
highest quality, but that it doesn't work properly". Isn't that about image
> you may have made some good points in it
I did. I'm glad you agree.
> Indeed, his only concern was drawing to the screen
You know that's not true Michael. You've just made that up in an attempt to
crawl out of the hole you've dug for yourself. In fact the OP specifically
said, "There might be shades of quality that wouldn't show up onscreen but
would show up in a print". So your own statement of, "it's_completely
pointless_ arguing about the bit-depth of the image in memory since higher
depths won't be used" is . . . erm . . . how can I put this . . . erm . . .
> I never made any claims of LoadPicture() and
> the depth it returns the image
Yes you did. Have you forgotten already Michael? I posted some LoadPicture
code for you to try on a system set to 16 bit colour depth and you said,
"Under XP I'm getting a 24-bit DIB regardless of the display depth". That's
exactly what you said Michael. I remember responding to that statement of
yours and telling you about the mistake you had made when running that code.
The statement you made makes it quite clear that you believe that
LoadPicture returns a 24 bit DIB regardless of the display depth. That's
exactly what you said. And you are wrong!
> If my own examples use it [LoadPicture into a StdPicture object]
There's no "if" about it Michael. It's a certainty. That's exactly what your
own example does!
> . . . it's only for the convenience
> of supporting GIF and JPEG
Well that's very convenient Michael. So what you're saying is your code
doesn't work properly, but it's convenient! I've got no problems with that.
I often write such code myself in various specific circumstances. But in
your case you went to a lot of trouble in your code and you used a lot of
API routines to draw the resized image in such a way as to avoid the loss of
colour depth that you would otherwise get if you instead used the native VB
methods and you effectively totally negated the effects of that by using the
LoadPicture function to load the image into a StdPicture object, thereby
destroying the bit depth of the image before the rest of your code even got
a look at it! That in itself wouldn't bother me of course. We all make
mistakes, including you. But I would prefer it if you would admit your
mistakes when you make them.
Why don't you just face facts Michael. You thought that using LoadPicture to
load a jpeg or a 24 bit bitmap file into a StdPicture object returned a 24
bit DIB whether your machine was running at 24 bit colour depth or not. In
fact you specifically said so in one of your responses. And you are wrong
Michael. It does not. On a system running at 16 bit colour depth it returns
a 16 bit DIB. Just admit it Michael. There's nothing wrong with being wrong
Michael. It comes to us all sometimes. Just admit it Michael. You'll feel a
> I make no claims about the call's device independence
> (without knowing how the call's implemented internally
Yes you do Michael. Just admit it. You specifically told me that on your
system you get full colour depth even when it is running at 16 bit. But you
are wrong Michael. It does not. Not even on your system, not unless you
"fiddle" it. You made a mistake Michael.
You even went on to make the rather nasty and sarcastic remark, "unless your
system is (again) operating differently to all mine". I remember that thread
Michael. It was quite some time ago and as I recall it was something to do
with graphic output. I remember posting some code for people to try and
quite a number of people responded. In the end it turned out that most
systems were behaving in a similar manner to my own and your own system was
just about the only one producing a different result! How convenient.
> how could I, or you for that matter, [check the
> device independence of using LoadPicture to
> load an image into a StdPicture object]?
Very simple Michael. Just write some code (as I have done) to test the
premise and run that code on various systems set to various different colour
depths. You'll see that it is NOT device independent, as I have said and as
you have argued with. Over on this side of "the big pond" it's called "suck
it and see". Why don't you suck it Michael! You really seem totally unable
to admit it when you have made an error. In one of your posts, after you had
made a mistake and posted incorrect results, and after I had pulled you up
about it, you said . . .
"so those results may not have been entirely accurate"
Seems a bit verbose that, Michael, "may not have been entirely accurate".
Any chance you can condense that a little?
By the way, I'll be going on holiday tomorrow to the English Lake District
(really beautiful place, at all times of the year and something special in
September). I'll be away for about a week so I won't see your response to
this post until I get back. In the meantime, if you again "lose the will to
live" on reading this post please remember my advice. The Samaritans are
really nice people Michael. They'll look after you. Here's the link again:
Have a nice day.