IFF (ILBM) file format : saving images with less than 256 colors

[GoogleCodeExporter]

IFF files saved by Grafx2 can only be loaded by Deluxe Paint 4.5 or later 
because only these expect 8 bitplanes in an image. The hardware of the OCS 
(Orginal ChipSet, such as used on Amiga 500) couldn't exceed 6 bitplanes, so 
these images can only be displayed on Amiga AGA. (tested fine on an emulator : 
X-Man's 'Evil Nun' saved as LBM can be edited just fine in Deluxe Paint 4.5 AGA)

There is demand for supporting files that can be saved directly in an IFF 
variant directy supported by the older Amiga software.
The most frequently used modes are 16 and 32 colors.

Original issue reported on code.google.com by yrizoud on 11 Sep 2012 at 12:57

[GoogleCodeExporter]

Ref: http://eab.abime.net/showthread.php?p=838679

IMO, making grafx2 enforce color restriction everywhere may be a rather large 
change.

In any case, a 16-color IFF file loaded in Grafx2 and edited without using 
colors > 16, should be re-saved in the same variant of the format (4 bitplanes) 
without querying the user.

Original comment by yrizoud on 11 Sep 2012 at 1:04

[GoogleCodeExporter]

Looks like I had encountered the IFF formats issue two years ago and forgot 
about it:
http://code.google.com/p/grafx2/issues/detail?id=365#c8

This week I wrestled with IFF specification, and got a local prototype working 
for saving the actual ILBM variant. Still have to think how to integrate it 
well in Grafx2. A specific screen with IFF settings, like we did for C64 ? An 
auto-detection on used colors ? (counting them is needed anyway to warn a user 
if his image uses more colors than format allows)

Original comment by yrizoud on 15 Sep 2012 at 12:47

[GoogleCodeExporter]

Implemented in r1993 : The format selector now proposes pbm AND lbm.
pbm is the chunky 256-color mode that Grafx2 has always used, the one it 
mistakenly called "lbm" until now.
If you choose lbm, Grafx2 will save in the interleaved model as described by 
the Electronic Arts 1985 specification. At the moment, Grafx2 will detect how 
many bitplanes should be saved according to the colors you used, ie. if the max 
color is #13 it will save a 4-bitplane image with a 16-color palette. If you 
use more than 32 colors your image will not be loadable on Amiga OCS, but the 
file is still reloadable in Grafx2, XnView, Deluxe Paint 4.5 or 5 (Amiga) or 
Deluxe Paint 2E (MS-DOS).

Original comment by yrizoud on 15 Sep 2012 at 6:22

• Changed state: Accepted
• Added labels: Milestone-2.4
• Removed labels: Milestone-NotPlanned

[GoogleCodeExporter]

I'm not so happy with that. It means if you open an image and start editing the 
palette to play with shades, without changing pixels, then your changes are 
lost without a warning.

I think we need a way to mark colors as "unused" in the palete. It would work 
this way:
 * Using "Reduce" or "Zap" mark affected colors as unused
 * loading an image with less than 256 colors pads the palette with "unused" color if "clear palete" setting is on
 * In the palette editor, show them with a pattern (maybe a black X or so)
 * They can still be selected and edited in the palette. Editing them marks them "used" again
 * when exiting the palette editor, make sure the selected color is not an unused one
 * make sure unused colors can't be used for drawing: make it impossible to select them in the palette swatches, shade editor, gradient editor; and make sure they are not picked by effects like transparency and alpha.

The last step is the most complex one. Maybe we don't need it, instead, make 
these colors flash or glow black/red using the colorcycling feature so they are 
easy to spot for the user. Up to them to take action: define the color again, 
replace it with another one, redraw part of the image, ...

Ideally, unused colors should escape the RGB constraints and stay available for 
the UI. But that conflicts with colorcycling them.

Original comment by pulkoma...@gmail.com on 16 Sep 2012 at 6:09

[GoogleCodeExporter]

I know it's not ideal: it produces the smallest file that faithfully records 
the image's appearance, but unused palette entries will be lost.
In practice, I don't think it will be an issue because if a user makes several 
16-color IFF images for an Amiga game (sprites, scenery etc.) they are intended 
to be used with the same palette. If one of them gets reduced to 8-color 
because it didn't use high color indices, then the user still has the complete 
palette in all his other files.

If there was room in the Save screen I'd have put a sub-format selector there, 
but re-organizing it seemed too big a change for an almost-complete v2.4. (risk 
of making questionable UI choices)

Original comment by yrizoud on 17 Sep 2012 at 4:07

[GoogleCodeExporter]

Of course, that palette stuff is a 2.5 (or 3.0?) thing.
Let's release 2.4 first !

Original comment by pulkoma...@gmail.com on 19 Sep 2012 at 7:02

[GoogleCodeExporter]

Original comment by pulkoma...@gmail.com on 28 Sep 2012 at 6:28

• Changed state: Fixed