Re: CALL for DISCUSSION: eXIf 20170115

On 31 January 2017 at 21:42, Willem van Schaik <[email protected]> wrote:

> OK, I work for Cisco, we own WebEx. I use WebEx to just have a phone
> call with a colleague. And then most time we switch on video to see each
> other.

Ok, I have already understood very well by now that you serve
customers who do not care for bandwidth; but...

> How many GB's do you think will at that moment be transferred ?? Nobody
> cares, the capacity is there.

A very incorrect generalization. Fit for your use case and many
others, but unfit for yet many others.

In the past 5 years I worked, among other things, on mobile software
development and Internet of Things. It's a different world out there,
a world where entirely different sorts of bandwidth are important.

For example, imagine a directory containing hundreds or sometimes even
thousands of digital assets, many of which are PNG images, to be
flashed onto a mobile device. Some tiny, some small, some
medium-sized, none of them large. The hardware engineers are tuning
the CPU clock to find a good compromise between battery life (the
slower the CPU, the better) vs. quality of user experience (the faster
the CPU, the better). The software engineers are tuning the software
performance. I/O is a highly significant bottleneck today, as it was
20 years ago, as it was 50 years ago. Economizing CPU cycles is key.
Optimize file size. Minimize cache misses. Do anything that can
possibly be done. Fit 3 files instead of 2 into this RAM memory area.
Fit 80 files instead of 50 into that flash memory area. Throw out all
metadata, keep only the bare essentials: gAMA, cHRM, iCCP, because
these ones actually matter in rendering. (That is, when images aren't
just re-rendered in sRGB; in the other case, all metadata gets thrown
out.) Thank you, PNG Group, for giving us compressed iCCP.

The Internet of Things has been the most interesting. It was quite
awesome when we upgraded the microcontroller from 32KB to 64KB (yes,
that is "sixty-four kilobytes") of RAM. Not for PNG use, mind you. At
the core, I'm a compiler development guy.

> But adding 1000 lines of code to a piece of existing software is a "real
> cost" to a company, that they try to avoid at all means.

You're talking about 1000 lines of code as if zlib.h does not exist.
Which, in your case, may not. In my case, zlib.h is as available as
stdio.h. (I'm talking about Windows, Linux, Mac. I also know that to
be the case for BSD. I do not know your use case.)

That is considering that you write code that does elementary things,
and that you're writing it in C. (I specifically mean that you don't
actually process the PNG *image*). But if you write in Python, or in
any other modern scripting language (since we're talking 2010's not
1990's, aren't we), "import zlib" is one line and
"zlib.decompress(my_bytes)" is another. Done!

I'm not saying that you're wrong. I'm saying that it's very wrong to
assume that my need for compression is something to be dismissed, just
because you happen to not share my technical background or
perspective.

And let me tell you one more thing, right on the topic that we are
currently discussing: EXIF for digital photography. I looked at your
sample code, and you don't do any CRC checks, although, in the spirit
of PNG format guarantees for data integrity, you should. (Simple, but
not simplistic, right?...) But even more so, you should do so for EXIF
in particular. Digital photography involves flash cards and
electronics that sometimes malfunction, and data corruption does
occur. Not too often, and not so much if one invests in quality (more
expensive) memory cards, but it does happen. And to get the CRC32
code, you either include zlib.h, or implement your own, or (if you
have the luxury of ARM64) you may get that directly from the CPU.

I simply fail to see how you're talking about 1000 lines of code,
unless you're willing to give more details about your specific use
case. All I see is one or two lines of code calling decompression in a
scripting language; or 5 or 6 or some other single-digit number of
lines of code calling decompression in C or C++.

> PNG is twenty years old, but times have changed.

Some things change and other things don't. Compression is still
important, just not to the same users, and not to the same use cases.

Sincerely,
Cosmin

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