Kphotoalbum ignores the 'Do not read RAW files if a matching JPEG/TIFF file exists' setting

[Andreas Schleth]

Hi Andrew,

I can confirm this behaviour on openSuse Leap 15.6 (KPA 5.13.0). Most
probably it is not an OS problem but one of KPA itself.

I tried this:
a) copy an existing *.jpg to *.RW2, *.dng, *.DNG - KPA imported all 4
and shows them side by side
b) copy a RW2 file into the same folder as the corresponding *.jpg - KPA
does not import or show the RW2 (Note: the jpg was imported earlier)
c) copy a *.jpg and the corresponding *.RW2 into the same folder (new
name) - KPA imports both

My conclusion:
a) It seems, that KPA does not look into the files to determine the MIME
type before import but seems to go by file extension.
b) I suspect that the "do not import"-rule only applies to images
already in the database. When importing a new set of images, there is
probably no surefire way to insure that KPA finds the *.jpgs first, so
that it can decide to skip the corresponding raw file. ... Yes: I
deleted one of the RW2 files, saved the database and copied it back to
its location: then it will not be imported.

I suggest, you file a bug report. The KPA maintainers are really good at
fixing things.

But you might then need to compile the program from the latest git
sources to get a fix (or wait for the
This is not so simple anymore, as KPA has moved to QT6 and not all
distros have all the bits and pieces in place to work with the newest
sources.
The flatpak version (org.kde.kphotoalbum) is on the most recent release
(6.0.1) but unfortunately it does not work for me (this is a differnet
topic).

Cheers, Andreas


Am 10.01.25 um 12:03 schrieb Andrew Kovacs via KPhotoAlbum:
> Hello, and happy new year!,
>
> Firstly, a heartfelt thank you to all the developers and contributors of this
> wonderful application.
> I'd be lost without it.
>
> A bit of an intro...
> I have been using linux since 2002.  I'd been driven mad by Windows (95, 98,
> 2000, etc...) then OS/2 (had potential, but went nowhere), when a friend
> loaned me a set of Red Hat 7.3 CDs.  I struggled, and learned the 'NIX way,
> with that and a bit of help, before distro-hopping through some RPM-based
> systems for a few years until I knew I needed stability, and more importantly,
> a sane package management system.
> Debian released Sarge, and with my meagre skills, I could install and use it.
> More importantly, I could maintain it!  :-)
>
> My digital photo organising journey was similar.  I started in 2004 with some
> cheap, nameless digital camera (1.3MPx), storing my photos in directories,
> beginning with the ISO date, then some meaningful description.  Backups were
> burnt to DVD.
> It worked for a while, but I moved to better cameras with bigger cards, took
> more photos, and by mid 2006, returning from a holiday with thousands of
> photos, and I was struggling to keep track of them.  Especially finding photos,
> and how to add places, names, etc... to them.  I knew about exif, but had no
> clue of what software to use, nor how to work out a tagging scheme that would
> properly store the tags.
> In my search for these, I stumbled across Kphotoalbum.  I tried it a few
> times, occasionally making a mess, then reinstalling, until I worked out which
> files to backup elsewhere, or to go back to an earlier index.xml backup.
>
> I moved to newer versions as I progressed to the newer Debian stable releases,
> and photo management was a breeze.  I stuck with Debian Jessie until mid 2022,
> when I attempted to move to Bullseye, .  This proved unsuccessful, mostly due
> to kmail generating thousands of copies of existing emails no matter what I
> did, so I elected to stick with Jessie, until Bookworm was released.
>
> This seems to be working well, (kmail too) but Bullseye had introduced a minor
> problem with Kphotoalbum, and it still exists in Bookworm (Kphotoalbum 5.9.1).
>
> This is summed up in the subject: Kphotoalbum ignores the 'Do not read RAW
> files if a matching JPEG/TIFF file exists' setting.
>
> New image files are copied from the camera SD cards to my NAS (huge plug for
> OpenMediaVault) into a directory structure thus: Digital_camera/<cameramake-
> model>/YYYY-MM-DD/files.
> The files keep their sequential naming and extension as created in the camera.
>
> I mostly use Pentax cameras, set to simultaneously save .JPEG and .DNG for
> each image.
>
> When I start Kphotoalbum, it's set to search for new files, and this is where
> the problem occurs.  Same when searching for new files from within Kphotoalbum.
> No matter what setting changes I make, Kphotoalbum insists on loading in the
> raw image files, and creating what are effectively 'duplicate' images in the
> thumbnail view.  I've been getting around this issue, by doing a blank search,
> ticking the raw file checkbox, then manually deleting the duplicate (raw)
> images from the database, leaving the raw files intact on the NAS.  While this
> works, kind of, if Kphotoalbum hasn't been started for a while, then loading
> (and creating the duplicate thumbnails for the raw files) can take a very long
> time.
>
> To test if a fresh install of Bookworm behaves differently, I copied a current
> Live Bookworm KDE to a USB stick, booted off that, updated everything,
> installed the current stable Kphotoalbum package, copied my all my files,
> symlinks, etc... to the same 'Images' folder in the live system home
> directory, mounted the NAS to the same mountpoint, and... no change.
> Kphotoalbum still loads in the raw files.
> I created a new 'Image-test' directory, copied a couple of small image
> directories there, started Kphotoalbum with -c and created a new index.xml
> (thinking my main database might be corrupt), and still the same problem.
>
> I then went through the same process with Debian Trixie, the current testing
> release, this time with Kphotoalbum 5.13.0.  The problem was gone!  So now,
> how to get 5.13.0 into Bookworm?
>
> I looked for a new version of Kphotoalbum in Debian-backports, but no luck.
> I set up my Bookworm install with the appropriate pinning, all set to install
> 5.13.0 from Trixie, but the number of packages that would have been removed,
> as well as installed, stopped me from pursuing that path.
>
> I then thought to create my own local backport.  The Debian instructions
> seemed simple enough to create a local, non-uploadbable, non-signed backport.
>
> For extra safety, I booted into the live Bookworm with the USB key, then
> successfully completed all the steps and created and installed a local
> backport of Kphotoalbum 5.13.0, built using Debian testing sources, as
> recommended in the Debian instructions.  I then set everything else up as
> before, crossed my fingers and started my shiny new Kphotoalbum.
> Sigh...., the problem still exists.  :-(
>
> I don't wish to migrate to Debian Testing, as I've tried that before and
> constant stream of package updates, plus the occasional breakage that can
> take considerable time to fix, isn't my idea of a stable production desktop.
>
> I tried using search, in the Debian-Users mailing list, but although there
> were a few posts about Kphotoalbum, nothing like I'm experiencing.  Also,
> there's no bug report about this in any version of Kphotoalbum in the Debian
> releases.
>
> I haven't filed a bug report with Debian or KDE, as this may well be caused by
> some other package/library/setting outside of Kphotoalbum.  If anyone else has
> encountered this, and knows how to fix it with some Debian or Kphotoalbum
> settings, I'd be grateful.
>
> Failing any solution, I'm prepared to continue with my workaround and wait for
> the release of Debian Trixie as stable, with what ever version of Kphotoalbum
> that finally 'ships' with.
>
> Thanks to anyone for any help or suggestions and I'll try to answer questions
> that might help.
>
> Kind regards,
> Andrew
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kphotoalbum/attachments/20250110/baf4ed7c/attachment.htm>