How to use the processing information digikam stores

[Anders Lund]

Hi,

 

The digikam image editor stores information on how an image was processed. How can I use that information to perform the same or some of the same steps to another image or images, or to redo the process on the same image?

 

--

Anders

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Gilles Caulier-4]

Hi Anders,

This is not implmented. A whish already exist in bugzilla about this topic...

Gilles Caulier

2014-02-14 23:33 GMT+01:00 Anders Lund <[hidden email]>:

> Hi,
>
>
>
> The digikam image editor stores information on how an image was processed.
> How can I use that information to perform the same or some of the same steps
> to another image or images, or to redo the process on the same image?
>
>
>
> --
>
> Anders
>
>
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users
>

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Anders Lund]

On Lørdag den 15. februar 2014 08:23:10, Gilles Caulier wrote:

> Hi Anders,

>

> This is not implmented. A whish already exist in bugzilla about this

> topic...

 

I back that then :)

 

I'm getting into photo work where that would come in extemely handy, and being able to import those processes from doing them in the editor is much more practical than using batch queue, because it is much more flexible to do correct good image in the editor and then just push the processing.

 

Can you easily find the bug # for the wish?

 

Anders

 

> Gilles Caulier

>

> 2014-02-14 23:33 GMT+01:00 Anders Lund <[hidden email]>:

> > Hi,

> >

> >

> >

> > The digikam image editor stores information on how an image was processed.

> > How can I use that information to perform the same or some of the same

> > steps to another image or images, or to redo the process on the same

> > image?

> >

> >

> >

> > --

> >

> > Anders

> >

> >

> > _______________________________________________

> > Digikam-users mailing list

> > [hidden email]

> > https://mail.kde.org/mailman/listinfo/digikam-users

>

> _______________________________________________

> Digikam-users mailing list

> [hidden email]

> https://mail.kde.org/mailman/listinfo/digikam-users

 

--

Anders

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Marcel Wiesweg]

> This is not implmented. A whish already exist in bugzilla about this
> topic...

The existing backend will be ready for this tasks with minor tweaks. The work
waits in the UI part and all the wishes that will arise (like storing and
organizing the processing steps, preview, bqm integration etc.)

Marcel
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Gilles Caulier-4]

These one for ex. there are certainly others relevant... :

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

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

Gilles Caulier

2014-02-15 11:35 GMT+01:00 Anders Lund <[hidden email]>:

> On Lørdag den 15. februar 2014 08:23:10, Gilles Caulier wrote:
>
>> Hi Anders,
>
>>
>
>> This is not implmented. A whish already exist in bugzilla about this
>
>> topic...
>
>
>
> I back that then :)
>
>
>
> I'm getting into photo work where that would come in extemely handy, and
> being able to import those processes from doing them in the editor is much
> more practical than using batch queue, because it is much more flexible to
> do correct good image in the editor and then just push the processing.
>
>
>
> Can you easily find the bug # for the wish?
>
>
>
> Anders
>
>
>
>> Gilles Caulier
>
>>
>
>> 2014-02-14 23:33 GMT+01:00 Anders Lund <[hidden email]>:
>
>> > Hi,
>
>> >
>
>> >
>
>> >
>
>> > The digikam image editor stores information on how an image was
>> > processed.
>
>> > How can I use that information to perform the same or some of the same
>
>> > steps to another image or images, or to redo the process on the same
>
>> > image?
>
>> >
>
>> >
>
>> >
>
>> > --
>
>> >
>
>> > Anders
>
>> >
>
>> >
>
>> > _______________________________________________
>
>> > Digikam-users mailing list
>
>> > [hidden email]
>
>> > https://mail.kde.org/mailman/listinfo/digikam-users
>
>>
>
>> _______________________________________________
>
>> Digikam-users mailing list
>
>> [hidden email]
>
>> https://mail.kde.org/mailman/listinfo/digikam-users
>
>
>
> --
>
> Anders
>
>
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users
>

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Gilles Caulier-4]

Marcel,

This can be a subject to propose to students this summer ?

Gilles

2014-02-15 18:51 GMT+01:00 Marcel Wiesweg <[hidden email]>:

>
>> This is not implmented. A whish already exist in bugzilla about this
>> topic...
>
> The existing backend will be ready for this tasks with minor tweaks. The work
> waits in the UI part and all the wishes that will arise (like storing and
> organizing the processing steps, preview, bqm integration etc.)
>
> Marcel
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[M. Fioretti]

Greetings,

I have a computer here running digikam 3.2.0 on Fedora 17 x86_64.

I just noticed, starting the program from the command line, that it
issues these warnings:

#> QSqlDatabasePrivate::removeDatabase: connection 'ConnectionTest' is still in use, all queries will cease to work.
digikam(14981)/digikam (core): Reached inotify limit

I already searched for both warnings separately, but found nothing
relevant, or anyway explaining **what** was happening and why.

should I worry? What should I do about them?

Thanks
        Marco
--

M. Fioretti http://mfioretti.com                   http://stop.zona-m.net

Your own civil rights and the quality of your life heavily depend on how
software is used *around* you
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Teemu Rytilahti]

M. Fioretti wrote:

> Greetings,

Hello,

> #> QSqlDatabasePrivate::removeDatabase: connection 'ConnectionTest' is
> #> still in use, all queries will cease to work.

This one has something to do with the database backend and is happening to
everyone I think, it's a bug I'd assume and may cause some weird effects,
but I haven't noticed any (using sqlite here).

> digikam(14981)/digikam (core): Reached inotify limit

This one just means that the limit for inotify handles is most likely full
(or kernel failed to allocate resources for it). This could also be a bug,
I'm not sure whether inotify is able to watch directories recursively, but
at the moment the watches are being set per album directory. And that most
likely causes problems, if you have a lot of albums and/or sub-albums.

sysctl fs.inotify.max_user_watches will give you how many handles is
possible to have, you can also change that value.

--
Best Regards,
Teemu Rytilahti


_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Teemu Rytilahti]

Teemu Rytilahti wrote:

Ah, sorry. Just realized that this is the users list, so I'm going to put
the things in user-understandable format.

>> #> QSqlDatabasePrivate::removeDatabase: connection 'ConnectionTest' is
>> #> still in use, all queries will cease to work.
>
> This one has something to do with the database backend and is happening to
> everyone I think, it's a bug I'd assume and may cause some weird effects,
> but I haven't noticed any (using sqlite here).

I think this is just used to check if the connection to the database (or in
case of sqlite, to the file) can be estabilished and that Digikam can make
the modifications there. So it's probably not an issue.

>> digikam(14981)/digikam (core): Reached inotify limit
>
> This one just means that the limit for inotify handles is most likely full
> (or kernel failed to allocate resources for it). This could also be a bug,
> I'm not sure whether inotify is able to watch directories recursively, but
> at the moment the watches are being set per album directory. And that most
> likely causes problems, if you have a lot of albums and/or sub-albums.
>
> sysctl fs.inotify.max_user_watches will give you how many handles is
> possible to have, you can also change that value.

And this means that there are too many folders in the collection, so a new
directory could not be added to the list of watched folders. That means that
new items (or new folders) appearing inside that can not be monitored for
changes (new files, removed files).

--
Best Regards,
Teemu Rytilahti


_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Jürgen Karbach]

Hello Marcel,

Does this affect / include the idea, I posted in topic / thread
„Best Way to Backup‟ ?

>  how are you recording your work between the backups?
>
> Is there a logging capability?
> Good to know, which files are affected.
> Better to know, which steps has been done to each file.
>
> I am dreaming of a detailed record of all steps,
> that will be work like a script or batch if needed.

I got this idea, reading Simon Cropper‛s warning

> Remember that it might take you a few days or even a week to notice a
> file has gone missing or the database has become corrupt. The only way
> to recover from this situation is going back to a previous backup.


Jürgen
--
H. Jürgen Karbach
[hidden email]

Am Samstag, 15. Februar 2014, 18:51:12 schrieb Marcel Wiesweg:

> > This is not implmented. A whish already exist in bugzilla about this
> > topic...
>
> The existing backend will be ready for this tasks with minor tweaks. The
> work waits in the UI part and all the wishes that will arise (like storing
> and organizing the processing steps, preview, bqm integration etc.)
>
> Marcel
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Marcel Wiesweg]

> Marcel,
>
> This can be a subject to propose to students this summer ?

Yes, regarding scope and difficulty this can be very well suited for a GSoC
project
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Marcel Wiesweg]

> Does this affect / include the idea, I posted in topic / thread
> „Best Way to Backup‟ ?
>
> >  how are you recording your work between the backups?
> >
> > Is there a logging capability?
> > Good to know, which files are affected.
> > Better to know, which steps has been done to each file.

For photo editing, the steps will be recorded in the metadata.
(This works regardless of any metadata format issues because for any file that
digikam can create, it also knows how to write metadata)
The system is designed to be able to locate any images related to a given
image, and display the relation and editing steps. It is not primarily
desigend to find out which files were edited in a given period of time.
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[M. Fioretti]

On Tue, Feb 18, 2014 00:51:41 AM +0100, Teemu Rytilahti wrote:

> Teemu Rytilahti wrote:
>
> Ah, sorry. Just realized that this is the users list, so I'm going to put
> the things in user-understandable format.
>
> >> #> QSqlDatabasePrivate::removeDatabase: connection 'ConnectionTest' is
> >> #> still in use, all queries will cease to work.
> >
> > This one has something to do with the database backend and is happening to
> > everyone I think, it's a bug I'd assume and may cause some weird effects,
> > but I haven't noticed any (using sqlite here).
>
> I think this is just used to check if the connection to the database (or in
> case of sqlite, to the file) can be estabilished and that Digikam can make
> the modifications there. So it's probably not an issue.
>
> >> digikam(14981)/digikam (core): Reached inotify limit
> >
> > This one just means that the limit for inotify handles is most likely full
> > (or kernel failed to allocate resources for it). This could also be a bug,
> > I'm not sure whether inotify is able to watch directories recursively, but
> > at the moment the watches are being set per album directory. And that most
> > likely causes problems, if you have a lot of albums and/or sub-albums.
> >
> > sysctl fs.inotify.max_user_watches will give you how many handles is
> > possible to have, you can also change that value.
>

thanks Teemu for the explanation. I didn't answer earlier because,
until this week, I simply had no occasion to go back to that specific
computer and work on this issue. Now I confirm that increasing the
inotify limit and letting digikam rebuild its thumbnail database fro
scratch fixed the problems, AFAICT.

Thanks again,
Marco
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users