Error 480 - can't create autoredraw image
in [Visual Basic]
|
From: Mike D Sutton on 1 Sep 2006 12:29 > I found this sampling page last night: > http://www.americaswonderlands.com/digital_photo_interpolation.htm > > 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, Mike - Microsoft Visual Basic MVP - E-Mail: EDais(a)mvps.org WWW: Http://EDais.mvps.org/
From: Mike Williams on 1 Sep 2006 18:02 "Mike D Sutton" <EDais(a)mvps.org> wrote in message news:uhIOGHezGHA.1252(a)TK2MSFTNGP04.phx.gbl... > 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 projects. 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 system. Mike Williams MVP Visual Basic Option Explicit 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 End Type 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 End Type Private Type DIBSection dsBm As Bitmap dsBmih As BitmapInfoHeader dsBitfields(0 To 2) As Long dshSection As Long dsOffset As Long End Type 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" End Sub
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 fits in.
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. NNTR Mike - Microsoft Visual Basic MVP - E-Mail: EDais(a)mvps.org WWW: Http://EDais.mvps.org/
From:
Mike Williams on 3 Sep 2006 17:22
"Mike D Sutton" <EDais(a)mvps.org> wrote in message news:eQc3LS4zGHA.5072(a)TK2MSFTNGP03.phx.gbl... > 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: http://www.samaritans.org/ > 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 quality Michael? > 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 . . . completely pointless! > 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 lot better. > 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: http://www.samaritans.org/ Have a nice day. Mike |