On 2 Apr 2012, at 02:05, Aleš Keprt wrote:
> So how many colours are possible per line in this format? Or what is possible
> in this picture format?
The number of colour changes per line depends on the image width, as CLUT
changes are only made outside the image. That gives 6 dynamic and 10 static
for full 256-pixel width, but up to 11 dynamic and 4 static for 96-pixel narrow
images.
> Also, I think that the converter could possibly de-noise the picture before
> or after the conversion.
Most of the conversion is using traditional methods — Heckbert's median cut to
reduce to the full SAM palette, then Floyd-Steinberg dithering to apply it.
The result of that will be close to what you'd get converting it in a typical
desktop image-editing package. Of course, there's a second step conversion to
reduce to the CLUT size, but it aims to keep the image as close to the original
converted image as possible. Reducing the dithering ('noise') would mean
compromising on pure colours, which is something that should probably be done
interactively on a per-picture basis.
> The viewer is quite straighforward, all the colour magic lies in the
> converter.
The core viewer code is short, but there's more to it than meets the eye! The
start alignment and dynamic colour count depends on the width of the image
being viewed. There are 6 self-modifying points used to inline counters and
pointers, since there's little time to make decisions at runtime.
The converter is still very important, of course, and my proof-of-concept
script has certain deficiencies. I'm hoping that having a released native
viewer will mean it can be included as an output format in existing SAM image
conversion utilities, where the conversion will get the extra attention it
needs, and by someone that knows more what they're doing!
Si
