Re: [Tracker] exiftool vs gstreamer

[Alexey Fisher <bug-track fisher-privat net>]

Am Montag, den 22.03.2010, 17:41 +0200 schrieb Ivan Frade:
> Hi,
>
> On Mon, Mar 22, 2010 at 2:24 PM, Alexey Fisher
> <bug-track fisher-privat net> wrote:
>         Am Montag, den 22.03.2010, 11:37 +0000 schrieb Martyn Russell:
>         
>         
>         
>         I see.
>         
>         About EXIF in RIFF i get your point and really like to see it
>         in
>         gstreamer.
>         
>         Than other question. For short time there was some sort of
>         call to all
>         developers to use tracker as backend for management programs
>         like
>         f-spot, rhythmbox ... i like tis idea.
>         
>         But now after i took a look to the source of tracker i see you
>         make own
>         extractors for tiff, jpg and png. some times you use litexif
>         for this.
>         What is about RAW image formats? gstreamer is not answer for
>         this.
>
> Exactly, we complete some formats with our own extractors. In some
> cases because it is more efficient (mp3) in other cases because it
> doesn't make sense to have them in gstreamer (powerpoint).
>
>
>         I think it will be real challenge to maintain it by your self.
>         So it
>         make me worry that app like Solang will take some years before
>         it will
>         be useful to manage photos.
>  
> And what is the solution for Solang? Rewrite yet another extraction
> code? You can also argue that at least that extraction code is managed
> only in one location (tracker) and not every project doing its own
> mag.

Sorry i do not wont to start flame war here. Just try to explain my
problem:
current EXIF state is in really bad shape, there is different tools and
libraries wich try to extract the data in different way. Every of them
is not perfect, libexif for example can read JPG but can't handle NEF.
exiftool is perl and not so popular. and so on..  and so on.

I wont to write really small program but in need data from files. It
seems to be a great idea to base it on tracker (like for example solang
do it). Now is the problem:
1) video/audio = tracker<-gstreamer = bad (do not support exif in riff)
2) jpg images = tracker<-own extractor(+libexif) = good
3) raw images = tracker<-not supported(libexif cant do it too) = bad
4) file relation based on DCIM is not present. 

this mean problem for me and i realized it will the problem for solang,
wich i hoped will be good integrated replacement for f-spot. 

Second problem: programm A use libexif, programm B use exiv2, program C
use exiftool.

I'm an photograph and have some unsupported formats, so if i use all
three tools i need to bug all three developers (this normally take
really long time) or to write patches by my self (this take long time
too).

I was shocked after i found tracker use some own extractors. It mean for
me more wore and more time with developers.

ok. <frustration of/>, to the solution. 

1) video/audio - I talked with gstreamer people and probably they will
write exif parser for gstreamer. May be i will write some of this too,
will see.
2) JPG is done
3) RAW. i do not have so many time to make complete new extractor for
RAW and keep it up to date. Do you have so match resources? Still do not
won't to use third part libs?
4) DCIM. this was my actual target. Still trying to talk with you...

So if point 3 and 4 can't be done with tracker. I can't even start my
app, or i should do it without tracker. But tracker still need to learn
do 3 and 4.

Regards,

Alexey