Activity for Grim
-
Grim posted a comment on ticket #15
I think this is very possible to do as a separate package, with RECOIL as it is. Import only of course. (Exporting is obviously beyond the scope of RECOIL.)
-
Here is a less intrusive patch against the current version. It add an optional argument to SetSize() which lets the caller request indexed pixels (instead of RGB pixels). In that case the image will never be converted to RGB then converted to PNG, and the original palette will of course be used. Everything will still function exactly the same from the API user perspective. It would also be easy for a decoder to first request indexed pixels and at a later stage upgrade to RGB pixels (because it needs...
-
As far as I'm concerned this is issue is basically solved now with the new API. Recoil just need to provide the info for all resolutions. IMHO calculating the horisontal and vertical pixels per meter for some TV of any size is sufficient since it's the ratio between the values that matters the most.
-
I don't have any file created with the actual Image System application. So I don't know if the 192 unknown bytes should actually contain something other than zeros (but it shouldn't affect the decoding in any case). I attach one file converted with tomseditor.com (which doesn't even try to preserve any color and seems to get the load address wrong) and one converted with pyriel. Both loads fine in tomseditor.
-
Support C64 Hires Image System files
-
I don't know enough about different Amiga graphic hardware (I'm only really familiar with the original Amiga 500), but I assumed CAMG could be interpreted slightly differently depending on if you have AGA or not. Since CAMG is the only way to activate HAM (?) I also assumed it could be used by encoders outside the Amiga world. (I'm working on an ILBM encoder with HAM support myself and I would be really surprised if I'm the first one.) Regarding the aspect ratio, I didn't mean the aspect ratio of...
-
In my opinion an image for the C64 should generally have all 16 colors in the palette, even if the image only contains a subset. Perhaps if the format has a concept of a palette with fewer colors, only those colors should be included. Does such formats exist? For multi palette images I don't think the concept of an original palette is relevant, it's okay to treat them as not having a palette (same as with HAM). For flickering images it would be ideal if each frame could be accessed individually,...
-
ILBM has fields in the header for defining fine grained pixel aspect ratio (just as the pHYs chunk of PNG), even if it's often misused. I detect misuse by calculating the claimed screen aspect ratio, if it adds up to 4:3 the information is most likely correct. So (at least in some cases) it doesn't need to be mapped to any particular hardware resolution to get the correct pixel aspect ratio. It would be nice to be able to query RECOIL about the more exact pixel aspect ratio with an argument telling...
-
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...
-
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.
-
I would also lika a possibility to disable image scaling that is done only to (very approximately) match the intended pixel aspect ratio. But I guess the scaling sometimes is done because the original hardware was able to render sprites in higher resolution on top of the image (or something similar). Even if a certain format doesn't make use of that, it's less clear if the image should be considered scaled or not. As for a more fine grained pixel aspect ratio, wouldn't it be possible to just look...
-
Properly fixing this requires a lot of small changes all over the code. This patch demonstrates how to do it gradually (with only a moderate risk of breaking things in the process). It currently only preserves the palette for MSX formats (including SC2) and some others. Once the changes are done i guess ContentPalette can be removed, possibly also the RGB to indexed color conversion code, maybe even the color counting code? It is also an open question if both the RGB version and index version of...
-
This is because the way recoil works the image is converted to RGB and the palette gets discarded. The new palette comes from reducing the number of colors again, which will also cause any unused color to get lost in the process. See bug #28.
-
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...
-
The trailing bytes of the images was confusing, but now I'm quite sure it's Z80 machine code saying: add a,d di ld d,0x00 ld ix,(0xbc12) ld hl,(0xbc14) ld a,(ix+0) ld (0xbc1a),a ld b,a ld a,(0xbc18) call 0xbd0c inc hl ld a,0x80 cp l jr nz,+0x2b ld a,0xfe cp h jr nz,+0x26 ld a,(0xbc17) inc a ld (0xbc17),a cp 0x5f jr z,+0x25 ld hl,0xc000 inc ix inc d jp nz,0xbc2d ld a,0x03 jp 0xbc3a di ld d,0x00 ld ix,(0xbc12) ld hl,(0xbc14) jp 0xbc2d It seems coherent (exept for the first line which is likely a fragment...
-
With the linked source code it's no problem to understand the format well enough to decode the sample files. However it doesnt's appear likely that this format is entirely specific to ArtMaster88 (that is the version of ArtMaster for the PC-8800 series). It uses ordinary bitplanes, which isn't very hardware specific to begin with. And it obviously has features ignored by the linked source code. It's also easy to imagine ways the format could be extended. So I assume at least all versions of ArtMaster...
-
Unfortunately the two files in the attachment are the only ones I've ever seen. But I'll try find the software and run it in an emulator. I didn't think about the trailing bytes, but will try to figure something out from them. Just guessing: Maybe it could be some text in japanese (EUC-JP encoded). Or perhaps the palette HSV encoded (which I know is sometimes used on the PC88).
-
This is also the behaviour I would excpect from RECOIL_ToPalette(). An easy solution might be to keep the palette around to use, then possible, instead of calling RECOIL_CalculatePalette() (and RECOIL_SortPalette() obviously).
-
Unfortunately the two files in the attachment are the only ones I've ever seen. But I'll try find the software and run it in an emulator. I didn't think about the trailing bytes, but will try to figure something out from them. Just guessing: Maybe it could be some text in japanese (Shift-JIS encoded). Or perhaps the palette HSV encoded (which I know is sometimes used on the PC88).
-
I just figured out this simple format. There is no header and no palette, just the compressed bitplanes. The compression works like this: One control byte where the high bit set indicates a runlength and the rest of the bits are the count (unadjusted). The data is aranged in groups of three bytes, one for each bitplane. That's all.
-
Incorrect usage of MIME types
1