[Digikam-users] after using gimp dk can´t open image.

[Jean-François Rabasse]

On Sun, 30 Oct 2011, sleepless wrote:

> Date: Sun, 30 Oct 2011 12:31:55 +0100
> From: sleepless <sleeplessregulus at hetnet.nl>
> Subject: [Digikam-users] after using gimp dk can´t open image.
> 
> After I used gimp dk will not open my image, gwenview can.
> Is this a known problem?

At least, it's a problem I know and had many times in the past.
Seems to be related to images files metadata and the way applications
use that data, and "what idea" they have of what could be valid or not.
Clearly, Gimp and Digikam haven't the same "idea" of validity.

I discovered the problem, not with digital photographs, but with JPEG
images coming from digitized artwork.

(Briefly, I'm amateur photographer and also amateur drawer / painter,
and I use DK to manage my genuine photos from digital cameras and also
scanned versions of my drawings.)

When I scan drawings, I always use Gimp to process the scanner output.
(Mostly because the Gimp/Xsane interface is great, and also because
I only own a small A4 flatbed scanner and drawing paper formats are
larger than A4, so I need to scan in multiple parts then reassemble.)

The final JPEG file I get, after processing, have a simple Exif section
made by Gimp which contains only the image preview (i.e. a dummy Exif IFD0,
an Exif IFD1 with preview size and offset, nothing else).
Obviously, no digital camera Exif info (focal length, aperture et al.),
and no other metadata informations, XMP or IPTC records.
(Gimp also adds a JFIF head section in the final file.)

And what I've observed is that all this seems to mystify Digikam.
Don't know why but...
As for Gwenview, same results as you get, Gwenview opens the image file.
But Gwenview doesn't care of metadata records so, as long as the "pure"
image sections of the JPEG file (DQT, DHT, SOF, SOS...) are valid, the
image is displayed.

Probably, your problem isn't related to digitized drawings or sketchs,
but digital photos ?
But it could be a similar problem of metadata organisation and content.
Maybe if DK finds a Exif header, but lacking some fundamental
(or supposed to be) information, it stucks or considers as a corrupted
header or file ? DK developpers involved in the metadata processing
could probably answer ?

I don't know a general solution, working with all applications.

As for me, as I really needed a working solution for scanned material,
I solved my above problem the following way :
- remove from my JPEG files of scanned material the Exif section.
   (I really don't care about an embedded image preview)
- tag my file by writing metadata in the XMP Dublin Core fields,
   xmp.dc.title, xmp.dc.description and xmp.dc.date
   (The date is important for scanned artwork, it's not like a photo.
   One should set the realisation date, not the scan job date.)

With that, DK opens the JPEG image and seems to be happy. And gets the
xmp.dc info so that I have a correct Caption, from xmp.dc.description,
and a correct date.

I'm not sure my problem and above solution can help you, but maybe you
should try to remove all metadata from the images DK refuses to open
(use any exiftool, exiv2, or even "convert -strip ..."), and rescan
your images directory with DK, as if it were fresh new JPEG without any 
metadata.

I happened to do that once, with a genuine digital photo but with a 
corrupted Exif header (or, most probably, not fully standard compliant
Exif header; it came from a Sony camera).
Juste removing Exif header made DK open the photo without problems,
of course, without focal length, aperture, shutter speed info...


Jean-François