Error 480 - can't create autoredraw image
in [Visual Basic]
|
From: Mike D Sutton on 1 Sep 2006 06:55 > Yes, and it's very simple code. The FreeImage > help file (a 2MB PDF download) has a sample > showing the effect of greatly enlarging a small > image with different filters. From looking at that > and trying the Reconstructor demo it seems that a > "bicubic" resample is probably the best way to get > very good quality reasonably quick, and bilinear is > moderately good very quickly. I wonder how that > compares to whatever method is used in StretchBlt. Bicubic is pretty good for scaling images up, however Lanczos3 will generally give you a slightly sharper result but at the cost of speed. For your requirements though, I'd say Bicubic should be more than satisfactory. Indeed since your input is a JPEG image, bicubic may be a better algorithm to go for anyway since Lanczos3 will often produce 'ringing' round JPEG compression artefacts on badly compressed source images due to its edge enhancing properties. Hope this helps, Mike - Microsoft Visual Basic MVP - E-Mail: EDais(a)mvps.org WWW: Http://EDais.mvps.org/
From: Mike D Sutton on 1 Sep 2006 07:12 > Are you using the exact code I posted, which loads a jpg file (not a bmp file) into a StdPicture object using the VB > LoadPicture function? At this end if I do that I get a 24 bit bitmap in the StdPicture on an XP machine running at > full colour depth but I get a 16 bit bitmap on the same XP machine running at 16 bit colour depth. If I first run the > code with the machine set to full colour and I then switch to 16 bit colour in Control Panel without closing the VB > test program I do still get a 24 bit bitmap, but as soon as I close the VB program and reopen it (or restart the > machine) I get the 16 bit result. Can you check it again for me Mike? Perhaps others here might like to check it as > well? The code I'm using is shown below. In the meantime, do you have any code that will reliably load a jpg into a > StdPicture obect while retaining its full 24 bit colour depth even on 16 bit machines. If you do then I'd welcome a > copy. I was loading a 24-bit bitmap running at 16-bit without a reboot, so those results may not have been entirely accurate, however the bit depth of the image is not the point I've been trying to make - As long as it's loaded into a DIB the memory limitation the OP was running into shouldn't be a factor. I wouldn't be surprised if the PictureBox uses a DDB for its back buffer since it's primary purpose is for on-screen rendering, which would be where the "Cannot create AutoRedraw image" error comes from. This makes far more sense since simply loading the picture has absolutely nothing to do with AutoRedraw (it's not touched any controls at that point.) I cannot verify this assumption for the time being though since I don't have a Win9x machine to hand. Mike - Microsoft Visual Basic MVP - E-Mail: EDais(a)mvps.org WWW: Http://EDais.mvps.org/
From: mayayana on 1 Sep 2006 09:16 > > Bicubic is pretty good for scaling images up, however Lanczos3 will generally give you a slightly sharper result but at > the cost of speed. > For your requirements though, I'd say Bicubic should be more than satisfactory. Indeed since your input is a JPEG > image, bicubic may be a better algorithm to go for anyway since Lanczos3 will often produce 'ringing' round JPEG > compression artefacts on badly compressed source images due to its edge enhancing properties. 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. 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?
From: Mike Williams on 1 Sep 2006 10:12 "Mike D Sutton" <EDais(a)mvps.org> wrote in message news:%23ugk0ebzGHA.4452(a)TK2MSFTNGP05.phx.gbl... > I was loading a 24-bit bitmap running at 16-bit without a reboot > so those results may not have been entirely accurate Yep. That's the point I was making. If you're running some code in the VB IDE to check the depth of the bitmap after loading a jpg into a StdPicture object using the VB LoadPicture function you need to at least close down and restart the VB IDE after any change in screen depth, otherwise the result will not be reliable. > however the bit depth of the image is not the point I've been trying to > make I think it was, unless of course I misundertood you when you said, "Also, is the problem really in loading the JPEG off disk or displaying it in the picture box? At least when VB returns the image in a StdPicture object it appears to be a DIB" ;-) Mike
From: Mike D Sutton on 1 Sep 2006 12:15
> I think it was, unless of course I misundertood you when you said, "Also, is the problem really in loading the JPEG > off disk or displaying it in the picture box? At least when VB returns the image in a StdPicture object it appears to > be a DIB" ;-) Yes, you did.. Unless your system is (again) operating differently to all mine, the bmBits member should be filled indicating that the image is a DIB, not a DDB (a DDB's image data is managed by the graphics driver and as such you don't get direct access to it.) Bit-depth is irrelevant, which is what I've been trying to explain.. Mike - Microsoft Visual Basic MVP - E-Mail: EDais(a)mvps.org WWW: Http://EDais.mvps.org/ |