[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: need this in KDE mime magic file
From:       Thorsten Schnebeck <thorsten.schnebeck () gmx ! net>
Date:       2005-11-12 13:50:57
Message-ID: 200511121450.57393.thorsten.schnebeck () gmx ! net
[Download RAW message or body]

Am Samstag 12 November 2005 00:30 schrieb Dirk Mueller:
> 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?

Hmmm,
The offset to the first IFD isn't part of the TIFF specification, and can be 
set to anything you want.  Most TIFF's use an offset of 8, but CR2
puts an (unreferenced) identifier in front of the first IFD and uses an offset
of 16. The other difference is that IFD3 holds the raw data and CR2 uses its 
own (secret) makernotes

I really think the aim of this unreferenced identrifier is to make it simple 
to differ CR2 from TIFF by MIME type magic :-) Otherwise you can only differ 
CR2 and Tiff by following and interpreting the IFD logic.

So, yes it is possible to create a file that looks like CR2 but does containt 
a valid tiff image. But no, it is not possible to create such a file by error 
or by accident. Maybe a saver magic approach is to take the first IFD offset 
into account:

 # CR2 (Canon RAW, a modification of TIFF)
0       string          II\x2a\x00\x16\x00\x00\x00CR\x02\x00          
image/x-raw

What about to look at the problem vice versa: If KDE say CR2 == TIFF it shows 
wrong (== no) image and metadata and programs fail cause internal image 
structure is interpreted wrong:

kuickshow: Trying to load /home/schnebeck/EOS/20D-Test/IMG_7301.CR2 with 
KImageIO...
kuickshow: KImageIO: readImage() format = TIFF
/home/schnebeck/EOS/20D-Test/IMG_7301.CR2: Warning, incorrect count for field 
"BitsPerSample" (3, expecting 1); tag trimmed.
/home/schnebeck/EOS/20D-Test/IMG_7301.CR2: Sorry, requested compression method 
is not configured.
(kolourpaint, gwenview, kview, showimg, showfoto : dito)

So, result of this test:

no KDE program shows the picture
every program seems to use the same tiff file detector
file detector is _right_ -> CR2 != tiff (!)

This togethers means: KDE is not able to handle a common RAW file type. When 
KDE will in future handle RAW == tiff  we have to drop KDE standard file 
detection logik and use a new one with a more sofisticated type checker and 
image detection based on file extention.

Maybe it is easier when you discribe your concerns? When you think CR2 == tiff 
do you mean the KImageIO have to be extend to handle raw files like in:
http://bugs.kde.org/show_bug.cgi?id=107805 ?

If a RAW format _is_ really a tiff file (like Adobes DNG format) then of 
course tiff parsing needs a enhanced tiff format handling.  

Bye

  Thorsten




 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]