This is a discussion on Re: need this in KDE mime magic file - KDE ; 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, ...
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?
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
# CR2 (Canon RAW, a modification of TIFF)
0 string II\x2a\x00\x16\x00\x00\x00CR\x02\x00
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
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:
If a RAW format _is_ really a tiff file (like Adobes DNG format) then of
course tiff parsing needs a enhanced tiff format handling.
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<