https://bugs.kde.org/show_bug.cgi?id=441698
--- Comment #55 from tagwer...@innerjoin.org ---
(In reply to tagwerk19 from comment #54)
> I *think* the patch takes the behaviour back to whatever internally coded;
> don't see mime types (as per freedesktop mime types) having an influence
I've dug into the format of the sample1.nef file. I'll give a warning that it's
not my day-job so it's fair to treat my observations with suspicion but maybe
it will help future travellers...
The mime database:
/usr/share/mime/packages/freedesktop.org.xml
has
<mime-type type="image/x-nikon-nef">
<comment>Nikon NEF raw image</comment>
... translations ...
<acronym>NEF</acronym>
<expanded-acronym>Nikon Electronic Format</expanded-acronym>
<sub-class-of type="image/x-dcraw"/>
<sub-class-of type="image/tiff"/>
<glob pattern="*.nef"/>
</mime-type>
<mime-type type="image/tiff">
<comment>TIFF image</comment>
... translations ...
<acronym>TIFF</acronym>
<expanded-acronym>Tagged Image File Format</expanded-acronym>
<magic priority="50">
<match type="string" value="MM\x00\x2a" offset="0"/>
<match type="string" value="II\x2a\x00" offset="0"/>
</magic>
<glob pattern="*.tif"/>
<glob pattern="*.tiff"/>
</mime-type>
So, it seems not to be able to distinguish (beyond looking at the file
extension) between an image/x-nikon-nef and an image/tiff file.
If I try imagemagick identify, it _can_ pull out correct details if I give an
extension:
$ identify -verbose sample1.nef
Image:
Filename: sample1.nef
Format: NEF (Nikon Digital SLR Camera Raw Image File)
Class: DirectClass
Geometry: 2844x4284+0+0
...
whereas renaming sample1.nef to sample1.tiff
$ identify -verbose sample1.tiff
Image:
Filename: sample1.tiff
Format: TIFF (Tagged Image File Format)
Mime type: image/tiff
Class: DirectClass
Geometry: 212x320+0+0
...
tiff:subfiletype: REDUCEDIMAGE
...
Gwenview is now following the same logic (after the rollback); give it an
extension and it will find that format image and display it: the sample1 file
is effectively a container and holds the image in three formats.
Before the rollback, Gwenview displayed the REDUCEDIMAGE.
Gut feeling is that the logic needed to "pick out" the primary image is too
complicated to implement in the mimetype database. You can see though that
there are 'ad hoc' patterns based on the Manufacturer tag set up for some other
"raw" types.
It might be worth working on some image/x-nikon-nef "magic" but it won't change
the Gwenview behaviour (something of a supposition...)
The behaviour, of Gwenview showing multiple copies of tags, seen in
https://bugsfiles.kde.org/attachment.cgi?id=141406
is better Moved To A New Bug
--
You are receiving this mail because:
You are watching all bug changes.
