Exiv2 bug reports
Locked
123
123
 
|
Hi Gilles,
just wanted to get back on the question of the suitability of the C++ Interface for ExifTool for DigiKam. Perhaps you have found some time already to take a look at it? Best, NeiNei On 11.03.2017 18:59, Gilles Caulier wrote: > Effectively, it's interesting. I will take a look... > > Gilles Caulier > > 2017-03-11 18:09 GMT+01:00 Andrey Goreev <[hidden email] > <mailto:[hidden email]>>: > > Can this help ? > > http://owl.phy.queensu.ca/~phil/cpp_exiftool/ > <http://owl.phy.queensu.ca/~phil/cpp_exiftool/> > > > Sent from my Samsung Galaxy smartphone. > > -------- Original message -------- > From: Gilles Caulier <[hidden email] > <mailto:[hidden email]>> > Date: 2017-03-11 9:17 AM (GMT-07:00) > To: digiKam - Home Manage your photographs as a professional with > the power of open source <[hidden email] > <mailto:[hidden email]>> > Subject: Re: Exiv2 bug reports > > > > 2017-03-11 16:48 GMT+01:00 Andrey Goreev <[hidden email] > <mailto:[hidden email]>>: > > What tool is creating xmp sidecar files for the video files at > the moment? Exiv2 ? > > > yes > > > > But anyways, there has to be something else in the FOSS world > that can handle the job. > > Video format is just too different from the image format so it > is tough to find a tool that can handle both very well. Exiftool > came pretty close to that but it still lacks of ability to write > many of tags. > > > Exiftool is perl based, not C++ > > Gilles Caulier > > |
|
|
There is some way that we can experiment, but i don't yet found enough time to code something suitable for the moment. It still in my TODO list. Gilles Caulier 2017-03-30 11:23 GMT+02:00 NeiNei <[hidden email]>: Hi Gilles, |
|
|
I'm back to this subject. I receive a mail from Exiv2 forum few days ago. This become more and more critical for the future of Exiv2 : I don't know where is the problem exactly in Exiv2 team. Even if Exiv2 0.26 is released, i fear to see a very long time before a next 0.27 release with video support bugfixes, as i hope. So we need a solid alternative... The only one is Exiftool of course. I see these possible problem to use it in digiKam: - Exiftool is Perl based program, not a lox level library. For each action to perform with metadata, we need to create a process. this is time consuming in a muti-threaded application as digiKam. - Exiftool can be compiled as binary program for the target and It need to be embedded in digiKam as ressource. This is a little bit complicated to do. Even if we do it fro the bundle, the distro based version will still as a script. Performance will be low, i'm sure... - Exiftool syntax to play with metadata tags is completely different than Exiv2. The port will be long and regression tests an hell... Voilà. I'm not yet investigated better for the moment. This kind of change in digiKam core is a very important stage, so, a good analysis of the possibilities need to be done before to start something in source code. Gilles Caulier 2017-03-30 11:43 GMT+02:00 Gilles Caulier <[hidden email]>:
|
|
|
I think we need to leave exiv2 as is for still images and find something else
for video files if possible... There are many options for video files out there. I have dealt with: mediainfo ( I have used it for reading but I am not sure if it can write) ffmpeg (I use it for conversion/compression but I know it can read/write metadata. mediainfo seems to be able to read better IMHO. I have not checked its all metadata writing capabilities) bento4 (I use it to move "xyz" atoms from originals to compressed files because they get lost during ffmpeg compression. [This is a bug of ffmpeg but I don't think it will be fixed soon.] This allows me to see the videos on the map on my Samsung Android phone. I haven't checked all the capabilities of that tool though.) Once we know what we want to do for video files I can volunteer and check every single tool availble on the web and come up with some kind of report. On Sunday, April 9, 2017 12:17:24 PM MDT Gilles Caulier wrote: > I'm back to this subject. > > I receive a mail from Exiv2 forum few days ago. This become more and more > critical for the future of Exiv2 : > > http://dev.exiv2.org/boards/3/topics/2829 > > I don't know where is the problem exactly in Exiv2 team. Even if Exiv2 0.26 > is released, i fear to see a very long time before a next 0.27 release with > video support bugfixes, as i hope. > > So we need a solid alternative... The only one is Exiftool of course. I see > these possible problem to use it in digiKam: > > - Exiftool is Perl based program, not a lox level library. For each action > to perform with metadata, we need to create a process. this is time > consuming in a muti-threaded application as digiKam. > > - Exiftool can be compiled as binary program for the target and It need to > be embedded in digiKam as ressource. This is a little bit complicated to > do. Even if we do it fro the bundle, the distro based version will still as > a script. Performance will be low, i'm sure... > > - Exiftool syntax to play with metadata tags is completely different than > Exiv2. The port will be long and regression tests an hell... > > Voilà. I'm not yet investigated better for the moment. This kind of change > in digiKam core is a very important stage, so, a good analysis of the > possibilities need to be done before to start something in source code. > > Gilles Caulier > > 2017-03-30 11:43 GMT+02:00 Gilles Caulier <[hidden email]>: > > There is some way that we can experiment, but i don't yet found enough > > time to code something suitable for the moment. > > > > It still in my TODO list. > > > > Gilles Caulier > > > > 2017-03-30 11:23 GMT+02:00 NeiNei <[hidden email]>: > >> Hi Gilles, > >> > >> just wanted to get back on the question of the suitability of the C++ > >> Interface for ExifTool for DigiKam. Perhaps you have found some time > >> already to take a look at it? > >> > >> Best, > >> NeiNei > >> > >> On 11.03.2017 18:59, Gilles Caulier wrote: > >>> Effectively, it's interesting. I will take a look... > >>> > >>> Gilles Caulier > >>> > >>> 2017-03-11 18:09 GMT+01:00 Andrey Goreev <[hidden email] > >>> > >>> <mailto:[hidden email]>>: > >>> Can this help ? > >>> > >>> http://owl.phy.queensu.ca/~phil/cpp_exiftool/ > >>> <http://owl.phy.queensu.ca/~phil/cpp_exiftool/> > >>> > >>> > >>> Sent from my Samsung Galaxy smartphone. > >>> > >>> -------- Original message -------- > >>> From: Gilles Caulier <[hidden email] > >>> <mailto:[hidden email]>> > >>> Date: 2017-03-11 9:17 AM (GMT-07:00) > >>> To: digiKam - Home Manage your photographs as a professional with > >>> the power of open source <[hidden email] > >>> <mailto:[hidden email]>> > >>> Subject: Re: Exiv2 bug reports > >>> > >>> > >>> > >>> 2017-03-11 16:48 GMT+01:00 Andrey Goreev <[hidden email] > >>> > >>> <mailto:[hidden email]>>: > >>> What tool is creating xmp sidecar files for the video files at > >>> the moment? Exiv2 ? > >>> > >>> yes > >>> > >>> But anyways, there has to be something else in the FOSS world > >>> that can handle the job. > >>> > >>> Video format is just too different from the image format so it > >>> is tough to find a tool that can handle both very well. Exiftool > >>> came pretty close to that but it still lacks of ability to write > >>> many of tags. > >>> > >>> Exiftool is perl based, not C++ > >>> > >>> Gilles Caulier |
|
|
In reply to this post by Gilles Caulier-4
Le 09/04/2017 à 20:17, Gilles Caulier a écrit :
> I'm back to this subject. > > I receive a mail from Exiv2 forum few days ago. This become more and > more critical for the future of Exiv2 : > > http://dev.exiv2.org/boards/3/topics/2829 > > I don't know where is the problem exactly in Exiv2 team. Even if Exiv2 > 0.26 is released, i fear to see a very long time before a next 0.27 > release with video support bugfixes, as i hope. > > So we need a solid alternative... isn't this a call for a fork? jdd |
|
|
A fork is a possibility. Typically, i proposed to the rest of the team to directly integrate Exiv2 core somewhere in digiKam core, with some part removed that we don't use, as ssh and web support. Forking Exiv2 will be not simple to maintain. Even if all the image support is well implemented in Exiv2, there are always tags list to improve. For the video support a lots of code need to be review and stabilized. So, it's a long work to do, and we have also a lots of bugs to fix in digiKam. So the decision is not simple to take. I'm shared... Gilles Caulier 2017-04-09 22:31 GMT+02:00 jdd <[hidden email]>: Le 09/04/2017 à 20:17, Gilles Caulier a écrit : |
|
|
Le 09/04/2017 à 22:44, Gilles Caulier a écrit :
> A fork is a possibility. Typically, i proposed to the rest of the team > to directly integrate Exiv2 core somewhere in digiKam core, with some > part removed that we don't use, as ssh and web support. > > Forking Exiv2 will be not simple to maintain. Even if all the image > support is well implemented in Exiv2, there are always tags list to > improve. For the video support a lots of code need to be review and > stabilized. So, it's a long work to do, and we have also a lots of bugs > to fix in digiKam. > > So the decision is not simple to take. I'm shared... > reading the post it looks like the author is ready to do the task, may be needs only support and infrastructure? did you contact him directly? sorry, I'm in no way able to help you on programming :-( jdd |
|
|
Take it slowly. We don't know the history behind all this (at least
that's the impression I get from the votes so far). The way I interpret that post is, that there is a founder or other kind of leader that is only partially involved in maintaining exiv2, but has all the keys to the infrastructure in his hand. This needs to be somehow resolved between this person and the people doing the heavy lifting on the code. Calling for taking over exiv2 either as a fork or integrating in digiKam (very bad option in my opinion) is certainly not a good idea. The core team working on digiKam is doing a great job, but certainly has enough on its plate as it stands. digiKam isn't the only software to use exiv2, so going ahead unilateral is anyway inpractical. On 09/04/17 22:50, jdd wrote: > Le 09/04/2017 à 22:44, Gilles Caulier a écrit : >> A fork is a possibility. Typically, i proposed to the rest of the team >> to directly integrate Exiv2 core somewhere in digiKam core, with some >> part removed that we don't use, as ssh and web support. >> >> Forking Exiv2 will be not simple to maintain. Even if all the image >> support is well implemented in Exiv2, there are always tags list to >> improve. For the video support a lots of code need to be review and >> stabilized. So, it's a long work to do, and we have also a lots of bugs >> to fix in digiKam. >> >> So the decision is not simple to take. I'm shared... >> > > reading the post it looks like the author is ready to do the task, may > be needs only support and infrastructure? > > did you contact him directly? > > sorry, I'm in no way able to help you on programming :-( > > jdd > |
|
|
In reply to this post by jdd@dodin.org
As i know, Robin has planed to move Exiv2 code to github, or something in the team. I don't know exactly.
But the problem is more complex than that. Few month ago, seeing all the problem in digiKam due of bad video support in Exiv2, i proposed to Robin to revisit the Exiv2 code, using the same technics used in digiKam : 1/ Pass all the code to static analyzer and fix the dysfunctions. 2/ only give the minimalist visibility of Exiv2 implementations from client side, to prevent to break the binary compatibility of the library. 3/ Clean up code to permit to install more than one version at the same time on a computer. I know serious problem in this kind of situation. This is very problematic. 4/ complete cmake port and remove the automake/autoconf, to limit code to maintain. None of this points have been accepted. I insisted by Robin start to use weird words about me. Recently, after to report as UPStream some dysfunction, the bugs have been rejected as well. Robin said that digiKam is a monster badly implemented which perturb tha Exiv2 project. Following this state, you can understand me to still polit, and left to support Exiv2, and especially Robin ad the way trying to work in open source. I have nothing to said to someone speaking to me like this. Voilà, the problem is more human than technical... It's like in the real life. Gilles Caulier 2017-04-09 22:50 GMT+02:00 jdd <[hidden email]>: Le 09/04/2017 à 22:44, Gilles Caulier a écrit : |
|
|
In reply to this post by Simon Frei
Robin talk about Andreas, the original author of Exiv2. He is a very good developer. I meet him in the real life, through a digiKam developer reunion. For a work opportunity, he is less and less available to maintain Exiv2 since few years now. Robin take the role of manager as well, but i suspect that the communication is not perfect between both. Robin management is special, and personalty, i don't like how he communicate with the team members the other client project using Exiv2. But this is just my viewpoint. Gilles Caulier 2017-04-09 22:58 GMT+02:00 Simon Frei <[hidden email]>: Take it slowly. We don't know the history behind all this (at least |
|
|
In reply to this post by AndriusWild
I don't think the community will let exiv2 disappear. There are too many good projects that use exiv2, e.g. digiKam and darktable. At the same time I don't believe exiv2 will ever support video files well. Metadata of still images and metadata of video files are just way too different. Sent from my Samsung Galaxy smartphone. -------- Original message -------- From: Gilles Caulier <[hidden email]> Date: 2017-04-09 3:11 PM (GMT-07:00) To: digiKam - Home Manage your photographs as a professional with the power of open source <[hidden email]> Subject: Re: Exiv2 bug reports Robin talk about Andreas, the original author of Exiv2. He is a very good developer. I meet him in the real life, through a digiKam developer reunion. For a work opportunity, he is less and less available to maintain Exiv2 since few years now. Robin take the role of manager as well, but i suspect that the communication is not perfect between both. Robin management is special, and personalty, i don't like how he communicate with the team members the other client project using Exiv2. But this is just my viewpoint. Gilles Caulier 2017-04-09 22:58 GMT+02:00 Simon Frei <[hidden email]>: Take it slowly. We don't know the history behind all this (at least |
|
|
In reply to this post by AndriusWild
On Sun, 2017-04-09 at 12:37 -0600, [hidden email] wrote:
> I think we need to leave exiv2 as is for still images and find > something else for video files if possible... I agree with this. For me the biggest problem with digikam is that I cannot store metadata inside video files. The digikam4.db database file is good but from experience I know that it can get corrupted and I relied on the image file metadata to restore it. > Once we know what we want to do for video files I can volunteer and > check every single tool availble on the web and come up with some > kind of report. That would be great. |
|
|
All,
I've been in touch with Robin about this, and in fact we have a presentation at LGM this past weekend together. He and Andreas have come to hopefully resolve the problems, and he expects to have a release out as soon as possible (the GIMP team is also watching this). Robin is also planning on moving away from the project at the end of the year to go back to school, so he is actively looking for a new engineer to transition into the project and continue the work. It might be worth holding off for a little bit to see if releases start coming. I understand that the work is done on 27, it's just awaiting Andreas to be released, which should be soon (fingers crossed). Pat On Mon, Apr 24, 2017 at 3:33 PM Jim Gomi <[hidden email]> wrote: On Sun, 2017-04-09 at 12:37 -0600, [hidden email] wrote: -- https://patdavid.net GPG: 66D1 7CA6 8088 4874 946D 18BD 67C7 6219 89E9 57AC |
|
|
Dear all,
in addition to Pat's mail, Robin Mill made a new posting on the future of exiv 2 a few hours ago: http://dev.exiv2.org/boards/3/topics/2830 As Pat noted, it seems that we still have to keep our fingers crossed. NeiNei On 25.04.2017 03:00, Pat David wrote: > All, > > I've been in touch with Robin about this, and in fact we have a > presentation at LGM this past weekend together. > > He and Andreas have come to hopefully resolve the problems, and he > expects to have a release out as soon as possible (the GIMP team is also > watching this). > > Robin is also planning on moving away from the project at the end of the > year to go back to school, so he is actively looking for a new engineer > to transition into the project and continue the work. It might be worth > holding off for a little bit to see if releases start coming. I > understand that the work is done on 27, it's just awaiting Andreas to be > released, which should be soon (fingers crossed). > > Pat > On Mon, Apr 24, 2017 at 3:33 PM Jim Gomi <[hidden email] > <mailto:[hidden email]>> wrote: > > On Sun, 2017-04-09 at 12:37 -0600, [hidden email] > <mailto:[hidden email]> wrote: > > I think we need to leave exiv2 as is for still images and find > > something else for video files if possible... > > I agree with this. For me the biggest problem with digikam is that I > cannot store metadata inside video files. > The digikam4.db database file is good but from experience I know that > it can get corrupted and I relied on the image file metadata to restore > it. > > > Once we know what we want to do for video files I can volunteer and > > check every single tool availble on the web and come up with some > > kind of report. > > That would be great. > > -- > https://patdavid.net > GPG: 66D1 7CA6 8088 4874 946D 18BD 67C7 6219 89E9 57AC |
|
|
There is something that i don't understand well... If the release depend only of the credential of Exiv2.org web site, there is only a right access to the website to only post and register the new release as well. Releasing source code has nothing to do with a website ! For me it's a wrong problem : 1/ release the source code 2/ post the announcement If 2/ cannot be done due to lack of credential, create a new web site as well. But as i already recommended to Robin, the source code is the big priority. I have a big exprience in open source, i know Exiv2 source code also to have already contributed, and this is the main goal. Fix the problems with client applications : 1/ list all main problems 2/ order by priority 3/ fix step by step. 4/ release more frequently the library (not all the 2 years, but all 6 month) I already talk with Robin about this topic. The feedback was been catastrophic. To resume : digiKam project is the heel and badly manged and implemented. This is why, for now, you can forget to talk about Exiv2 project to me... I seriously plan Exiftool migration. It will take a while but at least Exiftool is alive and constructive... I'm in contact with Exiftool team... Voilà. This is just the viewpoint from an human who code a little bit at free time... Gilles Caulier 2017-04-25 8:39 GMT+02:00 NeiNei <[hidden email]>: Dear all, |
|
|
Gilles, just my viewpoint from someone who used to code a little bit at free
time: Using an out-of-process solution like exiftool has the bonus that crashes dont crash digikam. It has the drawback of performance; metadata reading is quite expensive in some situations. Inter-process communication can be a pain. If it's based on Perl, this can be a problem for easy deploying on other platforms. And I dont know if you speak Perl really well. We have invested greatly in our exiv2-based infrastructure. There are hundreds of bug fixes and problem solutions in the code that depends directly on exiv2 via C++. In order to port all this logic, and to optimize IPC, you'd need custom parts in the other process - probably written in Perl? - that need to be developed by digikam and kept up to date with digikam. In the end, make a calculation if all this work is really worth it. Marcel > > I seriously plan Exiftool migration. It will take a while but at least > Exiftool is alive and constructive... I'm in contact with Exiftool team... > > Voilà. This is just the viewpoint from an human who code a little bit at > free time... |
|
|
Hi Marcel, This is a more simple solution, always based to C++ with ExifTool : This basis o this interface must do the job for all common call done by digiKam in Exiv2. Of course the tags syntax must be ported from Exiv2 to ExifTool. The second problem is the Perl stuff.. Here, also there is a solution to provide a machine compiled Exiftool in digiKam as a ressource. This will improve very well the performances. As i can see, LightRoom use this solution in background (yes I see Exiftool used while testing). ExifTool.exe precompiled already exists for Windows for ex. So it's possible to do for all platforms. There is some reponse about this topic here : Gilles 2017-04-25 12:53 GMT+02:00 Marcel Wiesweg <[hidden email]>: Gilles, just my viewpoint from someone who used to code a little bit at free |
|
|
Hi there,
the long awaited release of Exiv2 v0.26 should be released today according to http://dev.exiv2.org/boards/3/topics/2830 However, I do not know wether or how it will change the situation for DigiKam. As far as I understood Gilles thoroughly checks for alternatives in order to ensure a working, evolving and reliable metadata editor for DigiKam. NeiNei On 25.04.2017 22:38, Gilles Caulier wrote: > Hi Marcel, > > This is a more simple solution, always based to C++ with ExifTool : > > http://owl.phy.queensu.ca/~phil/cpp_exiftool/ > > This basis o this interface must do the job for all common call done by > digiKam in Exiv2. Of course the tags syntax must be ported from Exiv2 to > ExifTool. > > The second problem is the Perl stuff.. Here, also there is a solution to > provide a machine compiled Exiftool in digiKam as a ressource. This will > improve very well the performances. As i can see, LightRoom use this > solution in background (yes I see Exiftool used while testing). > > ExifTool.exe precompiled already exists for Windows for ex. So it's > possible to do for all platforms. > > There is some reponse about this topic here : > > http://stackoverflow.com/questions/1237286/how-can-i-compile-my-perl-script-so-it-can-be-executed-on-systems-without-perl-i > > Gilles > > 2017-04-25 12:53 GMT+02:00 Marcel Wiesweg <[hidden email] > <mailto:[hidden email]>>: > > Gilles, just my viewpoint from someone who used to code a little bit > at free > time: > > Using an out-of-process solution like exiftool has the bonus that > crashes dont > crash digikam. > It has the drawback of performance; metadata reading is quite > expensive in > some situations. Inter-process communication can be a pain. > > If it's based on Perl, this can be a problem for easy deploying on other > platforms. And I dont know if you speak Perl really well. > > We have invested greatly in our exiv2-based infrastructure. There > are hundreds > of bug fixes and problem solutions in the code that depends directly > on exiv2 > via C++. > > In order to port all this logic, and to optimize IPC, you'd need > custom parts > in the other process - probably written in Perl? - that need to be > developed > by digikam and kept up to date with digikam. > > In the end, make a calculation if all this work is really worth it. > > > Marcel > > > > > I seriously plan Exiftool migration. It will take a while but at least > > Exiftool is alive and constructive... I'm in contact with Exiftool > team... > > > > Voilà. This is just the viewpoint from an human who code a little > bit at > > free time... > > |
|
|
In reply to this post by AndriusWild
I am wondering what darktable, GIMP and other projects relying on exiv2 going to do... Sent from my Samsung Galaxy smartphone. -------- Original message -------- From: NeiNei <[hidden email]> Date: 2017-04-28 7:31 AM (GMT-07:00) To: digiKam - Home Manage your photographs as a professional with the power of open source <[hidden email]> Subject: Re: Exiv2 bug reports the long awaited release of Exiv2 v0.26 should be released today according to http://dev.exiv2.org/boards/3/topics/2830 However, I do not know wether or how it will change the situation for DigiKam. As far as I understood Gilles thoroughly checks for alternatives in order to ensure a working, evolving and reliable metadata editor for DigiKam. NeiNei On 25.04.2017 22:38, Gilles Caulier wrote: > Hi Marcel, > > This is a more simple solution, always based to C++ with ExifTool : > > http://owl.phy.queensu.ca/~phil/cpp_exiftool/ > > This basis o this interface must do the job for all common call done by > digiKam in Exiv2. Of course the tags syntax must be ported from Exiv2 to > ExifTool. > > The second problem is the Perl stuff.. Here, also there is a solution to > provide a machine compiled Exiftool in digiKam as a ressource. This will > improve very well the performances. As i can see, LightRoom use this > solution in background (yes I see Exiftool used while testing). > > ExifTool.exe precompiled already exists for Windows for ex. So it's > possible to do for all platforms. > > There is some reponse about this topic here : > > http://stackoverflow.com/questions/1237286/how-can-i-compile-my-perl-script-so-it-can-be-executed-on-systems-without-perl-i > > Gilles > > 2017-04-25 12:53 GMT+02:00 Marcel Wiesweg <[hidden email] > <mailto:[hidden email]>>: > > Gilles, just my viewpoint from someone who used to code a little bit > at free > time: > > Using an out-of-process solution like exiftool has the bonus that > crashes dont > crash digikam. > It has the drawback of performance; metadata reading is quite > expensive in > some situations. Inter-process communication can be a pain. > > If it's based on Perl, this can be a problem for easy deploying on other > platforms. And I dont know if you speak Perl really well. > > We have invested greatly in our exiv2-based infrastructure. There > are hundreds > of bug fixes and problem solutions in the code that depends directly > on exiv2 > via C++. > > In order to port all this logic, and to optimize IPC, you'd need > custom parts > in the other process - probably written in Perl? - that need to be > developed > by digikam and kept up to date with digikam. > > In the end, make a calculation if all this work is really worth it. > > > Marcel > > > > > I seriously plan Exiftool migration. It will take a while but at least > > Exiftool is alive and constructive... I'm in contact with Exiftool > team... > > > > Voilà. This is just the viewpoint from an human who code a little > bit at > > free time... > > |
|
|
In reply to this post by NeiNei
2017-04-28 15:31 GMT+02:00 NeiNei <[hidden email]>: Hi there, Nothing news with Exiv2 0.26, as i already use current code from svn server in all bundle (so pre 0.26 release) As far as I understood Gilles thoroughly checks for alternatives in order to ensure a working, evolving and reliable metadata editor for DigiKam. yes. No code is done yet. I plan to make some demo code soon with Exiftool c++ interface, when time permit. Gilles |
«
Return to digikam-users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |