[digikam] [Bug 394544] New: Export to inaturalist

[Marc]

https://bugs.kde.org/show_bug.cgi?id=394544

Bug ID: 394544
Summary: Export to inaturalist
Product: digikam
Version: 5.9.0
Platform: Other
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: general
Assignee: digikam-bugs-***@kde.org
Reporter: ***@gmail.com
Target Milestone: ---

Hi there,

As a powerful digikam user and also a naturalist, I think that an export
feature to inaturalist would be very helpful.

background:

inaturalist is a community website which allow to identify both plants and
animals based upon pictures: we submit a picture, add geotag and a date if
there are not embedded in the metadatas, suggest a species and the community
will help us to define very precisely the species which have been shooted.

main feature request:

being able to export to inaturalist from digikam like the google photos export
does (automatic login, save credentials, convert raw files into the supported
formats by inaturalist).

others useful features requests:

- Being able to identify from digikam which files have been submitted and which
not: it will avoid to being able to compare your submissions from inaturalist
website and digikam, task which can be time consuming.

- Having an option which doesn't allow submission of pictures which don't have
embedded geotag: this is not a real problem in inaturalist to set afterward the
geotag, but this is another time we'll have to contribute afterward in
inaturalist: it should be done only in digikam, and inaturalist would be there
only for identification.

- being able to embed the taxonomy which have been defined in inaturalist in
the pictures tags: taxnonomy is a very complex classification, and copy them in
the pictures tags is a very long task if we do numerous submissions.
From my side, I copy all the taxonomy found in inaturalist in my pictures. Our
exchanges on the mailing list highlight that not everyone copy all the taxonomy
so perhaps being able to configure which part of the taxonomy should be copied
would be useful. Take care: taxonomy is provided in differents languages. We
should be able to configure in which lang the taxonomy would be embedded.

[b***@kde.org]

https://bugs.kde.org/show_bug.cgi?id=394544

***@gmail.com changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com
Component|general |Export-WishForNewTools

[Ben Armstrong]

https://bugs.kde.org/show_bug.cgi?id=394544

Ben Armstrong <***@debian.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@debian.org

--- Comment #1 from Ben Armstrong <***@debian.org> ---
See https://www.inaturalist.org/pages/developers and
https://www.inaturalist.org/pages/api+reference which provides a place for
developers to start on this.

I'm trying to use Digikam to establish a photo processing workflow entirely
based on open source software.

On the input/import end, I'm using OsmAnd on Android to collect GPS tracks,
OpenCamera on Android to take photos. Then I use Digikam to GPS correlate
tracks & photos from my discrete camera (and also to supplement Android photos
with DOP values from the OsmAnd tracks, which the Android platform doesn't yet
support recording in EXIF natively). Currently, I do all other editing & photo
processing within Digikam.

For exporting, I typically publish (currently via batch uploads of files
through the web interfaces of each platform) to five different target
platforms: Strava (a group for stewards of our local wilderness trail),
Facebook (valuable to support discussions with a broader community not on other
platforms), Flickr (mostly as fairly large, "free" cloud storage), Wordpress
(self-hosted), and iNaturalist. Anything I can do to automate / optimize / cut
out redundancy in my workflow would greatly improve life for me.

A significant barrier in this workflow to uploading efficiently to the
iNaturalist platform is submissions through their web interface of large photo
sets. In Chromium, it is necessary to partition sets of greater than about 30
photos at a time into subsets, otherwise my Atom-based workstation with 8G RAM
runs out of memory to handle the page. Integration with Digikam done properly
would likely help with this.

The main feature request & other useful features all sound like things that
would help me too. I'd love to see something started, and then those additional
requests filed as separate wishlists once work is underway.

As a professional software developer, primarily in Ruby these days, but with
some proficiency in other languages, and also as a Debian developer of some
years, helping develop an iNaturalist export extension for digikam is certainly
something I'd be interested in exploring. I must caution, though, that I have
no KDE development experience. I don't think that's a huge barrier to me making
some sort of contribution, but it probably rules me out as being a driver for
this effort.

[b***@kde.org]

https://bugs.kde.org/show_bug.cgi?id=394544

--- Comment #2 from ***@gmail.com ---
Hi Ben,

First thanks to propose to contribute in goal to make a new export tool for
digiKam.

Since 5.0.0, and more with 6.0.0, we reduce drastically the KDE dependencies to
digiKam. You don't need to know the KDE API to write a new export tool. Only
Qt5 API is required. This simplify to developers work and increase the
portability everywhere.

Qt5 is a very powerfull C++ framework. all digiKam is based on Qt5.

The export tools source code, are located especially at this place :

https://cgit.kde.org/digikam.git/tree/core/utilities/assistants/webservices

And currently, all tools are step by step ported to O2 authentification by a
student to simplify the users workflow.

We can guide you understand the current code and the internal DK API than you
can use in these tools. Note that all export tools are available everywhere now
in digiKam and Showfoto, as in icon-view, image editor and light table (this is
not the case with previous releases).

Best

Gilles Caulier

[Ben Armstrong]

https://bugs.kde.org/show_bug.cgi?id=394544

--- Comment #3 from Ben Armstrong <***@debian.org> ---
Gilles,

I appreciate that when building & supporting a plugin ecosystem, having the
freedom of language choice through bindings for those languages has a cost, so
by limiting it to C++ and Qt5, it is less of a burden to support, but
unfortunately, that diminishes my interest in writing any code for this
wishlist, as any such code would be novice-level at best, and both user
communities (iNaturalist, Digikam) deserve better than that.

Still, I'd be happy to play some supporting role here, so that includes clearly
articulating what would be useful in such an extension, testing & debugging any
code written (if it gets that far), or any other way I can help.

If I cannot realize a substantially Digikam-centred workflow, perhaps I could
take a different tack, prototyping something standalone that works with my
Digikam collection.

And in any case, here are some issues I'm currently facing with Digikam's
support for GPS tags that a plugin like this could help with:

- It is important to submit accuracy with each observation created on
iNaturalist. While there are ways to collect that data automatically, I have
yet to determine how to merge it into my photo collection and submit in a form
that iNat accepts.

- Unfortunately, while OsmAnd (which I use for GPS tracking) stores HDOP per
trackpoint, I know of no way horizontal positioning error can be computed from
that figure & then written out to the corresponding EXIF tag
(GPSHPositioningError). And that's the only mechanism they have to input
accuracy from photos submitted on the web.

- Indeed, even after using Digikam's GPS correlation to merge HDOP from my
tracks, it doesn't loook like Digikam writes that out, not even to GPSDOP, in
the EXIF (I'd have to use exiftool for that).

- And even if Digikam did that, iNat ignores GPSDOP and only accepts
GPSHPositioningError.

- Therefore, while I can use Digikam's GPS correlator to import those HDOP
values into Digikam per photo, I am currently without any way (via Digikam or
otherwise) to turn that into usable data for my observation submissions.

If the plugin would ease this particular pain point, it would greatly improve
the workflow:

- snap shots in the field while taking GPS track with HDOP
- import into Digikam for processing
- GPS edit, using correlator to merge HDOP values
- submit to iNat with accuracy info included in a form iNat will accept

Thanks for considering this request.

Ben

[b***@kde.org]

https://bugs.kde.org/show_bug.cgi?id=394544

--- Comment #4 from ***@gmail.com ---
WARNING : with digiKam 6.0.0 and later, we will not support kipi interface
anymore. All tools are now located in digiKam core as well for a plan to
provide a more power-full integration with Batch Queue Manager and to be able
to export a workflow on a web-service.

All export tools are now available everywhere : album view, Image editor, Light
table, and Showfoto. Previously, only album view from digiKam core was able to
deal with export tools through libkipi.

All export tools are now located here :

https://cgit.kde.org/digikam.git/tree/core/utilities/assistants/webservices

All export tools use now a dedicated interface to communicate with the
application :

- digiKam (database) :

https://cgit.kde.org/digikam.git/tree/core/libs/database/utils/ifaces/dbinfoiface.h

- Showfoto (files metadata) :

https://cgit.kde.org/digikam.git/tree/core/utilities/assistants/common/dmetainfoiface.h


There is not direct use of digiKam database for compatibility with Showfoto.

We plan later to provide a dynamic loading of export tools using a plugins
mechanism. This will reduce overloading of the internal core libraries. A
dedicated devel branch have been created for that, but it's not yet complete:

https://cgit.kde.org/digikam.git/tree/?h=development/dplugins

But take a care, digiKam export tools as plugins will not be shared with
another external application. API will still private and only shared between
Showfoto and digiKam core. The experience with libkipi was bad and complex to
maintain/extend in time.

Gilles Caulier