<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Hi Andrew,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">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.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">I tried this:</div>
<div class="moz-cite-prefix">a) copy an existing *.jpg to *.RW2,
*.dng, *.DNG - KPA imported all 4 and shows them side by side</div>
<div class="moz-cite-prefix">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)</div>
<div class="moz-cite-prefix">c) copy a *.jpg and the corresponding
*.RW2 into the same folder (new name) - KPA imports both</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">My conclusion:</div>
<div class="moz-cite-prefix">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.<br>
</div>
<div class="moz-cite-prefix">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.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">I suggest, you file a bug report. The
KPA maintainers are really good at fixing things. </div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">But you might then need to compile the
program from the latest git sources to get a fix (or wait for the
<br>
</div>
<div class="moz-cite-prefix">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.</div>
<div class="moz-cite-prefix">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).</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Cheers, Andreas<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Am 10.01.25 um 12:03 schrieb Andrew
Kovacs via KPhotoAlbum:<br>
</div>
<blockquote type="cite" cite="mid:2685287.k3LOHGUjKi@avocado">
<pre wrap="" class="moz-quote-pre">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
</pre>
</blockquote>
<p><br>
</p>
</body>
</html>