[KPhotoAlbum] KPA 5.1/GIT problems

[Martin Jost]

Hello,

I tried to update to KPA 5.1.

But unfortunately, this crashes on start.
I get the following sequence on start:
- "the usual" messages about a not configured tag for untagged images
- A complain about a found mplayer, but missing mplayer2
(BTW: Is this still reasonable, given the fact that IIRC mplayer2 is
no longer developed ?)
- KPA starts to read in new photos (progress bar)
- Then it crashes with a segmentation violation and a core dump.
Unfortunately, I can't find a core file, despite
gollum:> ulimit -a
-c: core file size (blocks) unlimited
Any hints, why I miss it ?
- On the command line I get
gollum:> /usr/local/bin/kphotoalbum
KXMLGUI file found at deprecated location
("/usr/local/share/kphotoalbum/kphotoalbumui.rc") -- please use
${KXMLGUI_INSTALL_DIR} to install this file instead.
[1] 6040 segmentation fault (core dumped) /usr/local/bin/kphotoalbum
- I had to fix the permissions for /usr/local/etc/xdg/kphotoalbumrc and
also of /usr/local/etc/xdg
(But that didn't solve the problem)
- I don't find any file 'kphot*' below ~/.kde4
- I found ~/.config/kphotoalbumrc and moved it away.
After that I can start and load the demo DB - but trying to load my
own still crashes.

I had a quite recent copy from GIT running. But I missed to compile and
install this again for cross-check. Instead I did a 'git pull' but the
result of this behaves in the same way.

Any ideas for me ?

Regards

Martin

[Andreas Schleth]

Hi everybody,

I just added the openSUSE setup to the build instructions to
https://userbase.kde.org/Building_KPhotoAlbum.

However, I am not sure, in which way ffmpeg is necessary for building.
Is this the successor of mplayer(2)? I have it on my system anyway -
with a host of codec-libs. Which of these are needed at which state?

Andreas

[Andreas Schleth]

Hi Andreas,
thanks for pushing me in the right direction.
I got my crashing KPA fixed !
The trick is to install "ffmpeg" !

...

Regards - and a happy new year !
Martin

Hi everybody,

this is interesting: I just checked my model installation with a few
variations:

a) find some version of mplayer and install: this gives incomplete video
thumbnail support, as only mplayer (1) is provided.
b) deinstall mplayer and ffmpeg, but leave the code libs there: no video
thumbnail support
c) install ffmpeg instead of mplayer: this gives complete support for
video thumbnails (at least, "check feature set" says so).

In my first install, I just had a lot of ffmpeg codec libs already on
the system as they come with packages as vlc and audacious. I think, a
parallel install of the packman-version of vlc should be beneficial as
it pulls in a lot of codec libs.

How is the status internally: is Mplayer2 really needed anymore?
Ffmpeg seems to the better option as it is under active development and
seems to do just about everything except brewing coffee.

Andreas

[Andreas Schleth]

Hi everybody,

for me, the current version of KPA works fine. But I always have some
explaining and some works "in the basement" to do if my wife or others
use KPA. Therefore, I think some ironing out rough edges would be
beneficial for all of us:

a) Annotation dialog:
This is one of the best and central features of KPA. I tried a quite
few other photo tagging tools and always came back to KPA. Therefore I
think, this central feature should be as polished as it can get:
- It should always start up either in full screen or at most in screen
size. Right now it always starts up in a size larger than my screen.
- Saving a layout should also save the (relative) sizes of all widgets
including the preview image
- window layout should get a dedicated button at the lower left edge
to ease accessibility
- In the latest version, sorting the tags by time seems to be a bit
off - could this have a connection with saving the index file in a
different way now?
- @Martin Füssel: as you are looking at the map interface: how about
some method of mapping the places tag to a map feature? Or a point and
click map interface to create a new geo location? I have a lot of old
scans from slides ...

b) Selecting images by date/time/search:
Being able to drill down to a few images among a large set of some 10000
with a few clicks is impressive and the second power feature of KPA.
This also could use a few optimizations:
- the lens on the date bar (the_lens.jpg):
On startup it always resides on the oldest image. Or if a range is
selected and then expanded (switch resolution from years to months), it
always sits on the left end of the range. Now imagine the case, you
have very old pictures (in my case, starting from 1926): then one has to
shift some 90 years to the right before one can start drilling down.

c) Using a database with several users:
We have a family album which is accessed by various members of the
family (all different users, same group). This only works on the
condition that I periodically change the permissions of .thumbnails to
rw-rw-r-- manually. All files of KPA should inherit the permissions of
index.xml to make these low level repairs unnecessary.

All these things are no great new features, but would really make KPA
more accessible to less technically oriented users. I would love to see
KPA enter the circle of programs installed per default in the large
distributions some time.

Andreas

[Robert Krawitz]

- It should always start up either in full screen or at most in screen size. Right now it always starts up in a size larger than my screen.
- Saving a layout should also save the (relative) sizes of all widgets including the preview image
- window layout should get a dedicated button at the lower left edge to ease accessibility
- In the latest version, sorting the tags by time seems to be a bit off - could this have a connection with saving the index file in a different way now?

This reminds me of another annoyance with the annotation dialog. The
three widgets at the top left are the three that are least useful (and
possibly most dangerous): label, date, and Use Fuzzy Date.

I have a few times inadvertently changed the name of many files
because I accidentally started typing something I intended as a
keyword into the label box. I don't even want to think about what
setting the date implies. And I don't know what Use Fuzzy Date even
means in this context.

These look like artifacts of the very similar search dialog, but
search and annotate are not the same thing.

[Andreas Schleth]

Post by Robert Krawitz

- It should always start up either in full screen or at most in screen size. Right now it always starts up in a size larger than my screen.
- Saving a layout should also save the (relative) sizes of all widgets including the preview image
- window layout should get a dedicated button at the lower left edge to ease accessibility
- In the latest version, sorting the tags by time seems to be a bit off - could this have a connection with saving the index file in a different way now?

This reminds me of another annoyance with the annotation dialog. The
three widgets at the top left are the three that are least useful (and
possibly most dangerous): label, date, and Use Fuzzy Date.
I have a few times inadvertently changed the name of many files
because I accidentally started typing something I intended as a
keyword into the label box. I don't even want to think about what
setting the date implies. And I don't know what Use Fuzzy Date even
means in this context.
These look like artifacts of the very similar search dialog, but
search and annotate are not the same thing.

Hi Robert,

you might just redesign your window layout and simply put away this
offending window either totally (hit the x) or to an less dangerous
position (grab the local title bar and move the widget around - it will
become either a floating window or dock somewhere). Options ->
configure ... -> save current layout saves this for future tagging sessions.

Setting the date is just another label in the database. Remember, KPA
does not touch your images. Except if you order it to do so via one of
the KIPI plugins. KPA fills the date from exif data on loading new
images. If the image does not contain any exif-info, the file date is
used. This might not be appropriate, so you may set it to another date.

There is was?!? a KIPI plugin that allows you to transfer the KPA-date
to the image (exif) and vice versa.

Andreas

[Robert Krawitz]

This is a multi-part message in MIME format.
--===============5927052655967316771==
Content-Type: multipart/alternative;
boundary="------------8A283F2038126D804A744B2F"
This is a multi-part message in MIME format.
--------------8A283F2038126D804A744B2F
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Post by Robert Krawitz

- It should always start up either in full screen or at most in screen size. Right now it always starts up in a size larger than my screen.
- Saving a layout should also save the (relative) sizes of all widgets including the preview image
- window layout should get a dedicated button at the lower left edge to ease accessibility
- In the latest version, sorting the tags by time seems to be a bit off - could this have a connection with saving the index file in a different way now?

This reminds me of another annoyance with the annotation dialog. The
three widgets at the top left are the three that are least useful (and
possibly most dangerous): label, date, and Use Fuzzy Date.
I have a few times inadvertently changed the name of many files
because I accidentally started typing something I intended as a
keyword into the label box. I don't even want to think about what
setting the date implies. And I don't know what Use Fuzzy Date even
means in this context.
These look like artifacts of the very similar search dialog, but
search and annotate are not the same thing.

Hi Robert,
you might just redesign your window layout and simply put away this offending window either totally (hit the x) or to an less dangerous position (grab the local title bar and move the widget around - it will become either a floating window or dock somewhere). Options -> configure ... -> save current layout saves this for future tagging sessions.

Well, the rating (stars) widget is in the same pane as the label and
date widgets. And that one is certainly valuable (albeit I'd think
you'd more likely use it with annotating single images).

I understand that there are good reasons in some cases to set the
dates, although probably fewer than 10-15 years ago now that most
people are taking photos with a device that embeds the date in the
EXIF data and most image editing apps propagate the EXIF data. 15
years ago, this wasn't necessarily the case; a lot of people were
using scanners that even if they embedded EXIF data were embedding the
date that the image was scanned, not originally created.

But setting the label is another matter. That should be a unique or
close to unique (img_xxxx.jpg -- you're not going to have too many of
them). I'm very hard pressed to see _any_ use case for that, at least
for multiple annotation. If you want to do that, I'd think you almost
certainly want to set a keyword.

*Maybe* you would want to do that when annotating a single image. But
kpa already knows that it's a different situation; there's only one
image being annotated, so it has a single label.

Setting the date is just another label in the database. Remember, KPA does not touch your images. Except if you order it to do so via one of the KIPI plugins. KPA fills the date from exif data on loading new images. If the image does not contain any exif-info, the file date is used. This might not be appropriate, so you may set it to another date.
There is was?!? a KIPI plugin that allows you to transfer the KPA-date to the image (exif) and vice versa.

[Andreas Schleth]

Post by Robert Krawitz

This is a multi-part message in MIME format.
--===============5927052655967316771==
Content-Type: multipart/alternative;
boundary="------------8A283F2038126D804A744B2F"
This is a multi-part message in MIME format.
--------------8A283F2038126D804A744B2F
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Post by Robert Krawitz

- It should always start up either in full screen or at most in screen size. Right now it always starts up in a size larger than my screen.
- Saving a layout should also save the (relative) sizes of all widgets including the preview image
- window layout should get a dedicated button at the lower left edge to ease accessibility
- In the latest version, sorting the tags by time seems to be a bit off - could this have a connection with saving the index file in a different way now?

This reminds me of another annoyance with the annotation dialog. The
three widgets at the top left are the three that are least useful (and
possibly most dangerous): label, date, and Use Fuzzy Date.
I have a few times inadvertently changed the name of many files
because I accidentally started typing something I intended as a
keyword into the label box. I don't even want to think about what
setting the date implies. And I don't know what Use Fuzzy Date even
means in this context.
These look like artifacts of the very similar search dialog, but
search and annotate are not the same thing.

Hi Robert,
you might just redesign your window layout and simply put away this offending window either totally (hit the x) or to an less dangerous position (grab the local title bar and move the widget around - it will become either a floating window or dock somewhere). Options -> configure ... -> save current layout saves this for future tagging sessions.

Well, the rating (stars) widget is in the same pane as the label and
date widgets. And that one is certainly valuable (albeit I'd think
you'd more likely use it with annotating single images).
I understand that there are good reasons in some cases to set the
dates, although probably fewer than 10-15 years ago now that most
people are taking photos with a device that embeds the date in the
EXIF data and most image editing apps propagate the EXIF data. 15
years ago, this wasn't necessarily the case; a lot of people were
using scanners that even if they embedded EXIF data were embedding the
date that the image was scanned, not originally created.
But setting the label is another matter. That should be a unique or
close to unique (img_xxxx.jpg -- you're not going to have too many of
them). I'm very hard pressed to see _any_ use case for that, at least
for multiple annotation. If you want to do that, I'd think you almost
certainly want to set a keyword.
*Maybe* you would want to do that when annotating a single image. But
kpa already knows that it's a different situation; there's only one
image being annotated, so it has a single label.

Setting the date is just another label in the database. Remember, KPA does not touch your images. Except if you order it to do so via one of the KIPI plugins. KPA fills the date from exif data on loading new images. If the image does not contain any exif-info, the file date is used. This might not be appropriate, so you may set it to another date.
There is was?!? a KIPI plugin that allows you to transfer the KPA-date to the image (exif) and vice versa.

Hi Robert,

I see - setting the date on *multiple* images seems to be a strange
action and even for single images that is not often necessary - as you
say: this is in the exif data (if they are correct). However, after
scanning a set of really old pictures, I used this feature to set an
approximate date for the whole set (like 1.1.1928 - 31.12.1928), to bin
these images into the right year at least.

I regularly set a common label for a group of images - typically the
"event" name. This obscures the file name to some extent, but I rarely
need that directly. So, for me there is quite a bit of usefulness in
this feature.

I do not use the stars. When I started with KPA there were no stars, so
I set up my own category for quality and use that instead.

Andreas

[Johannes Zarl-Zierl]

[Sorry for the late reply - I'm still working through my email backlog]

Post by Andreas Schleth
How is the status internally: is Mplayer2 really needed anymore?
Ffmpeg seems to the better option as it is under active development and
seems to do just about everything except brewing coffee.

MPlayer/MPlayer2 is not needed anymore. MPlayer2 seems to be dead. We still
support both for now. This may change at some point in the future.

Ffmpeg is the best choice as far as I can currently see. We will support this
for the foreseeable future.

Cheers,
Johannes

[Andreas Schleth]

Hi,

this might be an issue with openSUSE, KPA or KIPI:

In my current install (KPA 5.1..., openSUSE Leap 42.2) the "batch
processing" plugins are not available. "Batch Plugins" is greyed out.
Several other plugins are available.
As far as I found out, these batch plugins are not part of the KF5 kipi
set anymore. I may be wrong.

Am I missing some config step?
Have these plugins gone awol? (I do not find any suitable packages.)
How is the situation with Ubuntu?

The batch plugins were the most useful (for me at least).

Andreas

[Reimar Imhof]

Post by Andreas Schleth
Hi,
In my current install (KPA 5.1..., openSUSE Leap 42.2) the "batch
processing" plugins are not available. "Batch Plugins" is greyed out.
Several other plugins are available.
As far as I found out, these batch plugins are not part of the KF5 kipi
set anymore. I may be wrong.
Am I missing some config step?
Have these plugins gone awol? (I do not find any suitable packages.)
How is the situation with Ubuntu?
The batch plugins were the most useful (for me at least).
Andreas

Hi Andreas,

to me it seems if these pugins where integrated into digikam.

Cheers,
Reimar

[Reimar Imhof]

Post by Andreas Schleth
Hi,
In my current install (KPA 5.1..., openSUSE Leap 42.2) the "batch
processing" plugins are not available. "Batch Plugins" is greyed out.
Several other plugins are available.
As far as I found out, these batch plugins are not part of the KF5 kipi
set anymore. I may be wrong.
Am I missing some config step?
Have these plugins gone awol? (I do not find any suitable packages.)
How is the situation with Ubuntu?
The batch plugins were the most useful (for me at least).
Andreas

Hi Andreas,
to me it seems if these pugins where integrated into digikam.
Cheers,
Reimar
_______________________________________________
KPhotoAlbum mailing list
https://mail.kdab.com/mailman/listinfo/kphotoalbum

Hi Reimar,
... meaning "desintegrated" from KPA? That would be a pity indeed!
Might there be a way to extract these plugins somehow?
Andreas

Hi Andreas,

I just searched a little and found an kipi plugins bugs overview at
https://bugs.kde.org/component-report.cgi?product=kipiplugins

To me this seems all interesting plugins are gone - for example I was using
the geo tagging plugin or the auto rotate thing. All gone :-(
I've got no idea if it's possible to include this things that moved to digikam
into kphotoalbum.
I don't know if there is anyone around who could discuss this with the digikam
people.

Cheers,
Reimar

[Johannes Zarl-Zierl]

Post by Reimar Imhof
I just searched a little and found an kipi plugins bugs overview at
https://bugs.kde.org/component-report.cgi?product=kipiplugins
To me this seems all interesting plugins are gone - for example I was using
the geo tagging plugin or the auto rotate thing. All gone :-(
I've got no idea if it's possible to include this things that moved to
digikam into kphotoalbum.

The easiest solution would be to port the missing plugins to KF/Qt5.

Post by Reimar Imhof
I don't know if there is anyone around who could discuss this with the
digikam people.

Speaking for the kphotoalbum developers, we can talk to the digikam people in
very much the same way as you can as a user. In a sense, I think it would
probably be better if "regular" users bring this up with the digikam people.

Talking worst case scenarios:
If nobody of the original plugin authors is willing to port the necessary
plugins to Qt5, we can probably get it done. Maintainership is an entirely
different problem, though (in case nobody noticed, we don't have that many
developers lying around here...)

Cheers,
Johannes

[Johannes Zarl-Zierl]

Hi,

Post by Andreas Schleth
However, I am not sure, in which way ffmpeg is necessary for building.
Is this the successor of mplayer(2)? I have it on my system anyway -
with a host of codec-libs. Which of these are needed at which state?

Neither ffmpeg nor mplayer is needed for building kphotoalbum.

However, you'll need either ffmpeg or mplayer when running kphotoalbum if you
want proper video support. mplayer(2) can be considered a fallback if ffmpeg
is not installed.

To be precise:
For optimum support, you need the binaries "ffprobe" and "ffmpeg".
If you can't have those, install mplayer2 (which is deprecated).
If you can't have mplayer2, install mplayer (which works almost as good as
mplayer2, but has had problems in the past with some shorter videos).

Installing several/all options mentioned above at the same time is not a
problem.

HTH,
Johannes