Error 480 - can't create autoredraw image
in [Visual Basic]
|
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
From: mayayana on 3 Sep 2006 19:03 I think I've got this worked out now. I'm loading images as StdPicture with LoadImage, then copying them into a 24-bit DIB in a class loosely based on the vbAccelerator cImage class, which is a nice, clever design that wraps up all those awkward DC and DIB ops needed to transfer bitmaps. (I wasn't sure about whether an 8-bit image could be copied directly to a 24-bit DIB without extra steps, but I'm having no trouble processing GIFs and then saving them as 24-bit BMPs to be turned into JPGs.) I've then written a BitBlt routine into the class for cropping and adapted the bilinear and bicubic routines from the "Reconstructor" sample project for resizing. It's complex code but also very compact. Each routine returns a new copy of the class, which is really little more than a "gift wrapped" DIB. It's slightly slow with the resizing on large images, but the quality seems to be very good. I also found straight VB code for writing JPGs, but it has 2 drawbacks: 1) It's notably slow and 2) the author is rather obnoxious about getting credit and specifies that commercial use requires direct permission...so it's probably not worth dealing with. -------- The mystery to me now is that so many people seem to be using FreeImage or GDI+ and don't know about the "Reconstructor" code.
From: Mike Williams on 3 Sep 2006 19:39 "mayayana" <mayaXXyana1a(a)mindXXspring.com> wrote in message news:QaJKg.5715$xQ1.747(a)newsread3.news.pas.earthlink.net... > I think I've got this worked out now. > I'm loading images as StdPicture with > LoadImage, then copying them into a > 24-bit DIB in a class loosely based . . As you appear to have discovered, LoadImage is a very useful function. Capable of loading and if necessary stretching bitmaps into memory. In fact if you set the LR_CREATEDIBSECTION flag in its fuLoad (un2) parameter it'll load a bitmap from file straight into a DIBSection for you. It won't load Jpegs of course, so you'll need to use a different method of loading them (the VB LoadPicture function that Mike Sutton uses to load Jpegs into StdPicture objects degrades the colour depth when run on 16 bit colour depth systems). I seem to remember there being some nice code on the VBAccelerator site though that will load a jpeg into a DIBSection for you. Check it out. Mike
From: mayayana on 4 Sep 2006 00:19 > > I think I've got this worked out now. > > I'm loading images as StdPicture with > > LoadImage, then copying them into a > > 24-bit DIB in a class loosely based . . > > As you appear to have discovered, LoadImage is a very useful function. > Capable of loading and if necessary stretching bitmaps into memory. In fact > if you set the LR_CREATEDIBSECTION flag in its fuLoad (un2) parameter it'll > load a bitmap from file straight into a DIBSection for you. It won't load > Jpegs of course, so you'll need to use a different method of loading them > (the VB LoadPicture function that Mike Sutton uses to load Jpegs into > StdPicture objects degrades the colour depth when run on 16 bit colour depth > systems). I seem to remember there being some nice code on the VBAccelerator > site though that will load a jpeg into a DIBSection for you. Check it out. > Actually I did mean LoadPicture. I still haven't tried LoadImage. I gather that you mean a 24-bit BMP or JPG on 16-bit display will get loaded by LoadPicture as 16-bit and get distorted? (Is that what the debate was about? I didn't catch that.) That's an interesting distinction. So I guess the tradeoff is between having the convenience of LoadPicture, with the idea that nearly everyone now uses 24- or 32-bit display, or doing the extra work with LoadImage. Now I'm curious about exactly what LoadPicture is wrapping, and whether plain GDI might have the ability to load JPGs and GIFs somehow, with reasonable ease. ...And there's also the OLE version, which I haven't tried but have seen used in code samples. It's hard to figure out exactly what the differences are between all of those.
From: mayayana on 4 Sep 2006 00:19
> > I think I've got this worked out now. > > I'm loading images as StdPicture with > > LoadImage, then copying them into a > > 24-bit DIB in a class loosely based . . > > As you appear to have discovered, LoadImage is a very useful function. > Capable of loading and if necessary stretching bitmaps into memory. In fact > if you set the LR_CREATEDIBSECTION flag in its fuLoad (un2) parameter it'll > load a bitmap from file straight into a DIBSection for you. It won't load > Jpegs of course, so you'll need to use a different method of loading them > (the VB LoadPicture function that Mike Sutton uses to load Jpegs into > StdPicture objects degrades the colour depth when run on 16 bit colour depth > systems). I seem to remember there being some nice code on the VBAccelerator > site though that will load a jpeg into a DIBSection for you. Check it out. > Actually I did mean LoadPicture. I still haven't tried LoadImage. I gather that you mean a 24-bit BMP or JPG on 16-bit display will get loaded by LoadPicture as 16-bit and get distorted? (Is that what the debate was about? I didn't catch that.) That's an interesting distinction. So I guess the tradeoff is between having the convenience of LoadPicture, with the idea that nearly everyone now uses 24- or 32-bit display, or doing the extra work with LoadImage. Now I'm curious about exactly what LoadPicture is wrapping, and whether plain GDI might have the ability to load JPGs and GIFs somehow, with reasonable ease. ...And there's also the OLE version, which I haven't tried but have seen used in code samples. It's hard to figure out exactly what the differences are between all of those. |