Imagemagick does it really "magic" with converting PNG->ICO

[vincentb1]

Hello,

Sorry for bothering imagemagick experts with a question which in fact is not really related to imagemagick. Imagemagick actually does a wonderful job, my problem is rather that I wrote a piece of java code to convert a 48x48 png icon into an ico icon, and the results slightly from what imagemagick does.

No doubt that imagemagick is not doing anything faulty, my problem is that I cannot find what I did wrong.

My aim is that the installer should create an ico file for MSWindows --- well, a simpler option would be that the ico file would also be stored inside the installer, and I would just unpack it, but I found that it would be funnier for me to write the code this way

The piece of code which I wrote is that one: http://jpicedt.cvs.sourceforge.net/view ... iew=markup

When I call it with the PNG icon which is there http://jpicedt.cvs.sourceforge.net/view ... iew=markup, with that sort of command line:

Code: Select all

java -Xmx96m -classpath the_jar_with_pngToIco.jar installer.PngToIco --overwrite  -i appicon.Cocorico.png  -o jpicedt.ico 

(these arguments cause the pngToIcoOfBmp function at line 111 to be called)

then the jpicedt.ico file which I get is different from that which I would get with convert, and the sole difference is that there is a 384 octets tailer added by imagemagick immediately after the pixel array, and also, consistently the bitmap length indicator is greate by 384 in the case of imagemagick than in my case.

So my question is about what this 384 octets tailer is ? is it part of the embedded bitmap, or is it part of the ico file. I could not understand why it is there based on the Wikipedia pages about ICO and BMP.

Any feedback is welcome --- even that sort of "you are out of scope, this is not the right place to raise such question"

Very best regards,

Vincent.

[glennrp]

Please post the ico that you are wondering about and I'll take a look.
Or you can take a look with the first thing I'd do,

Code: Select all

identify -debug coder -log %e -verbose jpicedt.ico

and maybe that will answer your question.

[vincentb1]

Here is the link to the orginal PNG picture http://jpicedt.cvs.sourceforge.net/view ... iew=markup

If I use the imagemagick command:

Code: Select all

convert appicon.Cocorico.png jpicedt1.ico

then I get this picture (jpicedt1.ico):


if now I use my java code, then I get this picture (jpicedt.ico):


Both picture look exactly alike, but imagemagick makes a little bigger file by 384 octets. Also it seems that MSWindowsXP handles better the ico produced by imagemagick as it displays the dimensions as a property in the file explorer with jpicedt1.ico, but not with jpicedt.ico. Also double-click on jpicedt1.ico opens a preview, but not for jpicedt.ico.

VBR
Vincent.

[fmw42]

Your last image was not linked

[glennrp]

The extra bytes are appended to the end of the file. Except for wasting space, they seem to be harmless; the "signatures" of the two files are identical.
I'll see if I can figure out what caused that. There's nothing helpful in the debug log (convert -debug coder -log %e in.ico out.ico)

[vincentb1]

Your last image was not linked

Sorry, when I browse on the forum I can see both images, maybe that situation about the last image was due to temporary traffic condition over the internet.

Vincent.

[vincentb1]

The extra bytes are appended to the end of the file. Except for wasting space, they seem to be harmless; the "signatures" of the two files are identical.
I'll see if I can figure out what caused that. There's nothing helpful in the debug log (convert -debug coder -log %e in.ico out.ico)

The log is there for those interested:

Code: Select all

/usr/local/projects/jpicedt/jpicedt>convert -debug coder -log %e c:/msys/1.0/local/projects/jpicedt/jpicedt/jpicedt/jpicedt/images/appicon.Cocorico.png c:/msys/1.0/local/projects/jpicedt/jpicedt/jpicedt1.ico
Enter ReadPNGImage()
  Enter ReadOnePNGImage()
  image->matte=0
  image->rendering_intent=2
  image->colorspace=13
    PNG width: 48, height: 48
    PNG color_type: 6, bit_depth: 16
    PNG compression_method: 0
    PNG interlace_method: 0, filter_method: 0
    Found PNG gAMA chunk.
    Found PNG cHRM chunk.
    Found PNG sRGB chunk.
    Reading PNG sRGB chunk: rendering_intent: 0
    Reading PNG gAMA chunk: gamma: 0.454550
    Reading PNG bKGD chunk.
    raw ping_background=(0,0,0).
    bkgd_scale=1.
    ping_background=(0,0,0).
    image->background_color=(0,0,0).
    Reading PNG IDAT chunk(s)
    Converting PNG pixels to pixel packets
    Looking for cheap transparent pixel
    ...got one.
    Found transparent pixel
  image->colorspace=13
    Reading PNG text chunk
      length: 25
      Keyword: date:create
    Reading PNG text chunk
      length: 25
      Keyword: date:modify
  exit ReadOnePNGImage()
  page.w: 0, page.h: 0,page.x: 0, page.y: 0.
exit ReadPNGImage()
c:/msys/1.0/local/projects/jpicedt/jpicedt/jpicedt1.ico
/usr/local/projects/jpicedt/jpicedt>

(The command was launched from an MSYS console, I generally uses that with IM because bash quotes are easier than MSW quotes)

Vincent.

[vincentb1]

Except for wasting space, they seem to be harmless

Just for clarification once again: I did not mean that IM was doing anything "harmful", all the opposite: without those extra 384 octets it seems that MSWindows XP handle the ico file in somehow a degraded way:

• no size (i.e. 48x48) indication in the file explorer
• no preview available when you double-click the file

So the whole purpose of my question is rather to know how those 384octets are generated and to do it also in PngToIco.java of the jPicEdt installer.

[vincentb1]

So it seems that nobody has an explanation what are those 384 octets for, and how they are generated.

Maybe somebody could send a pointer to the IM source code where this is generated and I could have a look and try & understand what that is for...

[glennrp]

So it seems that nobody has an explanation what are those 384 octets for, and how they are generated.

Maybe somebody could send a pointer to the IM source code where this is generated and I could have a look and try & understand what that is for...

It should be happening in coders/icon.c but it's not immediately obvious how.

[vincentb1]

Hello,

I downloaded http://www.imagemagick.org/download/win ... indows.zip and had a look at ImageMagick-6.8.5/coders/icon.c.

I suspect that the piece of code that adds the 384 octets tailer is in function WriteICONImage, and is starting at line 1203 like this:

Code: Select all

        /*
          Write matte mask.
        */
        scanline_pad=(((next->columns+31) & ~31)-next->columns) >> 3;
        for (y=((ssize_t) next->rows - 1); y >= 0; y--)
        {
          p=GetVirtualPixels(next,0,y,next->columns,1,&next->exception);
          if (p == (const PixelPacket *) NULL)
            break;
          bit=0;
          byte=0;
          for (x=0; x < (ssize_t) next->columns; x++)
          {
            byte<<=1;
            if ((next->matte == MagickTrue) &&
                (GetPixelOpacity(p) == (Quantum) TransparentOpacity))
              byte|=0x01;
            bit++;
            if (bit == 8)
              {
                (void) WriteBlobByte(image,(unsigned char) byte);
                bit=0;
                byte=0;
              }
            p++;
          }
          if (bit != 0)
            (void) WriteBlobByte(image,(unsigned char) (byte << (8-bit)));
          for (i=0; i < (ssize_t) scanline_pad; i++)
            (void) WriteBlobByte(image,(unsigned char) 0);
        }
      }

This code generates for each of 48 rows:

• 48 bits (6 octets) of bitmap indicating where each bit is for one pixel and tells whether the pixel is transparent
• 16 bits (2octets) caused by the scanline_pad due to rounding up the row length to a multiple of 4 octets

48 * 8 = 384 : that's it.

I think that I understood the intention, probably this is some leftover from the time when there was not any specific alpha channel for transparency and the transparency was yes-or-no.

I will try to update my java code and see whether it makes the same output and let you know when this is done.

Anyway, thank you very much for your kind support.

[vincentb1]

FYI, I have updated my java code --- see http://jpicedt.cvs.sourceforge.net/view ... iew=markup --- and now image magick and my code give exactly the same output on the icon of interest to me.

So, as for me, the issue is closed.