[Oberon] BMP; was "FPGA - Screen.Mod"

Jack Johnson knapjack at gmail.com
Wed Sep 20 17:40:57 CEST 2017


It does have a simple compression scheme in RLE (run length encoding),
basically calling out how many subsequent pixels match this one. It worked
OK for all the 8-bit images we had back then, probably even better for
2-bit.

I implemented some stuff for Targa files (way back when System 3 was new)
and that's even easier. I'm no programmer, and can't imagine doing JPEG
from scratch. FFT makes my head hurt.

I haven't looked, but uncompressed PNG can't be too bad, yeah? Probably
just a header and the raw data?

On Mon, Sep 18, 2017, 5:31 AM Paul Reed <paulreed at paddedcell.com> wrote:

> Hi Peter,
>
> > https://commons.wikimedia.org/wiki/Commons:File_types states
> > "On Wikimedia Commons, the file types we recommend are: SVG, PNG, and
> > JPEG.
> > BMP files are not allowed on Commons." without explanation.
> >
> > BMP is needlessly bulky?  Intellectual property concern?
>
> It's an uncompressed format, so only in that sense is it bulky; yet they
> recommend uncompressed PNG instead of BMP, so that can't be it.
>
> Even more confusing if you follow their link on BMP (lost in your paste),
> leading to a paragraph which says, "The simplicity of the BMP file format,
> and its widespread familiarity in Windows and elsewhere, as well as the
> fact that this format is relatively well documented and free of patents,
> makes it a very common format that image processing programs from many
> operating systems can read and write."
>
> Go figure.
> Cheers,
> Paul
>
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20170920/23a96c45/attachment.html>


More information about the Oberon mailing list