#36 suggestion: Export layers separately

[SD Snatcher]

When a file format is composed of one or more layers (i.e.: background vs sprites), or one or more combined images (i.e.: ZX-Spectrum flickering formats like .mg2), it would be nice to have an option in recoil2png to export each layer as a separate image.

This allows easier post-processing with modern tools.

[Grim]

In abydos this is done for some formats by including a patched version of recoil. At least then there is just two layers they are stored after one another, then in a final step recoil combines them. Just disabling this final step, ApplyBlend(), does the trick. Then there are more than two layers it would require a more intrusive change. It would be nice if recoil could do this without patching.
My suggestion is to first change all decoding routines to always decode/unpack all layers before starting to combine them (which of course has the downside of using more memory, but it's not even megabytes we're taling about). Then have an option to disable the layers from getting combined and instead get all the layers after one another as a taller image (as already stored in memory). Or better yet, create one image per layer, but that would be a lot more work I imagine.

[Grim]

Another suggestion: Never call ApplyBlend() in the decoding step, instead always just set Frames. Then, if desired, call ApplyBlend() in a later step. For example in GetPixels(). This idea is also possible to combine with keeping the palette for indexed images. If there are two frames and the palette is no more that 16 colors the blending could be done simply by blending the palette.

[Piotr Fusik]

Not all flickering mode routines conclude with ApplyBlend(). Some construct the blended image directly. Some through ApplyAtari8PaletteBlend(). Also, the source frames are not necessarily what the original hardware displayed - e.g. even lines should be swapped, but aren't for code simplicity because the average is commutative. So, great idea, but not a trivial one to implement robustly.

What should be the layers in case of sprites? One layer of sprites or each sprite separately? Sprite colors can mix, they can be partially covered by the bitmap. There aren't many formats with sprites. In Atari 8-bit formats the sprites are usually used for additional colors and don't make any sense without the rest of the picture.

Most importantly, what are the use cases of this feature? One that comes to my mind is extracting sprites easily. Not really useful for Atari 8-bit.

Also, some formats are actually sets of tiles - in particular, fonts. Currently these are somehow combined into a single bitmap, but one might want individual elements.

[Grim]

The original reason I want the layers separately is a bit odd. I'm working on an image viewing library born from the frustration with gdk-pixbuf. I discussed replacing gdk-pixbuf with the Gnome developers (about 15 years ago) and they made a list of required features, which included support for layers . So I added it. They didn't say why exactly, it was probably just something they though a good image loading library should have. (Even thou they considered gdk-pixbuf practically deprecated back then they never got around to replace it, and never added support for layers either. Now they consider the whole concept of image viewers deprecated in favor of photo managers and web-galleries. So this whole reason is kind of just historical by now.)

For me personally it's just because I find it very interesting to see how some multi layer images are constructed. And, as you point out, people might want to extract sprites and other low level building blocks, possibly to edit them and reconstruct the image.

In my library the concept of layers is basically just something that can be toggled on and off, exactly how the layers are combined internally is a black box. But that might not be appropriate for RECOIL, I guess. Is it possible to come up with a generic description of layers that fits every use case within RECOIL? Let's say a concept of main layers which are always blended together, and sub layers (of each main layers) which are always drawn on top of each other? I guess it would make sense if each sprite is a sub layers then (but I'm aware I don't have the full picture). Are there cases where sub layers are drawn in different ways? Can these ways be enumerated? Or are there cases that are just too odd to fit this mold? All this only makes sense if it can result in a good generic API. If the API would get too complex with exceptions for every other format it's probably a pointless endeavor.

A more practical way might be to only present the image as a set of layers if it can be done easily, otherwise not bother (retain the current behavior). A parallell to the usage of a palette: an image could be presented as having a palette only if not too much funky stuff is done with it. For example it's easy to just expand the palette for Amiga EHB, but for HAM it gets too complicated to bother (unless the concept of HAM is mediated through the API, which I think crosses the line of a too complicated API).

Personally I haven't (yet) felt the need for a generic API for accessing tiles directly. But as with the palette it might make sense to be able to access an image at a lower level as a set of basic building blocks. Would it perhaps even be useful for the internals of the decoder to have a generic concept of tiles (or fonts) just as a concept of a palette? Especially if more video game hardware (as supported by the Fluff format used by Turbo Rascal for example) gets supported by RECOIL.

[Piotr Fusik]

I like the idea of exposing the flickering frames, especially now that VRR is gaining popularity.

And tiles. Some general-purpose viewers support that concept, e.g. IrfanView for TIFF "pages".

These two sound well for some major version of RECOIL.

I don't think implementing layers is worth the trouble. Very few of the 400+ formats have any sprite overlay, and even then, the layers shown separately often make little sense. That's very unlike Photoshop-style editing with layers used extensively.

Thank you for the background! I think I made an attempt to code a gdk-pixbuf plugin, but failed because the API didn't expose the filename that RECOIL needed for format recognition.

[SD Snatcher]

That's very unlike Photoshop-style editing with layers used extensively.

At least for me, being able to export the MSX screen-2 images with sprites with separate layers would be a blessing.

I could then make the necessary changes on the background with GIMP+PixelPolizei and recompose the image back to the native format.

Right now, what I have to do is decode the image with another tool that doesn't render the sprites to get the background, then generate a diff between the background and image decoded with sprites to obtain the sprite layer.

[Eugene Nine]

Amiga icons (.info) have a second image for selected vs unselected, I would like to be able to specify the second and export it as well.