• Art - GIF_INFO.004

    From Barry Martin@454:1/1 to All on Tuesday, May 15, 2018 08:12:00
    [ANSIART]

    ===============================================================================

    To: DIRK LOEDDING Number: 4581
    From: GENE KWIECINSKI Refer #: None (Echo)
    Date: 01-23-01 23:19 Recvd: No
    Subj: Re: bulk zip batch file? Conf: 63 I_DOS.Tips
    BBS: The Safe House -------------------------------------------------------------------------------


    I couldn't tell you exactly how it's formatted, but I'd imagine you
    need a bit for each of the 3 colours that define a pixel, times
    whatever your bit depth is, and that can be a lot of bits per pixel.

    So how is it that a .GIF or .JPG file can be so small compared to the DL>.BMP it was converted from, without any apparent loss of picture DL>quality/information?

    BMPs (BitMaP) are strictly uncompressed image data, as if you had 2
    nested loops and just grabbed an entire image pixel-by-pixel. Eg, a 640x480x256 image would be 640x480B large (256 colors == 1 byte/pixel)
    or around 300kB (add some overhead for headers, end-of-row, color map,
    etc.). A 1280x1024x256 would be over 1.2MB. Make that 24-bit color,
    and that balloons up to over 3.6MB.

    A GIF compresses data linearly, ie, it takes raw data and compresses it,
    so that a 128 and 129 won't compress at all (lossless, after all). A
    JPEG/JFIF compresses based on image data, so that 128 is close enough to
    129 for it to figure, "Hey, close enough", and compresses 'em as 2
    same-color pixels, plus it knows enough about hues, saturation, and
    other color factors, not just the blind r/g/b conversion, so that it'll compress more intelligently, if the colors are *VISUALLY* similar
    enough.

    Eg, if you have a 640x480x256 image of all blue with one aqua pixel in
    the middle somewhere, a GIF will compress and reconstitute it to the
    blue field with one aqua pixel, whereas a JPEG will compress it to one
    big blue field, tossing the "anomaly" as useless.
    ---
    þ SLMR 2.0 #åñjw þ Rook! Godzirra!
    þ RoseMail 2.55á: ILink: FONiX Info Systems * Binfield, Berkshire UK




    ¯ ®
    ¯ Barry_Martin_3@ ®
    ¯ @Q.COM ®
    ¯ ®


    ... Plan to be spontaneous tomorrow.
    --- MultiMail/Win32 v0.47
    þ wcECHO 4.2 ÷ ILink: The Safe BBS þ Bettendorf, IA

    --- QScan/PCB v1.20a / 01-0462
    * Origin: ILink: CFBBS | cfbbs.dtdns.net | 856-933-7096 (454:1/1)