[lug] Are xcf (gimp) files that much smaller than bmps?

[jjh-blug at vieorhythms.com]

>>>>> "Peter" == Peter Hutnick <peter-lists at hutnick.com> writes:

>> I accidentally found out that windows does support some forms of
>> bitmap compression, and the Gimp will create them.  Take the bitmap,
>> switch to index mode (Ctrl-I) and create an index with a custom
>> palette.  Then do a Save-As and pick bmp.  Gimp will prompt you to do
>> RLE (Run Length Encoding) compression on the image.

Peter> Did anyone else get a second copy of this?  I can't tell if it is
Peter> something quirky with this list or my fetchmail . . .

That was my fault, this was actually my first post but I had the wrong
address in my From header.  I imagine this one went into the blug admin
folder and was then approved for submission.

Peter> Anyway, I wasn't going to pick this nit, but since I found it in
Peter> my inbox again . . .

Peter> RLE isn't /really/ compression.  It is a more efficient method of
Peter> storing graphics data.

In my own defense, I'll disagree with you here and argue that RLE is
data compression.

The definition of data compression from our very own NIST:

     http://glossary.its.bldrdoc.gov/fs-1037/dir-010/_1415.htm

     1. Increasing the amount of data that can be stored in a given
     domain, such as space, time, or frequency, or contained in a given
     message length.

     2. Reducing the amount of storage space required to store a given
     amount of data, or reducing the length of message required to
     transfer a given amount of information.

Peter> I submit that this is a difference /with/ a distinction.

I will submit that RLE is compression although it is quite simple.

RLE definition from Mark Nelson's Data Compression information site:
     
     http://datacompression.info/RLE.shtml
        
     Run Length Encoding is a conceptually simple form of
     compression. RLE consists of the process of searching for repeated
     runs of a single symbol in an input stream, and replacing them by a
     single instance of the symbol and a run count.

For those who are not familiar with RLE check out
http://www.rasip.fer.hr/research/compress/algorithms/fund/rl/index.html

It has a pretty good explanation of RLE and some example
implementations. One of which is the Windows bitmap RLE scheme.

Peter> I'd say that compression is when you look at a set of data and
Peter> find some way to represent it in an "equivalent" way (the meaning
Peter> of equivalent varies with lossy and lossless compression) with
Peter> fewer bits.

Peter> I'd say that RLE is an example of storing data in a way that
Peter> accounts for that type of data's properties to store them more
Peter> efficiently.

Peter> And as a litmus test: when I upgraded my the controller for my
Peter> hard disks from an MFM to an RLL controller did the new
Peter> controller "compress" my disks?

Actually, I would say that yes, it did "compress" your disks as RLL
recording involves writing more bits per track than MFM.

http://kb.indiana.edu/data/adlt.html :
     
     RLL recording involves squeezing more bits into a track. This is
     accomplished by using a larger number of sectors (27 rather than 17
     or 19), and requires a better quality drive medium than that
     required for MFM. RLL recording results in a roughly 50% increase
     in capacity over MFM recording, given the same physical hard
     drive. 

This falls under the 1st definition given above since the amount of data
(bits) stored in a give space (the track) was increased.  In other words
the packing density of the hard disk media was increased.  The ITS
definition of data compression (listed previously) specifically lists
increasing the packing density as an example of the data compression.

Definition of packing density also from NIST:

     http://glossary.its.bldrdoc.gov/fs-1037/dir-026/_3824.htm

     The number of storage cells per unit length, area, or volume of
     storage media. Note: Examples of packing density are the number of
     bits or characters stored per unit length of magnetic tape and the
     number of bits stored per unit length of track on an optical disk.

Of course, if your disk is still encoded as MFM, and you are using an
RLL controller (which is backwards compatible with MFM drives) then
the packing density didn't change and as such no compression was
performed.  The compression would come in if you re-encoded the same
physical hard disk media as RLL.

Peter> What is my obsession with ancient hardware lately?

No, clue, but it is a good obsession :-).

Peter> -Peter

enjoy, and thanks for making me do some research.

-jeremy


-- 
========================================================================
 Jeremy Hinegardner                              jeremy at hinegardner.org