Iconic fails with palette images on certain formats

[jPV]

If you have created icons from palette brushes, Iconic fails to save them in certain formats. Tested on MorphOS.

Code: Select all

@REQUIRE "iconic"

f = {
"#ICNFMT_AMIGAOS",
"#ICNFMT_AMIGAOS35",
"#ICNFMT_AMIGAOS40",
"#ICNFMT_MACOS",
"#ICNFMT_NEWICON",
"#ICNFMT_PNG",
"#ICNFMT_WINDOWS"
}

CreateBrush(1, 32, 32, {Palette=#PALETTE_OCS, FillPen=31})
CreateIcon(1, {{Type=#BRUSH, Image=1}})

CreateBrush(2, 32, 32, #WHITE)
CreateIcon(2, {{Type=#BRUSH, Image=2}})

For Local i = 0 To ListItems(f) - 1
	Local err = ?SaveIcon(1, "ram:" .. UnrightStr(f[i], 8) .. "_PAL.info", GetConstant(f[i]))
	DebugPrint("PAL", f[i], IIf(err, GetErrorName(err), "OK"))
	err = ?SaveIcon(2, "ram:" .. UnrightStr(f[i], 8) .. "_RGB.info", GetConstant(f[i]))
	DebugPrint("RGB", f[i], IIf(err, GetErrorName(err), "OK"))
Next

Output:

PAL #ICNFMT_AMIGAOS OK
RGB #ICNFMT_AMIGAOS OK
PAL #ICNFMT_AMIGAOS35 OK
RGB #ICNFMT_AMIGAOS35 OK
PAL #ICNFMT_AMIGAOS40 Error saving icon!
RGB #ICNFMT_AMIGAOS40 OK
PAL #ICNFMT_MACOS Error saving icon!
RGB #ICNFMT_MACOS OK
PAL #ICNFMT_NEWICON OK
RGB #ICNFMT_NEWICON OK
PAL #ICNFMT_PNG Error saving icon!
RGB #ICNFMT_PNG OK
PAL #ICNFMT_WINDOWS Error saving icon!
RGB #ICNFMT_WINDOWS OK

[jPV]

This also depends of the palette depth. Try "CreateBrush(1, 32, 32, {Palette=#PALETTE_GRAY8, FillPen=1}) " and also #ICNFMT_AMIGAOS35 and #ICNFMT_NEWICON fail.

[airsoftsoftwair]

If you have created icons from palette brushes, Iconic fails to save them in certain formats. Tested on MorphOS.

Well, actually most of what you're seeing here is more like a feature than a bug but I have to admit that Iconic is not that well-documented so you can't know it. There are some further limitations on icon formats which aren't described in the documentation:

- macOS icons: palette images must not use a different depth than 8
- Windows icons: only depths 1, 2, 4, and 8 supported for palette images
- AmigaOS4 icons: palette images not accepted at all because AmigaOS4 icons must have an RGB icon
- PNG icons: palette images aren't accepted because I'm not sure if palette PNG icons are supported at all? All PNG icons I have seen are 32-bit RGB+alpha channel icons... have you ever seen a palette-based PNG icon?

So these remarks should explain the behaviour you're seeing. Nevertheless...

This also depends of the palette depth. Try "CreateBrush(1, 32, 32, {Palette=#PALETTE_GRAY8, FillPen=1}) " and also #ICNFMT_AMIGAOS35 and #ICNFMT_NEWICON fail.

...this might actually be a bug. But I'm not sure yet. Can you post a full MCVE?

[jPV]

So these remarks should explain the behaviour you're seeing.

I wonder if it would do any harm if Hollywood would automatically convert them to RGB in the cases it's needed? Would be more convenient than taking all these variations into account...

This also depends of the palette depth. Try "CreateBrush(1, 32, 32, {Palette=#PALETTE_GRAY8, FillPen=1}) " and also #ICNFMT_AMIGAOS35 and #ICNFMT_NEWICON fail.

...this might actually be a bug. But I'm not sure yet. Can you post a full MCVE?

Here's an example that tests about all depths with those formats:

Code: Select all

@REQUIRE "iconic"

f = {
"#ICNFMT_AMIGAOS35",
"#ICNFMT_NEWICON"
}

For Local j = 2 To 8
	Local colors = Pow(2, j)
	CreateBrush(1, 32, 32, {Palette=GetConstant("#PALETTE_GRAY" .. colors), FillPen=3})
	CreateIcon(1, {{Type=#BRUSH, Image=1}})

	For Local i = 0 To ListItems(f) - 1
		Local f$ = "ram:" .. UnrightStr(f[i], 8) .. "_" .. PadNum(colors, 3) .. ".info"
		Local err = ?SaveIcon(1, f$, GetConstant(f[i]))
		DebugPrint(f$, IIf(err, GetErrorName(err), "OK"))
	Next
Next 

Output from that is:

Code: Select all

ram:AMIGAOS35_004.info Error saving icon!
ram:NEWICON_004.info Error saving icon!
ram:AMIGAOS35_008.info Error saving icon!
ram:NEWICON_008.info Error saving icon!
ram:AMIGAOS35_016.info OK
ram:NEWICON_016.info OK
ram:AMIGAOS35_032.info OK
ram:NEWICON_032.info OK
ram:AMIGAOS35_064.info OK
ram:NEWICON_064.info OK
ram:AMIGAOS35_128.info OK
ram:NEWICON_128.info OK
ram:AMIGAOS35_256.info OK
ram:NEWICON_256.info OK

So it seems to fail with 4 and 8 colour icons. A funny thing is that it still writes these files despite reporting the error. The files just don't contain the requested NewIcon or GlowIcon data, but have the AmigaOS fallback icons. And actually the code in the original report also produced files for failing MacOS, PNG, and Windows icons, but they're broken with filesizes from zero to few bytes. Maybe these files shouldn't be written at all or be deleted if there was an error?

Another issue I noticed with this test, is that NewIcon images are corrupted, at least from colors 16 to 256. It might be a bit hard to spot that with this test that produces dark images, but it's quite visible with the lesser colored icons at least. Icon graphics are striped or otherwise distorted.

[airsoftsoftwair]

I wonder if it would do any harm if Hollywood would automatically convert them to RGB in the cases it's needed? Would be more convenient than taking all these variations into account...

Actually, this was a design decision done on purpose because if I were to write an icon editor or something like that I'd never ever want the icon saver to modify/remap the pixel data in any way because this usually leads to worse quality. That's why Iconic was designed to simply reject images if they don't fit the exact format it expects. I think that behaviour makes sense because when it comes to icons you usually don't want the icon saver to mess with the pixel data you provided but you want it to save the *exact* pixel data you provided.

Btw, these restrictions aren't some artificial Iconic restrictions or anything. For example, the Windows icon format only supports depths 1, 2, 4, 8 for palette images so there's no way for Iconic to save a Windows icon that uses depth 5. Of course it could convert a depth 5 image to a depth 8 image but then there could be collisions because there could already be an image of depth 8 inside the icon. It's all rather complicated so I think it makes sense for Iconic to simply reject icons that don't fit the format expectations instead of trying to make assumptions and conversions.

So it seems to fail with 4 and 8 colour icons. A funny thing is that it still writes these files despite reporting the error. The files just don't contain the requested NewIcon or GlowIcon data, but have the AmigaOS fallback icons. And actually the code in the original report also produced files for failing MacOS, PNG, and Windows icons, but they're broken with filesizes from zero to few bytes. Maybe these files shouldn't be written at all or be deleted if there was an error?

Yes, that's definitely something that should be changed.

Another issue I noticed with this test, is that NewIcon images are corrupted, at least from colors 16 to 256. It might be a bit hard to spot that with this test that produces dark images, but it's quite visible with the lesser colored icons at least. Icon graphics are striped or otherwise distorted.

Ok, thanks for reporting. I'll check this.