Image descriptions (alt text) in Gwenview

Applications
, , ,
21

I am on top of it and will address and discuss the different approaches in my manual.

3 Likes
22

Hi again, :wave:

@nevj :

Yes, I see.

Perhaps I primitively deduced I could add some tag with setfattr and it would be available in any image viewer accordingly, which doesn´t seem to be the case at least with shotwell.

Right.

@Mina: :wave:

Thanks for your patience. :heart:

Many greetings to all from Rosika :slightly_smiling_face:

1 Like
23

Yes I thought that with gthumb too., but no it does not work.
It might work with gwenview, because gwenview keeps its tags in extended attributes.

2 Likes
24

Meanwhile, I found out that Shotwell uses an entirely different approach:

As I suspected, the program stores tags and descriptions in a database file:

$HOME/.local/share/shotwell/data/photo.db

So far, we have three different methods of storing image tags and descriptions:

  1. Shotwell: Database

:heavy_plus_sign: Extremely fast and efficient

:heavy_minus_sign: If files are moved around outside the program, the information is lost.

  1. GwenView: Extended File attributes

:heavy_plus_sign: Works for all kinds of files.

:heavy_minus_sign: Despite being supported by most modern file system types (e.g. ext4 and NTFS), this might not work on older file systems (e.g. FAT16) and, despite being around for a good while, they are hardly known and not copied by default by the cp command.

  1. gThumb: EXIF information

:heavy_plus_sign: The information sticks to the image, no matter, how it is moved around.

:heavy_minus_sign: Not all image and video formats contain EXIF information.

Besides that: The gThumb developers made the asshole move that, if you add a tag or a description in their program, all extended file attributes are deleted.

People might use different programs to view and organise their images, or they might change their preferences. Therefore, I decided to write a program that will keep at least these three methods of storing image information in sync for a given directory and its subdirectories.

So, if you add a tag or a description to an image in one program, it will be available in the other ones. I reckon, this might be rather useful. When I am ready, I will post a link.

1 Like
25

Hi Mina, :wave:

thanks so much for the work you´ve done so far. :heart:

It´s really great you found that out.

I immediately took a look at it:

  • opened the file $HOME/.local/share/shotwell/data/photo.db with sqlitebrowser and found all entries, but not the “Heideschnucken” tag I had created with setfattr. That was to be expected as per your findings.

  • created the tag “Heideschnucken” from within shotwell and sqlitebrowser indeed showed it :+1:

  • copied the relevant jpeg file to a test folder and opened it it from there:
    the “Heideschnucken” tag was lost, like you predicted.

So I may confirm everything you found out about shotwell. Thanks a lot, Mina. :heart:

It´s great you found out about those 3 different methods for storing tags in different applications.

Wow, that would be super-convenient for other folks to use. I´m amazed at what you can achieve, Mina. :+1:

Thanks for all your work.

Many greetings from Rosika :slightly_smiling_face:

2 Likes
26

That is great Mina.
I wonder what Gimp does? Hopefully not a fourth way.
The script idea is clever. I assume you run it as a daemon, or perhaps only as required.

3 Likes
27

I will not look at Gimp, as it is a picture editor, not a viewer or organiser.

I think, it depends on the use case: If you work a lot with images and different programs, you might want to run it as a daemon.
If you are a person, who just wants to organise their photos and only occasionally adds new ones, you will only run it, after you’ve done some tagging.

I can imagine, using Shotwell for tagging, for which it is great, but one of the others for viewing.

3 Likes
28

Doing my research for the program, I stumbled upon the fantastic organiser Digikam:

It uses the approach of using a database (Sqlite for storing tags and descriptions/comments per default or in a professional database, in case you’ve got a lot of photos, say > 100K) with the option to also write them into the images’ metadata, obviously with some performance penalty.

2 Likes
29

I think the database approach would be great for organising lots of images in one computer. Across computers it is not going to be as easily portable as say Exif approach. Each to its own.
I think DigiKam is tied to Qt and KDE , at least in Linux. Correct me?

2 Likes
30

It is built with Qt, which makes it native to KDE and portable to MacOS and Windows, but as far as I know, Qt apps run on every Desktop environment, as well as Gnome apps can be used in KDE - they just don’t look as nice, or better: they just don’t fit as smoothly into the KDE world with all the typical tweaking options.

Yes: Databases (my main area of work expertise) are exceptionally well suited for big collections, but rather fragile when it comes to manual meddling with structures. So, I believe, the approach of organizing and structuring tags and comments with a database based app and “backing up” the data persistently within the objects’ metadata makes total sense.

Also: These organisers (e.g. Shotwell and Digikam) are not as swift for mere viewing as the programs specialized for that (e.g. GwenView and gThumb).

On Windows, when I still had it, I absolutely adored IrfanView. Unfortunately, it is Windows only.
I tried it with Wine, but it’s not the same as a native app.

3 Likes
31

Yes, I have used it in several DE’s. It just installs a lot of package material.
and
Lets not lose sight of setting up web images to to best help visually impaired users.

3 Likes
32

In times of sheer infinite disk space, this is hardly a problem, I guess.

What do you mean by “setting up web images”?

33

Hi @Mina and @nevj, :wave:

I just looked up the installation of digikam with

env LANG=en_US.UTF-8 apt-get -s install digikam

and it´s really a lot that would be installed by the default sudo apt install command.

However I found this comment here [in German though] , if anyone else is interested in installing it:

To install digikam with components but without the many KDE dependencies open a terminal and enter the following command:

sudo apt-get install --no-install-recommends digikam exiv2 kipi-plugins graphicsmagick-imagemagick-compat

This also prevents many other problems among other desktop environments.

Many greetings from Rosika :slightly_smiling_face:

2 Likes
34

Oh, just the Alt Text tags.
Is there any method other than your copy/paste?

35

FWIW, I just noted a bit of information about xattr’s that may explain some of the reason they are problematic…

I run Syncthing to keep my 3 GNU/Linux boxes synchronized with the same files on all of them, as I want to be able to swap easily between them. It isn’t perfect but works well…

By coincidence, there was a question asked on the Syncthing support forum involving xattr’s that I saw just after reading this thread. The answer referred to the xattr page in the docs - syncXattrs — Syncthing documentation They talk about some of the issues w/ xattr that seems to be a case of poorly implementing that turns a good idea into a serious mess - specifically

Blockquote Extended attributes are recorded and synced on a per-operating system basis. That is, if a file has an extended attribute on one operating system, it will not be synced to another operating system. For example, if a file has an extended attribute on Linux, it will not be synced to macOS. This is because the extended attribute names, values and interpretation is different on different operating systems.

Syncthing will attempt to preserve information about foreign extended attributes when a file is manipulated. That is, if a file is modified on Linux it’s expected that macOS extended attributes will be preserved in the metadata and hence applied again on macOS. This is not always possible - for example if a file is moved on Linux, the macOS extended attributes for that file will be lost.

(bold added) Seems like this is a good reason not to use them?

ex-Gooserider

1 Like
36

And a good reason for further work, and maybe some set of standards for extended file attributes.

1 Like
37

Yes, but setting standards is always a pain, and it is likely that we will end up w/ the usual result - “Standards are wonderful, which is why we have so many to choose from…” :confused:

Color me cynical… :grinning:

ex-Gooserider

2 Likes
38

Sometimes it happens naturally. Remember when PC’s first appeared… there was a bewildering variety of architectures.
Then IBM came on the scene and it all contracted to the 8086. chip, and its descendents.

1 Like
39

Not that I know of.

However: One way to make things a bit easier, would be to create a browser extension that would access the meta information of an uploaded file and copy it automatically into the clipboard.

40

This is indeed a good reason.

However: Extended attributes are a list of pairs of strings (name - value), which seems pretty forward to me, and not too hard to implement cross-platform interoperability for copy and move (provided the file system supports it). The question boils down to the semantics of the names and values, and my wild guess is: Every OS has its own philosophy.

1 Like