Re: CALL for DISCUSSION: eXIf 20170115

On 30 January 2017 at 07:47, Glenn Randers-Pehrson <[email protected]> wrote:
> On Mon, Jan 30, 2017 at 12:20 AM, Greg Roelofs <[email protected]> wrote:
>> How many of the iTXt's were compressed?
>
> Also, what was the size distribution of the tEXt chunks?  If they're small,
> they shouldn't be compressed, so it would not be surprising that they
> weren't.

tEXt and friends are red herrings. They are meant to be read easily by
humans and extracted by standard Unix tools, so compressing them
defeats the purpose, at least in part. Moreover, deflate compression
is not usually effective for text under 1KB, while tEXt chunks are
typically brief.

EXIF is different. It is more like ICC profile data. It is always
non-trivial in size, and is eminently compressible because of the
embedded thumbnail stored as raw pixel data. (Conversely, EXIF is not
compressible when the thumbnail and preview image are stored as
JPEGs.) The usual compression rate of large text is approx. 3:2 (and
it is way smaller for smaller text); EXIF compression goes as high as
approx. 2:1.

EXIF can be compressed outside the PNG spec by replacing the
uncompressed thumbnails with JPEG-compressed thumbnails. The same goes
with preview images, although those ones are almost always compressed,
in my experience.

Someone suggested that we should approach the EXIF standard group and
have PNG compression introduced besides JPEG. I personally doubt
that's going to work. This group is JEITA, an association of Japanese
electronic manufacturers, and I personally do not see a way to get
this proposed, unless we develop a relationship with at least one
JEITA member.

To me, compressing EXIF altogether makes more sense than modifying
EXIF to compress the embedded images in the PNG format.

Sincerely,
Cosmin

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot