Efika 5200B Project Reggae on Efika in category Multimedia proposed by Grzegorz Kraszewski on 21st February 2006 (accepted on 20th March 2006) [View Full Project]

Blog Entry

	GIF - Generally Indigested Format ;-) posted by Grzegorz Kraszewski on 27th June 2007 Full GIF87a support is almost done. The only missing thing is deinterlacer. Even in its current, incomplete stage Reggae decoder seem to be the one following specification most accurately, copmared to other decoders available on MorphOS. The gif.datatype for example ignores tiled, or scattered images completely, it decodes only the first tile and assumes its dimensions are dimensions of the whole image. There are two common applications of scattered GIF-s, both a bit outdated, but decoder should support them. The first one is breaking 256 colors barrier with different local palettes. This feature has been obsoleted with PNG format (except of high color animations). The second application of scattered GIF-s is to get some nice visual effects while loading the image tile by tile. This effect when used in GIF87a, relies on slow transmission (modem era...), 89a flavour provides better means (delays specified explicitly). An internal decoder of IBrowse has other issue - for some weird reason it assumes background color to be black always. It goes unnoticed usually, as most GIF-s cover the whole area with contents. There are some GIF-s however, when it generates irritating visual effects. It seems the decoder also lacks of some graphic replacement methods defined in 89a specification. Playing with GIF-s I've introduced an interesting idea to Reggae - a metaformat for images and video. There are many image formats with non-linear pixmap scanning, GIF is one of them (a single tile is linear, but one frame may be composed of many tiles in random order, they may even overlap each other). Then to deliver a linear pixmap, Reggae decoder has to create a framebuffer in memory. It is not a problem usually, but may be if the image is really big. I have an example GIF image requiring 37 MB of memory for framebuffer. This framebuffer also implies data copying (from framebuffer to the display device). A memory saving viewer can use metaformat instead of fetching complete frames. In the simplest case meta stream is a series of "orders" for application to render pixmaps in specified places. Every order consists of taglist based header and optional data chunk. Two commands - rectangular pixmap and filled rectangle are enough to render any GIF image/anim. The metaformat is now used internally by gif.decoder, but will be published in the near future. Then it is possible to write a viewer able to display parts of extremely large images using very low amounts of memory. Viewing and processing 40 Mpix images on Efika? Why not? :-) It may be not extremely fast - but for sure it is possible. The flexibility of metaformat will allow me to extend it in the future. One of obvious extensions is rasterizing vectorial graphics.