Return-Path: <robert@stvmayday.dk>
Received: from mail-vb0-f52.google.com ([209.85.212.52] verified)
  by media-motion.tv (CommuniGate Pro SMTP 4.2.10)
  with ESMTP-TLS id 5267378 for AE-List@media-motion.tv; Mon, 28 Oct 2013 22:21:45 +0100
Received: by mail-vb0-f52.google.com with SMTP id f13so5626544vbg.25
        for <AE-List@media-motion.tv>; Mon, 28 Oct 2013 14:22:54 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=x-gm-message-state:mime-version:in-reply-to:references:from:date
         :message-id:subject:to:content-type;
        bh=rN3ASyhsghm91cNKftBAf4GfMD6nbdfD224pQh5WROo=;
        b=S9IO/JGO/6wrmeYgfrb9e6vHGBT8CrXHMzyOpR2d+uACCOWdsuyFlGmBytv3O2pIGg
         yZADiU1vPUw564+wV/DFcl1jQI1COuLoIHrr8bKG6SSXZeNyiWtPwRNjUbS4HgAV/ybF
         /8mWKN7w1UG8J4pafwo8m0ymw/J9DC1Q7h/u1gtJXSXHLz63lEggknvj5gV+pTwAJ271
         Ugy2wU5LFdms5jZ2nefS1XDjKDjpDr+xyNmHit9KobExkXm9iBD5c9DDNVgSoN6EYlQ+
         Mn+awtEdkuB5LCNvteSZw+rtHg0kbIIw8EBH0WFUEHlLoMkEUS+7bSAdqzEf+8tIJ3UM
         31KA==
X-Gm-Message-State: ALoCoQnxmEJGA8gZ1fjH/ZzDEuAr9eEc2C9khnjXRU3GCpFN4eOY/gaaiO60dVAw7si7wakfZvP5
X-Received: by 10.52.165.131 with SMTP id yy3mr2612032vdb.25.1382995374630;
 Mon, 28 Oct 2013 14:22:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.58.45.66 with HTTP; Mon, 28 Oct 2013 14:22:33 -0700 (PDT)
In-Reply-To: <list-5267325@media-motion.tv>
References: <list-5267325@media-motion.tv>
From: Robert Kjettrup <robert@stvmayday.dk>
Date: Mon, 28 Oct 2013 22:22:33 +0100
Message-ID: <CAFu=taYa8nUmQY5KrJipwNJL9mECjqYnx3vrVw762SA+-Pp14w@mail.gmail.com>
Subject: Re: [AE] Quick AE Render question.
To: After Effects Mail List <AE-List@media-motion.tv>
Content-Type: multipart/alternative; boundary=001a11c2c54a0808bf04e9d3b44d

--001a11c2c54a0808bf04e9d3b44d
Content-Type: text/plain; charset=ISO-8859-1

Thanks for the explanation.
This of course makes total sense now that you describe it :-)

Robert



2013/10/28 Chris Zwar <chris@chriszwar.com>

> On 28/10/2013, at 11:41 PM, Robert Kjettrup <robert@stvmayday.dk> wrote:
> >
> > Thanks Chris for the tip about NOT using LZW compression on 16bit tiff
> files. Never thought about that could be a problem, i always leave this
> setting on. But dosent this more sound like a bug?
>
> It's not a bug, it's just the way the algorithm was designed.  LZW is a
> very old and primitive form of compression and was specifically designed
> for 8 bit files.  It looks for patterns or values that repeat themselves a
> lot, and builds up a table of these repeated values.  In an 8 bit file
> where each value is restricted to 0 - 255 there's a high probability that
> sequences of numbers will repeat themselves, especially for things that
> have an underlying structure like language.  LZW can still do very well on
> text files, for such an old algorithm.  But in a 16 bit file the range of
> values is so much bigger (0-65535) that the probability of having specific
> sets of numbers that repeat falls dramatically, and the table becomes an
> overhead.
>
> I imagine that for simple images, such as mattes, then LZW would still
> offer impressive file size advantages in 16 bit mode.  But for natural
> images such as photographs then it just doesn't work very well, and it's
> due to the 8 bit nature of the algorithm's origins.
>
> I suppose it's a case of YMMV, but in general LZW isn't recommended for 16
> bit tiffs.
>
> -Chris
> +---End of message---+
> To unsubscribe send any message to <ae-list-off@media-motion.tv>
>

--001a11c2c54a0808bf04e9d3b44d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thanks for the explanation.=A0<div>This of course makes to=
tal sense now that you describe it :-)</div><div class=3D"gmail_extra"><br =
clear=3D"all"><div>Robert</div><div class=3D"gmail_extra"><br></div><div cl=
ass=3D"gmail_extra">

<br></div><br><div class=3D"gmail_quote">2013/10/28 Chris Zwar <span dir=3D=
"ltr">&lt;<a href=3D"mailto:chris@chriszwar.com" target=3D"_blank">chris@ch=
riszwar.com</a>&gt;</span><br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class=3D"im">On 28/10/2013, at 11:41 PM, Robert Kjettrup &lt;<a href=
=3D"mailto:robert@stvmayday.dk">robert@stvmayday.dk</a>&gt; wrote:<br>
&gt;<br>
&gt; Thanks Chris for the tip about NOT using LZW compression on 16bit tiff=
 files. Never thought about that could be a problem, i always leave this se=
tting on. But dosent this more sound like a bug?<br>
<br>
</div>It&#39;s not a bug, it&#39;s just the way the algorithm was designed.=
 =A0LZW is a very old and primitive form of compression and was specificall=
y designed for 8 bit files. =A0It looks for patterns or values that repeat =
themselves a lot, and builds up a table of these repeated values. =A0In an =
8 bit file where each value is restricted to 0 - 255 there&#39;s a high pro=
bability that sequences of numbers will repeat themselves, especially for t=
hings that have an underlying structure like language. =A0LZW can still do =
very well on text files, for such an old algorithm. =A0But in a 16 bit file=
 the range of values is so much bigger (0-65535) that the probability of ha=
ving specific sets of numbers that repeat falls dramatically, and the table=
 becomes an overhead.<br>


<br>
I imagine that for simple images, such as mattes, then LZW would still offe=
r impressive file size advantages in 16 bit mode. =A0But for natural images=
 such as photographs then it just doesn&#39;t work very well, and it&#39;s =
due to the 8 bit nature of the algorithm&#39;s origins.<br>


<br>
I suppose it&#39;s a case of YMMV, but in general LZW isn&#39;t recommended=
 for 16 bit tiffs.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
-Chris<br>
+---End of message---+<br>
To unsubscribe send any message to &lt;<a href=3D"mailto:ae-list-off@media-=
motion.tv">ae-list-off@media-motion.tv</a>&gt;<br>
</div></div></blockquote></div><br></div></div>

--001a11c2c54a0808bf04e9d3b44d--