in reply to encode/decode images

What's the idea behind the encoding?  If it's that you can't/don't want to store binary data directly, you could try ASCII85/Base85 encoding, which uses 85 "printable" characters (instead of 64), and thus is slightly more compact (25% (base85) vs. 33% (base64) larger than the binary input).  Otherwise, I don't see many possibilities to significantly compress your ascii-fied image data any further, as the original JPG input already is compressed...

Note that there are several slightly different versions of ASCII85.  A CPAN search shows the related Perl module Math::Base85 which implements the RFC 1924 variant. Implementations of the Adobe variant might be found in the respective PDF/PS modules, though PDF::API2::Basic::PDF::ASCII85Decode seems to provide decoding only...

Update: FWIW, Nicholas Clark seems to have written such a module. Does anyone happen to know if/under what name that ended up on CPAN?

Replies are listed 'Best First'.
Re^2: encode/decode images
by Anonymous Monk on Feb 25, 2009 at 20:21 UTC
    I was hoping to store the image as text to avoid having to bother with any binary data type stuff.

    Thanks

[reply]
      That's hilarious! You want to store a jpg in your database without "bothering" with "any binary data type stuff". And you're worried about how much space it will take up. Something here just isn't adding up.

      Let's take a step back. Why are you storing images in your database? In my experience this is a bad idea 100% of the time. Instead, store your images on disk and store the path in the database. If you have multiple servers use NFS or even Amazon S3 to store the file. But not your RDBMS - that's not what it's for.

      -sam

[reply]
      JPEG images ARE just binary streams. You can encode them to various ASCII/text type encodings, but all of those will increase the size of the resulting string/stream/file. You could transform the image to some pure-text image format, like XPM, but for typical JPEGs that will increase the size a lot more than a simple base64-type encoding of the original JPEG data.

      Bottom line: use "raw" binary strings when dealing with inherently binary data, unless you really need some encoding (for instance, when mailing the data or encapsulating it in an XML file).

      update: Postgres does have facilities for dealing with binary data directly. So read the docs for the right module.

      "What should it profit a man, if he should win a flame war, yet lose his cool?"
[reply]

In Section Seekers of Perl Wisdom