Hi everyone, First post here, so if I am not in the right place, please let me know :) Just a thought, seeing that Digikam uses databases to store data (MySQL for example), what do others think about having a version of Digikam that would run on a webserver and you access it via a browser? Sure you may not get every feature that you have on the current version working but it maybe useful for when you want to let other people view your photos or maybe do a quick upload of photos while you are away on holiday for doing backups etc. What are your thoughts on this? Thank you :) Daniel |
I think it would be great to have a web interface as a quick way to search
for pictures in your catalog, even if it's read only. That way, you could use Digikam to catalog everything, and the web interface for when you want to find one specific picture quickly, even in your phone, by folder, tags, date, or by the people in it. But that sounds like a lot of work. Actually, someone back in 2005 already proposed this feature: https://bugs.kde.org/show_bug.cgi?id=108873 I personally use Filerun (https://filerun.com/) for this purpose, which is self-hosted and free for personal use. It can read the metadata in pictures and you can search by date and tags, and more importantly, uses current directory trees, so you don't have to copy or move any pictures. -- Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html |
Would it be worth looking into this again? Much of the database schema is already there, may need to add 2 tables for users and permissions. After that all that is needed is some decent PHP, CSS, HTML and some jquery coding and as someone else said in the comments one would have a killer app that could be a real game changer. I already have some codes sitting around that deals with template systems, auth etc. On Sun, Apr 7, 2019 at 10:25 AM woenx <[hidden email]> wrote: I think it would be great to have a web interface as a quick way to search |
hi, Go on github, and search "digikam" There are at least 3 projects for a web interface. I never experienced this... Best Gilles Caulier Le dim. 7 avr. 2019 à 03:01, Daniel Fenn <[hidden email]> a écrit :
|
Thank you for the head up, having a look at then now, seeing how hold those projects are, just seeing if it worth forking those out or just start from the ground up. Biggest thing is, they most likely won't work on PHP 7 and then there the database schema that may have changed over the years too. On Sun, Apr 7, 2019 at 1:39 PM Gilles Caulier <[hidden email]> wrote:
|
In reply to this post by danielx386
Le 07/04/2019 à 01:40, Daniel Fenn a écrit :
> for example), what do others think about having a version of Digikam > that would run on a webserver and you access it via a browser? > there are many php web galleries that fits the need. I use Piwigo http://dodin.org/piwigo/index.php it's not always easy to work online, specially when moving, with suboptimal network (hotels) jdd -- http://dodin.org |
Þann 7.4.2019 06:19, skrifaði [hidden email]:
> Le 07/04/2019 à 01:40, Daniel Fenn a écrit : > >> for example), what do others think about having a version of Digikam >> that would run on a webserver and you access it via a browser? >> > > there are many php web galleries that fits the need. I use Piwigo > > http://dodin.org/piwigo/index.php > For years there have been conduits for various web services in Digikam. One thing to consider might be to make an extension for Nextcloud/ownCloud (or any of the federated private FOSS cloud systems); these systems already have solved the handling of users, permissions, file management, some of the metadata, have viewers for images, and plenty of other useful stuff. They also handle versioning, can be extended via plug-ins/extensions, have a huge user-base and are well documented. Some think of these as free private Dropbox on steroids, but there's so much more to it. Perhaps it's an overkill, but people have managed to setup Nextcloud on simple NAS and in QNAS, there's Nexcloud Box for Raspberry Pi, etc... AND there's both web interface(s) and Android/iOS clients, plus the desktop control-panels. I mention this because I think this could provide a vast scope of uses; from simple photo-management on a LAN, to a dedicated image-handling for specific purposes in corporate/institutional environment, e.g. cataloging products or scientific samples with multi-user access. This could perhaps be at least be explored to see if it is doable, where Digikam could fit in and what would be needed for it to work? Just thoughts, Sveinn í Felli |
On dimanche 7 avril 2019 11:11:34 CEST Sveinn í Felli wrote:
> Þann 7.4.2019 06:19, skrifaði [hidden email]: > > Le 07/04/2019 à 01:40, Daniel Fenn a écrit : > >> for example), what do others think about having a version of Digikam > >> that would run on a webserver and you access it via a browser? > > > > there are many php web galleries that fits the need. I use Piwigo > > > > http://dodin.org/piwigo/index.php There's probably a reason that the three php-digikam projects mentioned earlier haven't seen any updates for several years... A few more things to keep in mind: - A web interface to your entire image collection will show exactly that: your entire collection, duplicate and intermediate images included. Probably much more than you want to show the world. - All thumbnails for each album will have to be transmitted (in first approximation). Probably many more than needed in practice. - Your image collection will mostly consist of full-sized originals (raw files or camera jpegs). For web use, that means a lot of network traffic: with modern cameras, even a quarter-size embedded jpeg is easily 5-6 Mpixels, for display sizes closer to 2-3 Mpixels. Remco |
For anyone with Synology, I use their Photostation app and it's a useful way to access my 400k photos via the Web. Search is very fast, and you can update IPTC tags etc from the Web gui. We'll worth a look. On Sun, 7 Apr 2019, 10:29 Remco Viëtor, <[hidden email]> wrote: On dimanche 7 avril 2019 11:11:34 CEST Sveinn í Felli wrote: |
In reply to this post by Gilles Caulier-4
I also worked on one last year, using Symfony4 and Doctrine (php7, etc.) The biggest challenge of using an ORM was the way some relationships were set up, causing thousands of queries to list. Still, the database was fast enough to support it. Now I'd probably use a real full-text search service, like Elastica, which I'm using on other projects. The other challenge was using a remote database, the tradeoff between having super-fast local access v. web-based access. Finally, as mentioned here, there's the issue of users and permissions. Although pretty standard, it gets messy to add. Happy to revive the project and work with others if there's interest. Tac On Sat, Apr 6, 2019 at 11:39 PM Gilles Caulier <[hidden email]> wrote:
|
To be specific, the relationship issue I had a hard time with was the association between the image metadata and the image. Here's my question on StackExchange: I think the data would be easier to work with as a bi-directional relationship. Tac On Sun, Apr 7, 2019 at 9:14 AM Tac Tacelosky <[hidden email]> wrote:
|
Le 07/04/2019 à 15:20, Tac Tacelosky a écrit :
> To be specific, the relationship issue I had a hard time with was the > association between the image metadata and the image. Here's my > question on StackExchange: > > https://stackoverflow.com/questions/49322804/optional-related-doctrine-entity-onetoone-relationship/49323307 > > I think the data would be easier to work with as a bi-directional > relationship. > what I would like to have first is a simple way to create a sidecar file (xml) for metadata * from digikam database to xml it's standard * from/to piwigo database to xml it is probably pretty easy, I simply don't have the necessary time now (my sql knowledge is low) to investigate the goal is to syn digikam and piwigo meta data infos: some are modified on line, others on digikam. sync xml should be pretty easy because files a small and text thanks jdd -- http://dodin.org |
Or what one could do is, hack piwigo to use digikam's database so that there is no need to mess around with xml files etc. May need a few extra tables etc but still.
-----Original Message----- From: Digikam-users <[hidden email]> On Behalf Of [hidden email] Sent: Monday, 8 April 2019 1:06 AM To: [hidden email] Subject: Re: [digiKam-users] Web based interface (in PHP etc) Le 07/04/2019 à 15:20, Tac Tacelosky a écrit : > To be specific, the relationship issue I had a hard time with was the > association between the image metadata and the image. Here's my > question on StackExchange: > > https://stackoverflow.com/questions/49322804/optional-related-doctrine > -entity-onetoone-relationship/49323307 > > I think the data would be easier to work with as a bi-directional > relationship. > what I would like to have first is a simple way to create a sidecar file (xml) for metadata * from digikam database to xml it's standard * from/to piwigo database to xml it is probably pretty easy, I simply don't have the necessary time now (my sql knowledge is low) to investigate the goal is to syn digikam and piwigo meta data infos: some are modified on line, others on digikam. sync xml should be pretty easy because files a small and text thanks jdd -- http://dodin.org |
Le 08/04/2019 à 11:35, [hidden email] a écrit :
> Or what one could do is, hack piwigo to use digikam's database so that there is no need to mess around with xml files etc. May need a few extra tables etc but still. > or have way to directly sync the two databases, but using intermediate file (sidecar) is probably safer, just in case digikam or piwigo want to change they database given the name of the fields respectively in digikam and piwigo the translation may be be simple need only a week work for me, may be only two hours for anybody knowing better sql :-( jdd -- http://dodin.org |
Are we talking about the same piwigo? I gave it a go several months ago and I
really wanted to like it, but I couldn't. Apart from the interface that looked like something from 10 years ago (phpnuke, is that you?), it had some serious rough edges that prevented normal usage, such as displaying any directory that had special characters such as aphostrophes (https://piwigo.org/bugs/view.php?id=3030). Apart from that, I personally prefer to write the metadata in the same picture file instead of sidecar files (although I admit it's usually more reasonable to do use sidecars). I think that periodically scanning the picture folders (or when changes are detected) to populate a database would be more compatible for those who do not use sidecars. I don't know if thumbnails could be extracted from digikam's database or would need to be generated again. -- Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html |
Le 08/04/2019 à 21:07, woenx a écrit :
> Are we talking about the same piwigo? I don't know what you expect. I use Piwigo for a lot of time now, with success http://dodin.org/piwigo/index.php > serious rough edges that prevented normal usage, such as displaying any > directory that had special characters such as aphostrophes > (https://piwigo.org/bugs/view.php?id=3030). like any software it have syntax guidelines. I can use "?" in file names (linux), when Windows wont like them... nor piwigo. use "detox" and voilà http://www.dodin.org/wiki/pmwiki.php?n=Photo.GestionDesImages#toc8 > > Apart from that, I personally prefer to write the metadata in the same > picture file instead of sidecar files the problem is syncing metadata to/from web/local. It's not possible to send or receive full image files only to sync metadata, when moving xml files is easy and cheap. This do not prevent writing also to the images, as I always do jdd -- http://dodin.org |
To answer a question about if thumbnails can be extracted from a database, it depends on the format. Is it an jpg file or something like that? From: [hidden email] Sent: Tuesday, 9 April 2019 5:38 am To: [hidden email] Subject: Re: [digiKam-users] Web based interface (in PHP etc) Le 08/04/2019 à 21:07, woenx a écrit :
|
The thumbnails are stored in format that hardly anyone uses (blanking on the name of it now). In particular, there are no PHP libraries for reading it, even integrating GD, the popular and powerful image manipulation library. I wish there were an option for selecting the thumbnail format, which included jpg and png (and the associated quality and size options). Even if the database were bigger, it would allow much easier access to the thumbnails, without all the complications of re-creating thumbnails from somewhere else. Tac On Mon, Apr 8, 2019 at 4:12 PM Daniel Fenn <[hidden email]> wrote:
|
I wonder if it would be possible to get that changed, not just for this Web project but to make everything accessible for future generations to come. From: Tac Tacelosky Sent: Tuesday, 9 April 2019 9:37 pm To: digiKam - Home Manage your photographs as a professional with the power of open source Subject: Re: [digiKam-users] Web based interface (in PHP etc) The thumbnails are stored in format that hardly anyone uses (blanking on the name of it now). In particular, there are no PHP libraries for reading it, even integrating GD, the popular and powerful image manipulation library. I wish there were an option for selecting the thumbnail format, which included jpg and png (and the associated quality and size options). Even if the database were bigger, it would allow much easier access to the thumbnails, without all the complications of re-creating thumbnails from somewhere else. Tac On Mon, Apr 8, 2019 at 4:12 PM Daniel Fenn <[hidden email]> wrote:
|
Although it might seem like bad programming practice to put jpeg/png blob in a database instead of a filesystem, I'd love that option. In particular, it'd allow a cloud-based solution to not require an disk usage, making it cheaper to deploy. That is, pay for a cloud-based database, then use a free or low-cost deployment like heroku, create a dynamic site, and not need access to the original images to create the thumbnails, nor need access to a disk system in the heroku deployment. A second database could be used, or another table in the database with the image blob, but MUCH better would be an option for how you wanted in the images stored. PNG and JPG rendering will come from a library, so perhaps the developer would be open to this, even if it renders images differently than the current method. Of course, the images could also be stored on s3, but that's considerably more complicated, since the images are de-coupled from the database. On Wed, Apr 10, 2019 at 4:41 AM Daniel Fenn <[hidden email]> wrote:
|
Free forum by Nabble | Edit this page |