Hi all! I have a little program (written in VB6) that saves the image in
a picturebox to a BMP file. The problem is that BMP files are several
megabytes in size and do not support DPI (dots-per-inch) information for
printing.

I have turned to the PNG format which provides lossless compression
(files are only few kilobytes) and includes DPI information.

But how do I save the image in a picturebox to a PNG file?

Thanks in advance!

The png format will give you those kind of lossless compressions (50:1 or
even more) on simple images, such as line drawings with filled sections and
graphs and other images with a limited number of colours and many small or
large areas of a solid colour, but the png lossless compression of a tpyical
photo will be much less, perhaps in the order of 2:1 or something of that
nature. So, if your images are of the kind I first mentioned then png is
definitely one way to go if you want high compression, but if they are
typical photos (and if compression is your main concern) then the lossy but
still quite good compression of a jpg might be more suitable (although the
fact that png can give you lossless compression on photos might be exactly
what you want if compression is not your main concern). As far as DPI
information in an image file is concerned, that's a moot point that I won't
go into here because I sometimes get into lots of trouble from various
people for writing too much waffle :-)

I reckon GDI+ is probably your best bet. Have a look at:

http://www.vbaccelerator.com/home/vb/code/vbmedia/using_gdi_plus/Reading_and_Writing_JPG__PNG__TIF_and_GIF_Files/article.asp

Mike

VB6 does not natively support the PNG format. Look for an OCX or DLL that
does (sorry, I personally don't know of any or I'd suggest one).  Or, I
suppose you could search the Internet for the PNG format's file spec and
write the file yourself. Finding an OCX/DLL would probably be a lot easier,
and I'd be willing to bet there are free ones out there that shouldn't be
too hard to find.

Nando...

There are plenty of free resources out there for saving an image in
the PNG format.

One is the Free Image open source DLL.  It even has VB6 examples.
It's open source and available at:

http://freeimage.sourceforge.net/sourcecode.html

Even Microsoft provides that ability with the Windows Image
Acquisition Library (WIA) found here:

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=a332a77a-01b8-4de6-91c2-b7ea32537e29

Mike Williams also gave you a good resource at vbAcclerator.

And, btw, Mike.... one man's waffle is another man's treasure.  I
usually learn something with your "waffles".  Don't stop now!

Tom

what I would like to underwrite, too!

Show quote Hide quote It constitutes a long chain to trace back:

    * Date: Sun, 18 May 2008 19:34:26 +0200

news:ucj7kpPuIHA.3968@xxxxxxxxxxxxxxxxxxxxxxx

    Okay, Senn. I'll give it a whirl later. What do I need to download and
    install in order to make it work? Can you post a link?

    Mike


GDI+ TypeLib TLB
-Unicode Logo
Generator
http://www.planet-source-code.com/upload_PSC/ftp/GDI+_TypeL154059272003.zip

/senn

And Karls answer to this back then:

None of that nonsense. And, even if you're stuck using that other lib, you
can
still use FreeImage_GetFileType to tell you what sort of file you're dealing
with.
...NET: It's About Trust!

http://vfred.mvps.org

/se

senn wrote:
Show quoteHide quoteHi guys! I must share that I spent a great deal of time yesterday and
today understanding and implementing the GDI+ TypeLib routines within my
app. I just couldn't resist the temptation of having more than one file
type to save to (I only needed .PNG but I got greedy). GDI+ seemed to
offer so many other file types. Unfortunately after so much work and
troubleshooting I found I can only generate 32-bit transparent PNG files
and never 24-bit ones (just the very ones I need, since the 24-bit PNGs
do not support transparency and I cannot have transparency :-( Oh
well... can somebody just confirm this? Thanks!

-Nando

P.S.: Seems like the parameter "EncoderColorDepth" can only be set for
..JPG and .TIF. Seems like the GDI+ PNG codec just ignore any parameter.

Shotgun Thom wrote:
That is great Tom! I'll definetly look into that free image library. I
like the fact that you say they have VB6 examples! Awesome!

Interesting, I would like to try that (WIA Lib). Although I'm quite
scare now, since I spent too much time already with another Microsoft
library (GDI+) just to find out that it does not really do what I
wanted. I'll look into WIA Lib, but with reserves.

I'm not doing too much image manipulation in my app, just need to save a
bitmap file to a 24-bit PNG file. I also needed to read the bitmap and
create a new one setting DPI and resize it using basic
"Nearest-Neighbor" interpolation. I had all that figured out and set up
in my app using GDI+ (which until yesterday I never worked with). Now I
have to start from scratch. Hopefully the Free Image Library will be
more helpful.

-Nando

Hi Nando...

An even easier solution is to add the code included in this post to
your project in a Module:

It allows you to save your Picture Box as a 24bit PNG, JPG or BMP.

Once you have the picture displayed in your picture box you just call
the Sub as follows:

SaveImageAs "c:\mypicture.png", Picture1.hdc,  Picture1.Width /
Screen.TwipsPerPixelX,  Picture1.Height / Screen.TwipsPerPixelY,
CLng(100)

Open a new module in your project.  Copy the following code and paste
into the module.  Use the syntax above to call saving the image,
replacing, obviously, the file name with your own and with whatever
you named your Picture Box.

Option Explicit
'///////////////////////////////////////////////////
'// SaveImageAs - Save hDC to Bitmap or Jpeg file //
'// Ed Wilk/Edgemeal - last updated Feb.06,2010   //
'///////////////////////////////////////////////////

Private Const BI_RGB As Long = 0
Private Const DIB_RGB_COLORS As Long = 0

Private Type BitmapFileHeader
    bfType As Integer
    bfSize As Long
    bfReserved1 As Integer
    bfReserved2 As Integer
    bfOffBits 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
  biDataSize As Long
  biXPelsPerMeter As Long
  biYPelsPerMeter As Long
  biClrUsed As Long
  biClrImportant As Long
End Type

Private Type RGBQUAD
  rgbBlue As Byte
  rgbGreen As Byte
  rgbRed As Byte
  rgbReserved As Byte
End Type

Private Type BITMAPINFO
  bmiHeader As BitmapInfoHeader
  bmiColors As RGBQUAD
End Type

Private Declare Function DeleteDC Lib "gdi32" (ByVal hdc As Long) As
Long
Private Declare Function DeleteObject Lib "gdi32" (ByVal hObject As
Long) As Long
Private Declare Function CreateCompatibleDC Lib "gdi32" (ByVal hdc As
Long) As Long
Private Declare Function SelectObject Lib "gdi32" (ByVal hdc As Long,
ByVal hObject As Long) As Long
Private Declare Function CreateDIBSection Lib "gdi32" (ByVal hdc As
Long, pBitmapInfo As BITMAPINFO, ByVal un As Long, ByVal lplpVoid As
Long, ByVal handle As Long, ByVal dw As Long) As Long
Private Declare Function GetDIBits Lib "gdi32" (ByVal aHDC As Long,
ByVal hBitmap As Long, ByVal nStartScan As Long, ByVal nNumScans As
Long, lpBits As Any, lpBI As BITMAPINFO, ByVal wUsage As Long) As Long
Private Declare Function BitBlt Lib "gdi32" (ByVal hDestDC As Long,
ByVal X As Long, ByVal Y As Long, ByVal nWidth As Long, ByVal nHeight
As Long, ByVal hSrcDC As Long, ByVal xSrc As Long, ByVal ySrc As Long,
ByVal dwRop As Long) As Long

' gdi+
Private Type GUID
   Data1 As Long
   Data2 As Integer
   Data3 As Integer
   Data4(0 To 7) As Byte
End Type

Private Type GdiplusStartupInput
   GdiplusVersion As Long
   DebugEventCallback As Long
   SuppressBackgroundThread As Long
   SuppressExternalCodecs As Long
End Type

Private Type EncoderParameter
   GUID As GUID
   NumberOfValues As Long
   Type As Long
   Value As Long
End Type

Private Type EncoderParameters
   Count As Long
   Parameter As EncoderParameter
End Type

Private Declare Function GdiplusStartup Lib "GDIPlus" ( _
   token As Long, _
   inputbuf As GdiplusStartupInput, _
   Optional ByVal outputbuf As Long = 0) As Long

Private Declare Function GdiplusShutdown Lib "GDIPlus" ( _
   ByVal token As Long) As Long

Private Declare Function GdipCreateBitmapFromHBITMAP Lib "GDIPlus" ( _
   ByVal hbm As Long, _
   ByVal hPal As Long, _
   Bitmap As Long) As Long

Private Declare Function GdipDisposeImage Lib "GDIPlus" ( _
   ByVal Image As Long) As Long

Private Declare Function GdipSaveImageToFile Lib "GDIPlus" ( _
   ByVal Image As Long, _
   ByVal Filename As Long, _
   clsidEncoder As GUID, _
   encoderParams As Any) As Long

Private Declare Function CLSIDFromString Lib "ole32" ( _
   ByVal str As Long, _
   id As GUID) As Long




Public Sub SaveImageAs(ByVal sFileName As String, ByVal Source_hDC As
Long, ByVal Width As Long, ByVal Height As Long, Optional ByVal
Quality As Long = 80)
    Dim sFileExt As String
    Dim myDIB As Long, myDC As Long, fNum As Long
    Dim bi24BitInfo As BITMAPINFO
    Dim fileheader As BitmapFileHeader
    Dim bitmapData() As Byte
    ' gdi
    Dim tSI As GdiplusStartupInput
    Dim lRes As Long, lGDIP As Long, lBitmap As Long
    Dim tJpgEncoder As GUID
    Dim tParams As EncoderParameters

    ' source hDC to DIB
    With bi24BitInfo.bmiHeader
      .biBitCount = 24
      .biCompression = BI_RGB
      .biPlanes = 1
      .biSize = Len(bi24BitInfo.bmiHeader)
      .biWidth = Width
      .biHeight = Height
      .biDataSize = ((.biWidth * 3 + 3) And &HFFFFFFFC) * .biHeight
      ReDim bitmapData(0 To .biDataSize - 1)
    End With
    myDC = CreateCompatibleDC(0)
    myDIB = CreateDIBSection(myDC, bi24BitInfo, DIB_RGB_COLORS, ByVal
0&, ByVal 0&, ByVal 0&)
    SelectObject myDC, myDIB
    BitBlt myDC, 0, 0, bi24BitInfo.bmiHeader.biWidth,
bi24BitInfo.bmiHeader.biHeight, Source_hDC, 0, 0, vbSrcCopy
    Call GetDIBits(myDC, myDIB, 0, bi24BitInfo.bmiHeader.biHeight,
bitmapData(0), bi24BitInfo, DIB_RGB_COLORS)

    ' get file extension of filename to save as lower case.
    sFileExt = LCase$(GetFileExt(sFileName))
    ' Save image to file....
    Select Case sFileExt
        Case ".bmp"   ' save as bmp....
            With fileheader
                .bfType = &H4D42
                .bfOffBits = Len(fileheader) +
Len(bi24BitInfo.bmiHeader)
                .bfSize = bi24BitInfo.bmiHeader.biDataSize
+ .bfOffBits
            End With
            fNum = FreeFile
            On Error GoTo BadFileName
            Open sFileName For Output As fNum
            Close fNum
            Open sFileName For Binary As fNum
            Put fNum, , fileheader
            Put fNum, , bi24BitInfo.bmiHeader
            Put fNum, , bitmapData()
            Close fNum
        Case ".jpg", ".png"
            tSI.GdiplusVersion = 1 ' Initialize GDI+
            lRes = GdiplusStartup(lGDIP, tSI)
            If lRes = 0 Then
                lRes = GdipCreateBitmapFromHBITMAP(myDIB, 0, lBitmap)
' Create the GDI+ bitmap from the image handle
                If lRes = 0 Then
                    If sFileExt = ".jpg" Then ' JPG
                        CLSIDFromString
StrPtr("{557CF401-1A04-11D3-9A73-0000F81EF32E}"), tJpgEncoder
                        ' Initialize the encoder parameters
                        tParams.Count = 1
                        With tParams.Parameter ' jpeg Quality
                          CLSIDFromString StrPtr("{1D5BE4B5-
FA4A-452D-9CDD-5DB35105E7EB}"), .GUID
                          .NumberOfValues = 1
                          .Type = 4
                          .Value = VarPtr(Quality)
                        End With
                    ElseIf sFileExt = ".png" Then ' PNG
                        CLSIDFromString
StrPtr("{557CF406-1A04-11D3-9A73-0000F81EF32E}"), tJpgEncoder
                    End If
                    ' Save the image
                    lRes = GdipSaveImageToFile(lBitmap,
StrPtr(sFileName), tJpgEncoder, tParams)
                    ' Destroy the bitmap
                    GdipDisposeImage lBitmap
                End If
              ' Shutdown GDI+
              GdiplusShutdown lGDIP
            End If
            If lRes Then
                Err.Raise 5, , "Can not save image(GDI+ Error).:" &
lRes
            End If
    End Select
Fini:
    DeleteObject myDIB
    DeleteDC myDC
    Exit Sub

BadFileName:
    Close fNum
    Err.Raise 5, , "Can not save BMP image.:" & lRes
    Resume Fini
End Sub
Private Function GetFileExt(sFile As String) As String
    ' example" returns ".exe"
    Dim I As Integer
    I = InStrRev(sFile, ".")
    If I Then
        GetFileExt = Mid$(sFile, I)
    Else
        GetFileExt = sFile ' if not found then just return the whole
string
    End If
End Function



Thanks to Ed Wilk for this code I downloaded from somewhere but can't
remember.

Tom

Shotgun Thom wrote:
Show quoteHide quoteThanks a billion Tom!!! I'm now able to create 24-bit PNG files!!!

I'm multitasking a lot of stuff on my side, but one thing I'm still
experiment (just for curiosity) is why (for a specific BMP image sample)
I get different file sizes of 18KB and 23KB.

The sample image: A snapshot of the calculator of Windows XP as a BMP
file (446KB).

The PNG version of the file is 23KB (using the API code). I also get the
same result if I save the file manually as a PNG from MS Paint.

However, I get a smaller PNG version of 18KB saving the sample file as
PNG using Microsoft Photo Editor 3 (which shipped with Office XP or
2003). This was a smaller size without any loss in quality since I
checked by re-saving the PNG as a BMP and comparing with the sample, and
they matched bit by bit (SourceForge's WinMerge).

Just wondering how Photo Editor was able to produce a file 78% smaller
under the same PNG format. The quality specified using the API was set
to 100, so I'm quite intrigued.

-Nando

First of all, the Quality Setting included in the code I posted is
only applied when saving a file as a JPEG.  75 is a reasonable setting
for quality of a JPEG image that's purpose is to be viewed on a
monitor.  Good compression and reasonable quality.  Get much lower
than that and you may begin to notice the image deterioration.

Regarding the PNG file size differences... it all has to do with
compression techniques.  There are a bunch of tool/utilities
(PngCrush, PNGOUT, etc.) out there that do nothing but compress
existing PNG files.  There's even an online site  (www.punypng.com)
where you upload your PNG and it will reduce it for you and send it
back.  Google PNG Compression Tools and you'll see the plethora of
choices.

The nice thing about all these compression tools is there, usually, is
no loss of image quality.  The API code uses a pretty standard png
saving format.  Other utilities/programs, obviously, have tweaked the
compression.  Kinda like the difference between WinZip, GZip and 7Zip
compression.  They are all Zip tools... just different compression.

Tom

Shotgun Thom wrote:
Very interesting stuff Tom! Great site too (punypng.com).

I'm not planning to work on this, but I must sort my curiosity here :-)
I'm not an expert in file formats, my understanding is based mostly in
the common idea that an electronic image is just that, a 3D matrix of
dots (x, y, color) with that info as part of the file's header.

However, if there are so many tools around that offer different
types/levels of lossless compressions (and the files are still
backward-compatible for displaying in browsers and old editors) then
that implies these tools must be injecting the PNG file with the
*actual* code/algorithm that decompresses the picture. Which leads me to
the idea of a security vulnerability (right?). I'm not getting paranoid,
only curious. Is this the way PNG images are crafted?

Nando wrote:
Many image formats also have the capacity to store metadata, so that the
image is self describing - useful for archiving purposes.

http://www.steelbytes.com/?mid=30
for example, can strip such information from png/jpg files.

Perhaps the software you are using is also stripping that information -
because there is no standard way of adding such data to PNG files.

Jason Keats wrote:

Nice tool!

Definetly out of topic question now: is there a similar tool to for
optimizing or cleaning/removing junk from a VB6 EXE file?

Nando wrote:
No.

However, there are tools to remove dead code from your source - so that
it doesn't get compiled into your exe in the first place.
http://www.mztools.com/v3/mztools3.aspx

Some can do much more than that, like static code analysis to find
problems and even duplicate code.
http://www.aivosto.com/project/project.html

There are tools to replace all strings in your code with a function
lookup - to remove duplicate text and prepare your program for
translation of the GUI.
http://www.resourcemining.com/ResMe.htm

You can also compress your exe, if you wish.
http://upx.sourceforge.net/

I found that VB6 compiler removes functions that are not being called
anywhere, except if the function is Public in an object model(Form, Class,
UserControl), because it's Public functions are part of the interface for
these objects. If the function was private, it would be removed. Public or
Private functions that are not being called anywhere in a BAS module are
removed.

How do I know this? I viewed the disassembly in VC6 for a test program. This
is known as function-level linking, and I am glad that VB uses it.

Nobody wrote:
Show quoteHide quoteThanks, I'm glad to hear the VB compiler is (somewhat) smarter than I
thought.

However, I still think it's worthwhile to occasionally check for dead
code. There is usually a surprising amount of "junk code" in most
people's work after a while - removing unused routines and declaration
can be helpful.

Nobody wrote:

Nice finding Nobody! I'll keep it in mind when coding.

Jason Keats wrote:
Thanks Jason!

Cool!!

Show quoteHide quote

Hi Nano...

Jason is correct in that most image formats can store metadata (EXIF)
information in the image.  Here's an example of such informaion from a
typical .PNG:

File Name                       : balloonhotair.png
Directory                         : C:/iPic
File Size                         : 1571 kB
File Modification Date/Time     : 2010:08:13 13:35:28-07:00
File Permissions              : rw-rw-rw-
File Type                         : PNG
MIME Type                      : image/png
Image Width                    : 1024
Image Height                   : 768
Bit Depth                         : 8
Color Type                       : RGB
Compression                   : Deflate/Inflate
Filter                               : Adaptive
Interlace                          : Noninterlaced
SRGB Rendering              : Perceptual
Gamma                           : 2.2
White Point X                   : 0.3127
White Point Y                   : 0.329
Red X                               : 0.64
Red Y                               : 0.33
Green X                             : 0.3
Green Y                            : 0.6
Blue X                               : 0.15
Blue Y                              : 0.06
Modify Date                      : 2002:10:07 10:06:47
Description                     :
Creation Time                   : 2002:10:05 07:34:53
Software                          : iQ ImageXpress
Source                            : CYBERSHOT
Image Size                      : 1024x768

This data is easily modified or can be deleted from virtually any PNG
image.  I'm sure that would give some kind of size saving... just not
sure how much.

As far as security, I'm not sure what type of security, or
paranoia :) , you mean.  Some photographers put copyright information
as part of image metadata so that could be tampered with.

Regarding Mayayana's post

A couple of side notes that might be useful:

I think that is correct.  While Win 7 has wiautt.dll pre-installed I
don't believe it's the same version 2.0.  I know I tried using the
Printing features of WIA Ver 2.0 on Win 7 and it crapped out.



Tom

Shotgun Thom wrote:

My suspicion was that PNG files (in addition to the image data itself)
would have the actual decompression code/engine embedded into the file.
Hope my assumption is incorrect. Images should behave as a static data
file that is read by the browser and not as an EXE that provides the
browser the "execution" code to allow access to re-construct the image data.

I arrived to that conclusion to explain the fact that (with so many new
compression tools creating different PNG level of compressions) newly
created PNG files get actually understood/displayed/rendered by old
graphic software and browsers. That is a trait of a fixed image format.

    http://www.libpng.org/pub/png/

Mike

Mike Williams wrote:
Oh boy! So I wasn't so off after all. I was fast-reading the PNG
specification document and I was shocked after finding this:

"A PNG file or datastream is composed of a collection of explicitly
typed "chunks". Chunks whose contents are defined by the specification
could actually contain anything, including malicious code. But there is
no known risk that such malicious code could be executed on the
recipient’s computer as a result of decoding the PNG image. The possible
security risks associated with future chunk types cannot be specified at
this time." (section 5, pg 33, pgph 2-3)

Reference:
<http://www.libpng.org/pub/png/spec/1.0/png-1.0.pdf>

Show quote Hide quote Well I don't think that's a problem specific to PNG files. Malicious code
can be contained inside almost any data file. Any code, including malicious
code, is just a bunch of numbers, in the same way that image data (for
example) is just a bunch of numbers. The hard part (from a trojan writer's
point of view!) is in getting that code to run. I don't actually know
anything at all about writing trojans, but I seem to recall reading that in
certain circumstances it is possible to do get contained data to run as code
by arranging the data in such a way that a legitimate application which is
reading the file gets "tricked" by certain blocks of data not being quite
what it was expecting, causing the application to overwrite the area of
memory it had been allocated for writing into and causing a buffer overflow.
I think it is sometimes possible to craft the data in such a way that the
processor ends up executing code at an address supplied by the data on
return from the error. Something like that, anyway. I don't think what you
have read above means that the PNG format is more susceptible to this than
any other format (JPG for example) and I think that these days such tricks
are fairly well locked down by the OS, and by anti virus programs.

Mike

Mike Williams wrote:
Show quoteHide quoteI have dream, I have a dream of world where this kind of vulnerabilities
were non-existent. ..Oh boy! I'm delusional now :)

Getting back to Earth... Can you imagine, how can I explain a regular
folk or computer illiterate that one could get infected by just reading
a Webpage or diplaying an image? It's like explaining to them that they
could get harmed and infected by just opening a book or magazine for
reading.

Now, when you think about it a little - there's really
not much of a difference.

If you're asking me (constantly) about borrowing
my always latest computer-journal or paperback
(or whatever printed media) ... without returning
the favour that means... then I may decide, to spray
the pages the next time with something that gives you
"horrible runs" the next few days.

So, what it always and everywhere boils down to is, that:
1. You need to trust the source!
2. Your own backups are a good idea.
3. You shouldn't behave stupid ... ;-)

Olaf

Actually I think those people would be the easiest to explain it to. The
average Joe Public knows only that computers can get viruses, and that you
are much more likely to get them if you do not pay annual subscriptions to
one of the large anti-virus and internet security companies and if you fail
to upgrade to the next all singing all dancing superbly better and safer
version of Micro$oft Windoze each time a new version is released. Now I
wonder who writes most of these new viruses that cause people to keep
spending their money in such a way? I wonder who might have the most to gain
financially from it . . . hmmm . . .

Mike

Mike Williams wrote:

I remember the days when anti-virus software had a virus database of
6000 (that was when Win31 was around), today they are nearly 3 million!

  It does use "chunks" with alphabetic labels to
order the file content. In that way it's designed for
expandability. New chunk types can be added and
software can be updated to recognize the new types.

  I have VB code for opening/reading PNGs. Only a
few chunk types are required for that. Others can just
be ignored. So sometime down the line someone might
create a chunk type with the name "EVIL" and write
a nasty function in there. But it wouldn't matter because
no graphic software will recognize that chunk. They'll
just ignore it. Even if they did recognize it, they'd need
to do something with the data. It's not as though a
graphic viewer is finding chunks and just executing the
bytes that follow.

Mayayana wrote:

I like expandability :)

I see. Interesting details Mayayana. Thanks for explaining this!

I wonder whether there has been a case of infections or attacks via
opening data files in the past.

    http://www.microsoft.com/technet/security/bulletin/ms04-028.mspx

Mike

Mike Williams wrote:
" Buffer Overrun in JPEG Processing (GDI+) Could Allow Code Execution.
Maximum Severity Rating: Critical. Recommendation: Customers should
apply the update immediately. "

" A buffer overrun  vulnerability exists in the processing of JPEG image
formats that could allow remote code execution on an affected system. "

" An attacker who successfully exploited this vulnerability could take
complete control of an affected system. "


Aha!!!

So I guess software defect is no longer taken seriously. I remember
companies like Rational fully dedicated to debug enterprise software. It
seems MS does not invest in software defect detection, and programmers
don't read books like Code Complete anymore. No longer important for the
industry I guess ? Consumers have already learned to just keep upgrading
and rebooting for patches.

On 17/08/2010 04:19, Nando wrote:
Show quoteHide quoteAnd you can create thousands of lines of code which are 100% bug free?
Bugs exist. You can test for some things, but it is impossible to test
for every combination.
Once you know about it, it's (normally) easy to fix, but you have to
have an idea of what to look for...

I very much doubt it, although I think that the PNG file does contain
certain flags that can instruct the actual decompression engine to modify
its behaviour in certain ways.

To be perfectly honest I don't know anything at all about the details of the
PNG image format but according to various bits of information on the web
page to which I recently posted a link it would appear that the format
contains a number of things which would allow different applications to
achieve different levels of compression. I was particularly interested in
the fact that the format compresses each horizontal scanline separately, and
that there are five standard compression filters available, each of which is
best suited for compressing specific kinds of scanline image data.
Apparently a different compression filter (one of the five available) can be
applied to each individual scanline (the filter number is obviously included
in the compressed data for each line). This means that by analyzing the
image data line by line and intelligently choosing which of the five
available filters is best suited to each specific horizontal line of a
bitmap, an application can achieve greater compression than some other
application that either uses a single filter throughout or that does not
choose the filters intelligently. I think that is probably one of the main
reasons why certain applications are better at producing lower file size
PNGs than others, although it seems to be a fairly complicated format and
there are probably others.

Mike

Mike Williams wrote:
Interesting

Show quoteHide quoteThe format does seem quite complex and advanced. That would definitely
explains the different PNG sizes, compression levels without being tied
up to a single format-version or compression format. No wonder it is the
World Wide Web Consortium (W3C)'s standard :)

Thanks a lot Mike! That solves the mystery. Hope there isn't any file
format out-there implementing my wild thought of embedding decompression
engines ;)

On 15/08/2010 04:33, Nando wrote:
UPX does, but then it's an executable anyway so expected.

A couple of side notes that might be useful:

* I'm not certain, but I think WIA is XP-only.

* If you look at planetsourcecode for Peter
Scale you'll find sample projects that provide
straight VB code for many graphic operations,
including not only "nearest neighbor" bilinear
resizing but also bicubic. (Though if I remember
correctly, starting with XP a basic StretchBLT
can use bicubic.)


Show quoteHide quote

http://www.planet-source-code.com/vb/scripts/ShowCode.asp?txtCodeId=72401&lngWId=1


Show quote Hide quote

Abhishek wrote:
Thanks Abhishek!!

Show quoteHide quote

RegClean
create user on AD server
the vb letter
Problem automating page in IE 8
Intermittent problem in data transfer MSAccess to Oracle using VB
Form Z order across the divide
Are PDB files used by VB6
Creating html from vb
Casting in VB6
Predefined gradients