Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
Originally Posted by VbNetMatrix
you should edit your code though to replace the image1 reference by picture1 in the last line, you're making reference to both.
thanks you 1000x times, I tested it, work like a charm.
Done. I just whipped that sample up quickly. Original post was referring to image control & your issue related to picturebox. Oops; at least I didn't confuse you.
Insomnia is just a byproduct of, "It can't be done"
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
Awesome control!
I wish I knew what I was doing with graphics, but alas I do not.
I have an issue that is very strange. I have a particular 8-bit BMP graphic I am trying to use on a form in my project, and I am using the latest version of your control with everything as default, I've changed nothing...
The image appears GREAT on Windows XP, however when loaded on a Windows 7 PC, the image is distorted with a lot of extra black that shouldn't be there. See the attached pic for a side-by-side comparison.
As I said I've messed with absolutely none of the control's various settings in this picture. I have experimented with a few settings to see if I could resolve the issue but I have no idea what I'm doing.
The image does display fine on both operating systems if I use the VB6 picture control to display it.
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
Originally Posted by Foolish Tech
As I said I've messed with absolutely none of the control's various settings in this picture. I have experimented with a few settings to see if I could resolve the issue but I have no idea what I'm doing.
The image does display fine on both operating systems if I use the VB6 picture control to display it.
Advice?
Maybe you can post the image so I can take a look-see. You might have uncovered a bug with my control or possibly another workaround needed due to GDI+ inadequacies? It certainly appears as if some color has been made to be transparent
Insomnia is just a byproduct of, "It can't be done"
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
Originally Posted by LaVolpe
Maybe you can post the image so I can take a look-see. You might have uncovered a bug with my control or possibly another workaround needed due to GDI+ inadequacies? It certainly appears as if some color has been made to be transparent
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
Thanx for the image. There is only 1 thing a bit unusual with it. I won't be able to get to a Win7 machine until the weekend, but it displays fine on XP & Vista. The unusual thing is that it has a DPI setting of 1081 which appears quite high.
The bottom line is that GDI+ loads the bitmap. My cFunctionsBMP class only handles 32bpp and allows GDI+ to load all other color depths.
I've uploaded the exact same image, but removed the DPI settings from it. If you have chance to test it before I get to a Win7 machine, does it display correctly or poorly? << attachment removed >>
Last edited by LaVolpe; Mar 23rd, 2012 at 10:13 AM.
Insomnia is just a byproduct of, "It can't be done"
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
Originally Posted by LaVolpe
Thanx for the image. There is only 1 thing a bit unusual with it. I won't be able to get to a Win7 machine until the weekend, but it displays fine on XP & Vista. The unusual thing is that it has a DPI setting of 1081 which appears quite high.
The bottom line is that GDI+ loads the bitmap. My cFunctionsBMP class only handles 32bpp and allows GDI+ to load all other color depths.
I've uploaded the exact same image, but removed the DPI settings from it. If you have chance to test it before I get to a Win7 machine, does it display correctly or poorly? Attachment 87776
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
Originally Posted by Jonney
On my Win7, both show black dots.
Ok, thanx. That is not good. As I said, GDI+ loads the image. This could be a problem with GDI+ or my CreateSourcelessHandle routine that all bitmaps get sent to. Will try to resolve it this weekend
Last edited by LaVolpe; Feb 17th, 2012 at 08:49 AM.
Insomnia is just a byproduct of, "It can't be done"
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
Originally Posted by LaVolpe
Ok, thanx. That is not good. As I said, GDI+ loads the image. This could be a problem with GDI+ or my CreateSourcelessHandle routine that all bitmaps get sent to. Will try to resolve it this weekend
Yep, still shows black dots.
A little background: my app is designed for others to use and custom brand with their own logo/text. So I didn't create the image, but I did I did find out something about the creation of the image from the person who sent it to me.
He said that he tried to create the ever elusive, non-existent, "transparent bmp" with it (because before finding you awesome control, I had limited my app to BMP only using the built-in VB6 picturebox.) As said, the image originally displayed fine in the picturebox on Win7, but the issue of course occurred when he updated the app to a newer version which uses your control.
He didn't remember all the voodoo he underwent in his attempt to create this "transparent bmp", however. But maybe he used some funky hex color code somehow packed into a BMP format, that could explain something *shrug* so I would consider his image a special exception in the graphics world and not something you'll probably run across very often
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
Originally Posted by Foolish Tech
I would consider his image a special exception in the graphics world and not something you'll probably run across very often
If only... I have scrutinized your file and found no liberties taken. It is simply an 8 bpp, 256 color image. The contained bitmap header is correctly filled out (except maybe for that high DPI). None of the palette colors use the alpha byte. In short, there is nothing wrong with the image. I do think, right now, it is a problem with my control. When moving from 1 O/S to another, sometimes it unveils logic errors previously unseen. My gut says that this problem can occur with other paletted bitmaps too.
Insomnia is just a byproduct of, "It can't be done"
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
Originally Posted by Foolish Tech
Yep, still shows black dots.
Ok, took a bit to figure it out. The issue is order of code. When I create a sourceless GDI+ image, I copy the bits from one handle to the other, then copy the palette. On Vista & earlier, no problem, but on Win7, a problem. So, by copying the palette first, then the image bits, problem goes away. Though I know the fix for this specific problem, I need to re-look at other code too where I manipulate palette information (i.e., creating/displaying animated gifs). Fix will be in the next update which I expect to be out by end of month.
If you can't wait til March, here's an immediate patch
In the modCommon module, find the function CreateSourcelessHandle then...
Code:
' find this block of code
If GdipBitmapLockBits(Handle, dstBoundsI, ImageLockModeRead, tBMPsrc.PixelFormat, tBMPsrc) = 0& Then
' open the destination for writing using the pointer we just got from source
tBMPdst = tBMPsrc
If GdipBitmapLockBits(ReturnObject, dstBoundsI, ImageLockModeWrite Or ImageLockModeUserInputBuf, tBMPdst.PixelFormat, tBMPdst) = 0& Then
GdipBitmapUnlockBits ReturnObject, tBMPdst ' done
' for paletted images, need to transfer palette also
If tBMPsrc.PixelFormat <= lvicColor8bpp Then
GdipGetImagePaletteSize Handle, cPal.Count
If lType Then
GdipGetImagePalette Handle, cPal, cPal.Count
GdipSetImagePalette ReturnObject, cPal
End If
End If
' and replace with this block of code (just re-arranging things a bit) & fixing 1 minor logic bug too
' for paletted images, need to transfer palette also
If (tBMPsrc.PixelFormat And &HFF00&) \ &H100& <= 8& Then
GdipGetImagePaletteSize Handle, cPal.Count
If cPal.Count Then
GdipGetImagePalette Handle, cPal, cPal.Count
GdipSetImagePalette ReturnObject, cPal
End If
End If
If GdipBitmapLockBits(Handle, dstBoundsI, ImageLockModeRead, tBMPsrc.PixelFormat, tBMPsrc) = 0& Then
' open the destination for writing using the pointer we just got from source
tBMPdst = tBMPsrc
If GdipBitmapLockBits(ReturnObject, dstBoundsI, ImageLockModeWrite Or ImageLockModeUserInputBuf, tBMPdst.PixelFormat, tBMPdst) = 0& Then
GdipBitmapUnlockBits ReturnObject, tBMPdst ' done
Last edited by LaVolpe; Feb 17th, 2012 at 07:06 PM.
Insomnia is just a byproduct of, "It can't be done"
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
nice finding that one... it's kind of burried deep.
Win7 is the first OS to fully support PNG, (to others: no Vista doesn't) I'm guessing it is using the palette information to show the png as soon as it arrive (in IE9), therefore, he doesn't recalculate (re-adjust) the palette after he has all the bit of the images because he think he already loaded it first...
could be possible.
The palette is the first thing to be sended after the header on Web uploade isn't ?
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
@VbNetMatrix
Not sure if that is the issue here since we are talking about a simple 8 bpp bitmap. However, GDI+ does the palette different in Win7 as proven by the bug & fix. I am surprised GDI+ would do anything with the palette since we are not drawing the image, but simply setting the palette colors. This could be troublesome for previous version apps that use GDI+ to toggle palette colors for sprites
Anyway, if I get really curious, I could use the earlier code and write out the palette & bitmap pixel data. Then use the fixed code & do it again. At that point, via comparison I would be able to figure what GDI+ is doing. But at this point in the game, I'm not that interested right now.
P.S. You mentioned changes with Win7 and Png. Can you post the source, I'd like to get caught up on any other changes GDI+ went thru with Win7
Last edited by LaVolpe; Feb 19th, 2012 at 11:37 AM.
Insomnia is just a byproduct of, "It can't be done"
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
I read that stuff long ago when IE9 got out because my custommer where having problem with their website when "their client" used IE9 It was an OS problem, Ms fixed it by adding a condition inside IE
if OS <=Vista
png blababa
else >= win7
png blabnaaabla
I'll try to find back that article. it was rather technical, you'll like it.
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
can't find it back I found some article by google team about their javascript "fix" for png that wasn't needed under Ie9 anymore... but not the technical thing I had in past...
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
Hi Lavolpe,
I got a png that seem to have been specially crafted... I can load it inside your component but when I do an Export I always get an all black image.
I know it is probably NOT an issue with your component, I suspect foul play with the image...
but I really wish I could have the image back So since you're a specialist in image, I thought maybe looking at this strange phenomenon could interest you.
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
When you say "Export", I am assuming you mean right clicking within the property page and saving the image to file? If so, I cannot replicate your problem. Here is the image I extracted, is it the same as you expected?
Insomnia is just a byproduct of, "It can't be done"
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
By export, I meant using the code I provided withing the project I created.
My program (not the project I gave in previous post) load image of user choice, apply some watermark and save it back. but when I do that with THAT image, the result is a big black rectangle.
I found out how it was crafted though, but unless I read pixel by pixel and change each pixel back to another image, I don't know how I could fix it. The guy used Black pixel ALL over the image and he play with opacity for making the image appearing... it's kind of cleaver because program like Adobe Photoshop doesn't allow you to change the color of the Opacity, but with your component, I succeeded.
I'm not sure if your component got a "filter" I could apply to image... ( About this, I read the documentation but I didn'T find where you mention how to apply filter or effect like the one you did in some previous post with the Fox and the Bubble to give 3d effect with Alpha channel.)
Also take not that I'm using WinXp and under this OS, the image you just sent appear as this:
The "viewer" see it correctly, but other WinXp BASE program see it as a big black rectangle.
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
Possible you have an outdated GDI+ dll? On XP and Vista, simply loading the image in reply #419 into the AIC, it displays properly. Saving it to file on both systems, the saved file displays properly when loaded into the AIC. I cannot reproduce your problem. Everything works just fine
For your info, the GDI+ version I have on my XP box is dated Oct 2010
Now if you are saying that some other program can't read the image correctly, but the AIC can, then the other program has a problem. If however, you are saying that after manipulating the image, it is saved as a black rectangle, then I think it would be helpful to see some of the code you use to change the image before saving it.
To prevent any confusion, please post an image that displays properly in a typical viewer but doesn't display correctly in the AIC.
Edited: Regarding v3 of the AIC. I think I'll have the save functions rewritten/debugged this week. Then I just need to test the control out against the sample projects to ensure I didn't foul something up during some of the rewrites. I probably did, just hope I can find most of them so you guys don't have to .
If all goes well, it'll be released within 1-2 weeks from today
Last edited by LaVolpe; Mar 13th, 2012 at 12:40 AM.
Insomnia is just a byproduct of, "It can't be done"
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
Originally Posted by LaVolpe
Possible you have an outdated GDI+ dll?
doubt that...Like I tried to explain, this is NOT a bug. it is the way the image was crafted.
Originally Posted by LaVolpe
On XP and Vista, simply loading the image in reply #419 into the AIC, it displays properly. Saving it to file on both systems, the saved file displays properly
try to save the file as BMP, you'll understand what I am experimenting. As I have stated before though, this is not a bug with your component. This image is crafted in a special way to give that result. However, in order to deal with the way this image is crafted, I need to be able to change the color of the Transparency. To explain myself more properly, I made 2 images imageA.png has a RED transparency and imageB.png has a BLACK transparency (more common)
This is the same method GIF use in order to make transparency. It take 1 color and set it as the transparent color. All pixel of that color are then transparent.
in png it work a little bit different but when applied, it is like each pixel with this color has opacity set to 0.
Originally Posted by LaVolpe
For your info, the GDI+ version I have on my XP box is dated Oct 2010
what file in particular should I look for ?
Originally Posted by LaVolpe
If however, you are saying that after manipulating the image, it is saved as a black rectangle, then I think it would be helpful to see some of the code you use to change the image before saving it.
Use the code I sent in post #418 and change Dest format to BMP. but again... this IS NOT A BUG. The result is the consequence of the way the file was crafted.
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
Originally Posted by VbNetMatrix
Use the code I sent in post #418 and change Dest format to BMP. but again... this IS NOT A BUG. The result is the consequence of the way the file was crafted.
It's a matter of understanding GDI+ limitations. The AIC will display it correctly after it has been saved to a BMP. But on XP, anyway, window's picture/fax viewer, MS Paint, & others may display it as a black rectangle when saved to bitmap. This is because GDI+ doesn't support 32 bpp alpha channel bitmaps. Not sure if Vista & Win7 versions of GDI+ have been fixed to provide that capability. With my AIC, I've known this for years and have custom routines to determine if the alpha channel is used and if so, how it is used.
a) all alpha values are 255 - the alpha channel exists but has no effect on the image
b) all alpha values are zero - the entire image is either transparent or app should treat it as all are 255
c) alpha value applies & the RGB components may or may not be premultiplied against the alpha values
-- read comments at bottom of sample code provided below.
-- regarding para b) above: In the rare case of a 100% transparent 32bit bitmap (not one pixel is opaque nor semi-opaque), then image is treated as if all alpha values are 255 not zero. A decision needed to be made & that was my decision
When an app does not support the alpha channel of bitmaps, then the channel is assumed to be all opaque. Since the image forecolor is black and the color of the transparent pixels are black, the image appears 100% black on software that doesn't properly read the bitmap format. Changing the color of the transparent pixels to say white would make the bitmap appear as black text over white background. However, this is WRONG. Even though the pixels are white, their opacity level is 0% -- fully transparent. It doesn't matter what color those pixels are, they should never be visible in a decent viewer; unless the viewer has options to render with/without the alpha channel
Note: PNG & GIF viewers handled these situations a bit differently when their formats were new to the world. Both have a special field in their format that identifies a background color. This bkg color would be used if the software displaying the PNG/GIF could not or would not render transparency.
Note: If some app is using the alpha channel to write their own information in it, then apps like mine are going to assume the alpha channel is used for the image, not for some custom values. In those cases, then the only apps that may display the image as intended is the one that created the custom values or apps that do not honor the alpha channel
Edited: Now to discuss changing colors of transparent pixels so they are not always black? This has no real advantage except for viewers that cannot properly recognize 32bpp bitmap formats using the alpha channel.
-- Not doable with GDI+ easily as far as I know. The problem is that when GDI+ sees 100% transparency, it always changes the pixel values to black when rendering. This means you can have an all-white image at 100% transparency. If you save it like that; no problem. But if you draw anything onto it then save it, GDI+ changes any remaining transparent white pixels, within the drawing area, to now be transparent black pixels
-- GDI+ won't let you create a blank image containing 100% transparent pixels other than black. If you try to create a GDI+ brush of any transparent color and fill the blank image, all transparency is changed to 0,0,0,0 regardless of the brush color
-- Here's a bit of proof
Code:
Option Explicit
Private Declare Function GdipGetImageGraphicsContext Lib "gdiplus.dll" (ByVal pImage As Long, ByRef graphics As Long) As Long
Private Declare Function GdipDeleteGraphics Lib "gdiplus.dll" (ByVal mGraphics As Long) As Long
Private Declare Function GdipCreateSolidFill Lib "gdiplus.dll" (ByVal mColor As Long, ByRef mBrush As Long) As Long
Private Declare Function GdipDeleteBrush Lib "gdiplus.dll" (ByVal mBrush As Long) As Long
Private Declare Function GdipFillRectangleI Lib "gdiplus.dll" (ByVal graphics As Long, ByVal brush As Long, ByVal X As Long, ByVal Y As Long, ByVal nWidth As Long, ByVal nHeight As Long) As Long
Private Sub Command1_Click()
Dim SS As SAVESTRUCT, tImg As GDIpImage, bAlphas() As Byte
SS.Width = 256: SS.Height = 256
SS.ColorDepth = lvicConvert_TrueColor32bpp_ARGB
SS.RSS.FillColorARGB = ConvertRGBtoARGB(vbGreen, 0) ' transparent green
SS.RSS.FillColorUsed = True
Set tImg = New GDIpImage
' call function to create new bitmap. That function calls a GDI+ API that erases the bitmap
' with the passed color (transparent green). But you will see, all transparency ends up black
SavePictureGDIplus Nothing, tImg, lvicSaveAsBitmap, SS
SavePictureGDIplus tImg, App.Path & "\test1.bmp", lvicSaveAsBitmap
' now we'll use a solid green brush and change the alpha values to zero manually
SS.RSS.FillColorARGB = ConvertRGBtoARGB(vbGreen, 255) ' opaque green
SavePictureGDIplus Nothing, tImg, lvicSaveAsBitmap, SS
ReDim bAlphas(0 To CLng(SS.Width) * SS.Height - 1&) ' all zero values
tImg.AlphaMask bAlphas(), True ' change alpha values
Erase bAlphas()
SavePictureGDIplus tImg, App.Path & "\test2.bmp", lvicSaveAsBitmap
' sounds promising, no? Nope. Now if you draw anything onto this green transparent image using GDI+,
' any green transparency reverts to black transparency
Dim tIcon As GDIpImage, hGraphics As Long, hBrush As Long
Set tIcon = LoadPictureGDIplus(Me.Icon)
GdipGetImageGraphicsContext tImg.Handle, hGraphics
tIcon.Render 0&, , , , , , , , , , , hGraphics
' and for the fun of it, we'll create a transparent blue brush and fill part of the image with it
' but where it paints, it will be black not blue
GdipCreateSolidFill ConvertRGBtoARGB(vbBlue, 0), hBrush
GdipFillRectangleI hGraphics, hBrush, 128, 128, 96, 96
GdipDeleteBrush hBrush
GdipDeleteGraphics hGraphics
Set tIcon = Nothing
SavePictureGDIplus tImg, App.Path & "\test3.bmp", lvicSaveAsBitmap
' Loading the 3 test bitmaps into the AIC, you'll get these results:
' 1) all black transparent bmp: Image will appear 100% opaque black not transparent
' 2) all green transparent bmp: Image will appear 100% opaque green not transparent
' 3) green & black transparency with icon. Image will be 100% transparent except for the icon in top/left corner
' Why is 100% transparency in bitmaps 1 & 2 being shown as opaque? Simply because of the tie breaker rules
' my routines use when trying to determine alpha usage. The rules are simple enough:
' a) Any alpha values other than 0, then alpha is assumed in use & applied to the image
' b) If all alpha values are zero then either image is 100% transparent or alpha values are not used and image is 100% opaque
' -- since the AIC is designed to display images, the default tie breaker is: 100% opaque, not 100% transparent
' -- odds of seeing a 100% transparent 32bit bitmap are extremely rare, so assume it is not on purpose
End Sub
-- So, how does one change the transparent color in a bitmap? Pixel by pixel modifications. Prior to saving, one needs to loop thru the image bits and check for zero alpha values. Once found, change the RGB component of that pixel to the desired color
Last edited by LaVolpe; Mar 13th, 2012 at 03:19 PM.
Insomnia is just a byproduct of, "It can't be done"
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
very interesting indeed.
about your conclusion, it was exactly what I had in mind... in fact right before I read your post, I already had an export of the file that I did pixel by pixel by modifying the alpha channel of thoses who were crafted in that special way.
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
Hi Lavolpe,
I found something you would be interested in.
a bug (that is easy to fix) that make your component completely crash inside the IDE.
here the process to REPRODUCE the bug from your side.
1. make a project, put a Lavolpe Component on the form.
2. add a BUTTON on the form (important)
3. add an image inside the component with the property page.
4. save and exit.
5. Open your project back,
6. open the property page of the lavolpe image.
7. Click browse to select a new image (DO NOT CHOOSE THE IMAGE YET)
8. Click on the form button... (the one you added)
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
Hi again...
I got a little question about SaveControlAsDrawnToGDIpImage parameter...
I've tried to see the difference... but it seem in PNG there is no difference.
I can see difference if I export to BMP, there will be squared instead of stranparency while setting the parameter to True, will "emulate" the transparency color...
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
Regarding the error generated within the property page. Thanx and here's the fix which will be applied to the updated control when I post it later this month. FYI. Error was not generated in Vista.
Object: Property Page (ppgCustom)
Routine: cmdBrowse_Click
1. At very bottom of the event, add this
Code:
ExitRoutine:
If Err Then Err.Clear
2. In same event, find this line: If cBrowser.ShowOpen(PropertyPage.hWnd) Then
Just before that line, add this: On Error GoTo ExitRoutine
3. In same event, find this line: With cFolderBrowser
Just before that line, add this: On Error GoTo ExitRoutine
Ok, regarding your question about PNG and SaveControlAsDrawnToGDIpImage... Sorry I don't understand what you are asking.
Insomnia is just a byproduct of, "It can't be done"
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
I'm trying to load a lavolpe.picture into tImg (GDIpImage) and then modify SOME pixel and then save result back...
unfortunately, when I do that, I can SHOW on screen on another control the RESULT and it is Fine. but when I try to save that result to DISK, I got the original file unchanged.
as for SaveControlAsDrawnToGDIpImage, it does work but some pixel are slightly changed no matter what parameter I provide. And I wanted to know more about what that parameter was really doing.
but my main question is more "how I can save back to disk the picture I have modified" since it doesn't seem to work.
If instead of using a picture as source, I use a blank image and then copy pixel by pixel the "source" image and then add my modification, then SavePictureGDIplus work correctly...
in other word:
this work:
Set tImg = New GDIpImage
ss.Width = lavPicture.ScaleWidth
ss.Height = lavPicture.ScaleHeight
ss.ColorDepth = lvicConvert_TrueColor32bpp_ARGB
SavePictureGDIplus Nothing, tImg, , ss
... 'here pixel modification
SavePictureGDIplus tImg, App.Path & "\00.png", lvicSaveAsPNG, ss
This doesn't work:
Set tImg = lavPicture.picture
ss.Width = lavPicture.ScaleWidth
ss.Height = lavPicture.ScaleHeight
ss.ColorDepth = lvicConvert_TrueColor32bpp_ARGB
SavePictureGDIplus lavPicture.picture, tImg, , ss
... 'here pixel modification
SavePictureGDIplus tImg, App.Path & "\00.png", lvicSaveAsPNG, ss
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
When tImg has no image and you pass a SS to SavePictureGDIplus, you are telling the routines to create a new blank image of the requested bit/color depth: lvicConvert_TrueColor32bpp_ARGB
When tImg is a loaded picture and you call SavePictureGDIplus with a passed SS that contains a bit/color depth, it is possible that a conversion occurs in the save routines. That conversion may be what you are experiencing. You have no control over the conversion process
Try 1 of these:
1) set SS.ColorDepth = lvicNoColorReduction
Else one of these:
If the image in tImg is 32bpp then...
a) After loading the image into tImg, make tImg.KeepOriginalFormat to false. This converts tImg to a 32bpp bitmap format
b) change your pixel values, save image to PNG
If the image in tImg is not 32bpp or you are not sure, then...
a) save tImg with SS.ColorDepth as lvicConvert_TrueColor32bpp_ARGB as a bitmap format, not PNG
b) do your pixel modifications
c) now save to PNG as needed
Insomnia is just a byproduct of, "It can't be done"
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
I never work with something lower then aPNG why settle for less when you can have no degradation, compression and alpha blending?! So, it's eitheir ICO or PNG for me
I started with a working project on a BLANK image... then I changed:
SavePictureGDIplus Nothing, tImg, , SS
to
SavePictureGDIplus aicLine.Picture, tImg, , SS
(now not working)
then I tried solution #1 (before and after SavePictureGDIplus in 2 different try)
not working...
then I tried:
tImg.KeepOriginalFormat = false - as proposed
this work.
what are the implication ? what will it do to the image ? Should I expect weirdo reaction under some parameter ?
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
Working with 32bpp bitmaps is ideal. All image formats (png, jpg, icon, etc) are reduced to bitmap when being displayed on screen. 32bpp bitmaps can have their bits accessed easily with GDI+. A 32bpp bitmap can be saved to any format that uses the alpha channel without any degradation. Regarding passing SS, it is not needed unless you want to change the image during saving. When not passed, all values are filled from the image, as necessary. PNG, TGA are formats that can compress most color depths without color loss. Other image formats may be limited to specific ranges of color depths before loss occurs
Exception: If saving to an image format that doesn't support the source image color depth, then loss of original data may apply. For example, GIF doesn't support 32bpp unless alpha values are either 0 or 255.
Note about saving. If passing a SS, then there is a chance that the image can be redrawn, depending on the SS structure values/settings. If the image is redrawn, then any transparent pixels will be reset to black transparency by GDI+.
Last edited by LaVolpe; Mar 19th, 2012 at 03:37 PM.
Insomnia is just a byproduct of, "It can't be done"
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
yeah I knew a lot about image format. I did an essay at university on them (and it's online too) but it is in french...
I speculate that in the long run, GIF and JPEG will vanish (for good)
ok, so in my case, SS is optional...
but what are the implication of the added line:
tImg.KeepOriginalFormat = false
wich make me able to SAVE the change to the real image.
does it imply more then just changing the pixel I have changed ?
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
Originally Posted by VbNetMatrix
but what are the implication of the added line:
tImg.KeepOriginalFormat = false
wich make me able to SAVE the change to the real image.
does it imply more then just changing the pixel I have changed ?
When that property is set to false, any cached data is thrown away and the image is reduced to a bitmap of equal color depth of the source. That property is intended to reduce memory consumption for loaded images. By default, loaded images keep their original source data (with few exceptions) and this can be seen as wasted memory use.
Unless the source image was a bitmap to begin with, resetting that property will result in the image being reported as PNG, but internally, the image will always be bitmap. Reading the comments at the the top of the GDIpImage class may be helpful
Insomnia is just a byproduct of, "It can't be done"
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
very interesting.
the cache thing is an interesting feature though, even if it can be seen as a waste of memory.
I didn't saw that KeepOriginalFormat in the documentation, I must have missed it.
I'd like to know with all the implementations in this Newest version would it be Faster or slower to this kind of project if i use it instead of the old version 1.1.0 of your Alpha Image Control.
I really would appreciate your comment back. Greetings!
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
Hi alanXp,
I see that your application rely on large image. Lavolpe component is no doubt the best for handling different image format, but like you, I have notice some problem with large image.
The fix I propose and use in my program is to use regular image/picture box component for image that doesn'T need to have alpha blending (transparency) .
Lavolpe (a few post back) showed me how to load a PNG into memory and then transfer it to a regular image/picturebox control.
I think the same effect could be used in your program by replacing the background image (zorder1) by a picture box.
I have used this technique on a game myself with a background png of 1280x768 without any lag effect using a simple Pentium 4 - 3.0ghz
I never tried the v1.1 Component and I'm using the latest version.