--===============0965785492==
Content-Type: multipart/signed;
boundary="nextPart2994753.C7oOaRY3mz";
protocol="application/pgp-signature";
micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart2994753.C7oOaRY3mz
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Saturday 12 November 2005 00:30, Dirk Mueller wrote:
> On Saturday 29 October 2005 17:32, Thorsten Schnebeck wrote:
> > > ... if I come to the same conclusion?
> >
> > Same conclusion? :-)
>
> Hmm, I'm not convinced. Those *are* tiff files after all, no?

No, not in the sense that any ordinary tiff reader could read them. They ju=
st=20
share some characteristics, but to make images out of .raw files, you need =
to=20
do some complicated stuff. No tiff reader, no client of the common tiff=20
library will be able to do that. These images need to be handled with dcraw=
=20
or a derivatice of dcraw.

Currently, I have to special-case my tiff filter for files with extensions=
=20
like .cr2 or .dng and then call my raw filter from my tiff filter.

=46or all practical purposes (i.e., writing code that doesn't surprise user=
s),=20
it's necessary to make a distinction between an ordinary tiff file and a ra=
w=20
file. All raw files, whether tiff-like or not need to be handled the same=20
way, and that way is different from the way one would handle tiff files.

=2D-=20
Boudewijn Rempt=20
http://www.valdyas.org/fading/index.cgi

--nextPart2994753.C7oOaRY3mz
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQBDdd5TdaCcgCmN5d8RAqvlAJ9usZSSyXe0mvz5hHfYce JxvqXNtACg0R5k
e4TQ19cR23q186/a80prfGM=
=12SD
-----END PGP SIGNATURE-----

--nextPart2994753.C7oOaRY3mz--

--===============0965785492==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

--===============0965785492==--