digikam PNG workflow...

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

digikam PNG workflow...

Gilles Caulier
Hi all,

Please take a look in my new blog entry and let's me hear you viewpoints...

http://www.digikam.org/?q=node/62
--
Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

Re: digikam PNG workflow...

Tom Albers-2
Op maandag 23 januari 2006 12:31, schreef Gilles Caulier:
> Hi all,
>
> Please take a look in my new blog entry and let's me hear you viewpoints...
>
> http://www.digikam.org/?q=node/62


I think we should not implement this for the 0.9.0 release. Lets not do too
much in one release.

Toma
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

Re: digikam PNG workflow...

Joern Ahrens
On Monday 23 January 2006 13:05, Tom Albers wrote:

> Op maandag 23 januari 2006 12:31, schreef Gilles Caulier:
> > Hi all,
> >
> > Please take a look in my new blog entry and let's me hear you
> > viewpoints...
> >
> > http://www.digikam.org/?q=node/62
>
> I think we should not implement this for the 0.9.0 release. Lets not do too
> much in one release.

I second this.

... Jörn

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

Re: digikam PNG workflow...

Marcel Wiesweg
In reply to this post by Gilles Caulier
Am Montag 23 Januar 2006 12:31 schrieb Gilles Caulier:
> Hi all,
>
> Please take a look in my new blog entry and let's me hear you viewpoints...

> In Camera interface : add a new option to convert on the fly JPEG and RAW
> files to PNG . Exif from RAW file can be get from THM (JPEG thumbnail) file
> provides by camera. Put automaticly all JPEG metadata to dedicaced PNG
> metadata tags.

Would the lossless PNG be equivalent to the RAW file, or does a RAW file
contain more data? If it does, people might want to keep a "digital negative"
additionally to the "working copy" in form of the PNG.

Marcel


>
> http://www.digikam.org/?q=node/62
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

Re: digikam PNG workflow...

Gilles Caulier
Le Lundi 23 Janvier 2006 20:46, Marcel Wiesweg a écrit :

> Am Montag 23 Januar 2006 12:31 schrieb Gilles Caulier:
> > Hi all,
> >
> > Please take a look in my new blog entry and let's me hear you
> > viewpoints...
> >
> > In Camera interface : add a new option to convert on the fly JPEG and RAW
> > files to PNG . Exif from RAW file can be get from THM (JPEG thumbnail)
> > file provides by camera. Put automaticly all JPEG metadata to dedicaced
> > PNG metadata tags.
>
> Would the lossless PNG be equivalent to the RAW file, or does a RAW file
> contain more data? If it does, people might want to keep a "digital
> negative" additionally to the "working copy" in form of the PNG.

Well RAW file formats are the big bazard. there is nothing homogenous and
anyone includes metadata, anyone no. For more information about RAW files
problems, take a look in openraw web site :

http://www.openraw.org/

In all cases, PNG is better than RAW, because :

- It's a GPL-iszed standard... better than DNG that there is no lib to manage
it. It's an non-standard file format provide by a commercial compagny : Adobe
(tm)
- It's can be displayed without problem by all web/file managers.
- It's can be decoded more speedly than RAW files (:=))).
- It's a RW file format, not RAW files.
- It's can be compressed like TIFF with a better ratio, and _LOSSLESS_ !
- It's can be read on all computers. There are no PNG patents...

Using libPNG is easy and ready to use now. I have just need to add any lines
of code in png image loader to backup/extract JPEG metadata (:=)))

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

Re: digikam PNG workflow...

Bugzilla from thorsten.schnebeck@gmx.net

> Well RAW file formats are the big bazard. there is nothing homogenous and
> anyone includes metadata, anyone no. For more information about RAW files
> problems, take a look in openraw web site :
>
> http://www.openraw.org/
>
> In all cases, PNG is better than RAW, because :
>
> - It's a GPL-iszed standard... better than DNG that there is no lib to
> manage it. It's an non-standard file format provide by a commercial
> compagny : Adobe (tm)

DNG is tiff, libtiff supports DNG although I have not found a code sample
showing how to create a DNG file cause interaction with dcraw is for sure
necessary. I know there are programs that create DNG files with libtiff and
dcraw.
While its true that DNG is not an etasblished format you can make a step back
and look at others Adobe open formats like PostScript, TIFF or PDF. All of
these file formats are well known industry standards. Adaption of DNG just
starts (Samsung, Hasselblad) and got some positive comments also from the
openraw campaign.
If you want some samples here is a complete processed toolchain:
ftp://ftp.graphicsmagick.org/pub/outgoing/tiff-exif-dng/


> - It's can be displayed without problem by all web/file managers.
> - It's can be decoded more speedly than RAW files (:=))).
> - It's a RW file format, not RAW files.
> - It's can be compressed like TIFF with a better ratio, and _LOSSLESS_ !
> - It's can be read on all computers. There are no PNG patents...
>
> Using libPNG is easy and ready to use now. I have just need to add any
> lines of code in png image loader to backup/extract JPEG metadata (:=)))

All true, but can digiKam establish a PNG metadata standard? If I create a PNG
file with digiKam with an e.g. embedded ICC profile other programs do not
understand, it is not that good. If we use PNG simply as an extendable
storage container we lose compatibility.

As a user I would vote for a temporary PNG solution and switch over to DNG
when the libs are ready and handy.

YMMV

  Thorsten

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

Re: digikam PNG workflow...

Bugzilla from mikmach@wp.pl
In reply to this post by Gilles Caulier
Dnia poniedziałek, 23 stycznia 2006 12:31, Gilles Caulier napisał:
> Hi all,
>
> Please take a look in my new blog entry and let's me hear you
> viewpoints...

Not sure if forced conversion of RAW files into PNG is good thing.

I think main problem is dealing with JPEGs (lossy etc.).

Maybe would be possible to convert files on the fly when loading image
in IE/Showfoto? Operate on PNG data (lossless), end write to JPEG.

Even today, with relatively cheap HDD space transformation JPEG->PNG can
take big, big space. I've made few tests on my photos. When converting
images with ImageMagick and trying to get best quality (this is the
point of the whole exercise)::

    mogrify -quality 100 -sampling-factor 1x1 -format png *.jpg

Size of images was growing 9-10 times. My modest collection of 4000 pics
currently 2,5G would be ca. 20G. Of course, this is acceptable for some
people, but for other not.

Temporary conversion would give users without much disk space advantages
of lossless format.

m.


_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

Re: digikam PNG workflow...

Gilles Caulier
Le Mardi 24 Janvier 2006 00:03, Mikolaj Machowski a écrit :
> Dnia poniedziałek, 23 stycznia 2006 12:31, Gilles Caulier napisał:
> > Hi all,
> >
> > Please take a look in my new blog entry and let's me hear you
> > viewpoints...
>
> Not sure if forced conversion of RAW files into PNG is good thing.

Are you read my all my comments in this thread ?

>
> I think main problem is dealing with JPEGs (lossy etc.).

No and no JPEG is a lossy quality file format for photograph. It dedicaced to
publish pictures on the web, not to backup a photograph !!!

>
> Maybe would be possible to convert files on the fly when loading image
> in IE/Showfoto

no, only on camera interface because Exif information are availalble by THM
jpeg file on camera only. When you have downloaded RAW file, THM are lost on
your computer

> ? Operate on PNG data (lossless), end write to JPEG.
>
> Even today, with relatively cheap HDD space transformation JPEG->PNG can
> take big, big space. I've made few tests on my photos. When converting
> images with ImageMagick and trying to get best quality (this is the
> point of the whole exercise)::

No and no.  look RAW file size and convert it to PNG with max compression.
Take a care to use 16 bits / color /pixel with dcraw (YES PNG support 16 bits
image, not JPEG)


>
>     mogrify -quality 100 -sampling-factor 1x1 -format png *.jpg
>
> Size of images was growing 9-10 times. My modest collection of 4000 pics
> currently 2,5G would be ca. 20G. Of course, this is acceptable for some
> people, but for other not.
>
> Temporary conversion would give users without much disk space advantages
> of lossless format.

The space disk isn't a problem here ! Who using an hdd 10Gb of capacity ?

In all case if you won't convert JPEG/RW to PNG on the fly, i can. It will be
an option !

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

Re: digikam PNG workflow...

Gilles Caulier
In reply to this post by Bugzilla from thorsten.schnebeck@gmx.net
Le Lundi 23 Janvier 2006 23:18, Thorsten Schnebeck a écrit :

> > Well RAW file formats are the big bazard. there is nothing homogenous and
> > anyone includes metadata, anyone no. For more information about RAW files
> > problems, take a look in openraw web site :
> >
> > http://www.openraw.org/
> >
> > In all cases, PNG is better than RAW, because :
> >
> > - It's a GPL-iszed standard... better than DNG that there is no lib to
> > manage it. It's an non-standard file format provide by a commercial
> > compagny : Adobe (tm)
>
> DNG is tiff, libtiff supports DNG although I have not found a code sample
> showing how to create a DNG file cause interaction with dcraw is for sure
> necessary. I know there are programs that create DNG files with libtiff and
> dcraw.

Yes, i know, but you forget than DNG need to have a lib about a new metadata
format from adobe (tm) : RDF. This is not EXIF and IPTC. Actually, only Exif
metadata are supported by digiKam.

> While its true that DNG is not an etasblished format you can make a step
> back and look at others Adobe open formats like PostScript, TIFF or PDF.
> All of these file formats are well known industry standards. Adaption of
> DNG just starts (Samsung, Hasselblad) and got some positive comments also
> from the openraw campaign.
> If you want some samples here is a complete processed toolchain:
> ftp://ftp.graphicsmagick.org/pub/outgoing/tiff-exif-dng/

yes, but i'm not agree with openraw goal. DNG isn't the unique solution to
make a digital negative file format. PNG can do it easily....

>
> > - It's can be displayed without problem by all web/file managers.
> > - It's can be decoded more speedly than RAW files (:=))).
> > - It's a RW file format, not RAW files.
> > - It's can be compressed like TIFF with a better ratio, and _LOSSLESS_ !
> > - It's can be read on all computers. There are no PNG patents...
> >
> > Using libPNG is easy and ready to use now. I have just need to add any
> > lines of code in png image loader to backup/extract JPEG metadata (:=)))
>
> All true, but can digiKam establish a PNG metadata standard?

Digikam no, but PNG team yes. If tere is any PNG team member in this room...

> If I create a
> PNG file with digiKam with an e.g. embedded ICC profile other programs do
> not understand, it is not that good.

No. there is already a standard PNG tag for ICC profile ! This is not a
problem.

With libPNG, you can create a new tag without compatibilty problem (this is
the power of PNG) Using this way, you don't break compatibilty.

If you want, i can create a PNG file with an EXIF tag to test (:=)))


> If we use PNG simply as an extendable
> storage container we lose compatibility.

NO ! Read libpng documentation before !

>
> As a user I would vote for a temporary PNG solution and switch over to DNG
> when the libs are ready and handy.

I a new DNG loader in the future to Digikam::DImg API, when a GPL lib will be
availalble, or if a contributor want create this loader from strach using
only DNG spec. personnally, i have no time to do it...

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

Re: digikam PNG workflow...

Bugzilla from mikmach@wp.pl
In reply to this post by Gilles Caulier
Dnia wtorek, 24 stycznia 2006 13:23, Caulier Gilles napisał:

> Le Mardi 24 Janvier 2006 00:03, Mikolaj Machowski a écrit :
> > Dnia poniedziałek, 23 stycznia 2006 12:31, Gilles Caulier napisał:
> > > Hi all,
> > >
> > > Please take a look in my new blog entry and let's me hear you
> > > viewpoints...
> >
> > Not sure if forced conversion of RAW files into PNG is good thing.
>
> Are you read my all my comments in this thread ?

Yes.

>
> > I think main problem is dealing with JPEGs (lossy etc.).
>
> No and no JPEG is a lossy quality file format for photograph. It
> dedicaced to publish pictures on the web, not to backup a photograph !!!

But, you know, there is no small number of cameras which are making
photos in JPEG.

> >     mogrify -quality 100 -sampling-factor 1x1 -format png *.jpg
> >
> > Size of images was growing 9-10 times. My modest collection of 4000
> > pics currently 2,5G would be ca. 20G. Of course, this is acceptable
> > for some people, but for other not.
> >
> > Temporary conversion would give users without much disk space
> > advantages of lossless format.
>
> The space disk isn't a problem here ! Who using an hdd 10Gb of capacity
> ?

10G maybe not. But 20G of 40G (standard for cheaper laptops) is still
big part of HDD.

> In all case if you won't convert JPEG/RW to PNG on the fly, i can. It
> will be an option !

OK.

m.


_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

Re: digikam PNG workflow...

Gilles Caulier
In reply to this post by Gilles Caulier
And to medit anymore, take a look in ExifTool PNG page :

http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/PNG.html

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

Re: digikam PNG workflow...

Bugzilla from thorsten.schnebeck@gmx.net
In reply to this post by Gilles Caulier
> Yes, i know, but you forget than DNG need to have a lib about a new
> metadata format from adobe (tm) : RDF. This is not EXIF and IPTC. Actually,
> only Exif metadata are supported by digiKam.

... or xpm. IMHO xmp will be the next generation metatag standard.
Can I embed xmp into PNG?

>
> > While its true that DNG is not an etasblished format you can make a step
> > back and look at others Adobe open formats like PostScript, TIFF or PDF.
> > All of these file formats are well known industry standards. Adaption of
> > DNG just starts (Samsung, Hasselblad) and got some positive comments also
> > from the openraw campaign.
> > If you want some samples here is a complete processed toolchain:
> > ftp://ftp.graphicsmagick.org/pub/outgoing/tiff-exif-dng/
>
> yes, but i'm not agree with openraw goal. DNG isn't the unique solution to
> make a digital negative file format. PNG can do it easily....

Hmm, I do not think so. PNG is already a demosasaic file format. So nothing
new compared to e.g. 16bit-TIFF. DNG is a completely differend beast. It
embeds the RAW matrix using loseless JPEG as internal compression format like
most vendor RAW format do. If there are in future better algorithms for raw
processing you can uses them with DNG but not with PNG. You should also embed
the original data chunk into the DNG  These parts stay read only for ever as
an equivalent of a real digital negative.
http://www.adobe.com/digitalimag/pdfs/dng_primer.pdf

So PNG is a full featured medium range image format but not a RAW format.

> > > - It's can be displayed without problem by all web/file managers.
> > > - It's can be decoded more speedly than RAW files (:=))).
> > > - It's a RW file format, not RAW files.
> > > - It's can be compressed like TIFF with a better ratio, and _LOSSLESS_
> > > ! - It's can be read on all computers. There are no PNG patents...
> > >
> > > Using libPNG is easy and ready to use now. I have just need to add any
> > > lines of code in png image loader to backup/extract JPEG metadata
> > > (:=)))
> >
> > All true, but can digiKam establish a PNG metadata standard?
>
> Digikam no, but PNG team yes. If tere is any PNG team member in this
> room...

The specs are there - when are specs a standard? So maybe its good to evaluate
what other programs support extensive PNG metadata.

>
> > If I create a
> > PNG file with digiKam with an e.g. embedded ICC profile other programs do
> > not understand, it is not that good.
>
> No. there is already a standard PNG tag for ICC profile ! This is not a
> problem.

again, a spec is not a standard.

> With libPNG, you can create a new tag without compatibilty problem (this is
> the power of PNG) Using this way, you don't break compatibilty.
>
> If you want, i can create a PNG file with an EXIF tag to test (:=)))

You can use my "rawimage" too to create PNG with full metatag informations ;-)
I was ahead of the times:
http://mail.kde.org/pipermail/digikam-devel/2005-September/001763.html
so I'm now thing about the next step :o)

> > If we use PNG simply as an extendable
> > storage container we lose compatibility.
>
> NO ! Read libpng documentation before !

Yes, I can read the specs on
http://www.libpng.org/pub/png/spec/1.2/PNG-Chunks.html
but you also know that there is one prominent plattform called "Windows" that
has some problems with PNG on system level. And you read on some places in
the specs that you should ignore if you don't understand a tag.

And that is what I want to say: If digiKam is the only program that uses all
advanced PNG features its of course OK as a notable RAW-R/W alternative but I
think is a special, a niche solution.
 
> > As a user I would vote for a temporary PNG solution and switch over to
> > DNG when the libs are ready and handy.
>
> I a new DNG loader in the future to Digikam::DImg API, when a GPL lib will
> be availalble, or if a contributor want create this loader from strach
> using only DNG spec. personnally, i have no time to do it...

PNG is the best option we have today - but it has not a long future. Its in
the best KDE traditions to use the tools and libs that work today.

And it would be a great feature if digiKams download window has an option to
transform every known filetype to PNG on the fly.


Bye

  Thorsten

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

Re: digikam PNG workflow...

F.J.Cruz
In reply to this post by Gilles Caulier
Hi everybody,

I've the last member that has joined to the team, so I've been waiting to readd the larger number of messages from the others memebers and these are my conclusions:

About file formats:

Actually, RAW format is the more similar to a “Digital Negative” althought it's so far from to be an unified and standar format since each manufacturer has his own format.
DNG, nowdays, is neither an standard nor an extended format, but in a future (no far future?), it'll be able to be a “de facto” standard (like pdf?).
I agree that PNG is, possibly, one of the best formats: metadata, losless compresion, etc. But it has been unable to make its own “hole” between the graphics formats in an “inter-platform” level. (Hmm, I don't know if you can understand this paragraph).
About JPEG format, everybody know that, probably, this is the worst format to image storage/processing: (losly, 8-bits capable only, etc.) but it's  a format that all the digital cameras (i know) are capables to handle.

About digiKam:

If an app wants to be a wide-use tool, for a large range of users, it can't promote a particular file format. It can neither force to use, as default, a particular format, but to allow to the user to set his own choice.
As develop team, we have to try that the level support for all formats, are similars.
We have to find the balance between the developers think about what is technicaly the best and what the user wants/needs: probably, a standar user won't want his photos in png format (altought it's the best)  if the Photo Labs waits for JPEG's or TIFF's files.
We haven't to forget to provide with metadata read/write ability to digiKam. I think it's a feature in great demand.

As Gilles used to say: my 10 €cnt. :-). I hope it's usefull.

PD.: excuse my poor English.

Paco.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Digikam-devel] digikam PNG workflow...

Bugzilla from tomalbers@kde.nl
Op woensdag 25 januari 2006 11:25, schreef [hidden email]:
> these are my conclusions:

Thanks for summarizing Paco, saves me time reading ;-)

> If an app wants to be a wide-use tool, for a large range of users, it can't
> promote a particular file format. It can neither force to use, as default,
> a particular format, but to allow to the user to set his own choice. As
> develop team, we have to try that the level support for all formats, are
> similars. We have to find the balance between the developers think about
> what is technicaly the best and what the user wants/needs: probably, a
> standar user won't want his photos in png format (altought it's the best)
> if the Photo Labs waits for JPEG's or TIFF's files.

We must not forget that a lot of our userbase just want to organise their
pictures and give slideshows to their neighboors. We must not force them to
convert their jpegs to something else. We must keep the interface accessible
for all users. If we can create features for professional users as well,
without confusing the avarage user: great. But a part of our strength is in
the simplicity of using digiKam.

> We haven't to forget to
> provide with metadata read/write ability to digiKam. I think it's a feature
> in great demand.

Yes, but we need to do that smart. I dont think we should simply add every
meta format there is to digiKam. Pick one and do it right, but I dont think
we should do it on our own, it should be a extragear/graphics wide or even
kde wide library.

> As Gilles used to say: my 10 €cnt. :-). I hope it's usefull.

My 0,02, so we are now on 32 cents, right?


> PD.: excuse my poor English.

No need to.

Toma

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

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Digikam-devel] digikam PNG workflow...

Gilles Caulier
Le Samedi 28 Janvier 2006 14:03, Tom Albers a écrit :

> Op woensdag 25 januari 2006 11:25, schreef [hidden email]:
> > these are my conclusions:
>
> Thanks for summarizing Paco, saves me time reading ;-)
>
> > If an app wants to be a wide-use tool, for a large range of users, it
> > can't promote a particular file format. It can neither force to use, as
> > default, a particular format, but to allow to the user to set his own
> > choice. As develop team, we have to try that the level support for all
> > formats, are similars. We have to find the balance between the developers
> > think about what is technicaly the best and what the user wants/needs:
> > probably, a standar user won't want his photos in png format (altought
> > it's the best) if the Photo Labs waits for JPEG's or TIFF's files.
>
> We must not forget that a lot of our userbase just want to organise their
> pictures and give slideshows to their neighboors. We must not force them to
> convert their jpegs to something else.

I won't to force anybody to use an image file format, but just add a new
option to do it.

> We must keep the interface
> accessible for all users.
> If we can create features for professional users
> as well, without confusing the avarage user: great. But a part of our
> strength is in the simplicity of using digiKam.

Absolutly

>
> > We haven't to forget to
> > provide with metadata read/write ability to digiKam. I think it's a
> > feature in great demand.
>
> Yes, but we need to do that smart. I dont think we should simply add every
> meta format there is to digiKam.

In all case, excepted Exif, there is no universal way to use all metadata
type.

To resume, major metadata to drive are :

- Exif for JPEG (already done), TIFF (embeded - TODO), and RAW (via thm file
provide by camera - TODO)
- IPTC for JPEG  (embeded - TODO), TIFF  (embeded - TODO), and RAW (via thm
file provide by camera - TODO)
- XMP for JPEG, TIFF, DNG, PNG, etc (for the far future).


> Pick one and do it right, but I dont think
> we should do it on our own, it should be a extragear/graphics wide or even
> kde wide library.

I'm not sure that to create another shared lib is the better, or perhaps you
have any free time to manage it (:=)))

>
> > As Gilles used to say: my 10 €cnt. :-). I hope it's usefull.
>
> My 0,02, so we are now on 32 cents, right?

hum, i has only 10 ents here. It's enough for you ?

>
> > PD.: excuse my poor English.
>

Your English is better that mine (:=)))

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Digikam-devel] digikam PNG workflow...

Bugzilla from tomalbers@kde.nl
Op zaterdag 28 januari 2006 14:37, schreef Gilles Caulier:

> > Yes, but we need to do that smart. I dont think we should simply add
> > every meta format there is to digiKam.
>
> In all case, excepted Exif, there is no universal way to use all metadata
> type.
>
> To resume, major metadata to drive are :
>
> - Exif for JPEG (already done), TIFF (embeded - TODO), and RAW (via thm
> file provide by camera - TODO)
> - IPTC for JPEG  (embeded - TODO), TIFF  (embeded - TODO), and RAW (via thm
> file provide by camera - TODO)
> - XMP for JPEG, TIFF, DNG, PNG, etc (for the far future).
Ok. Thanks for this list, i was kind of lost ;-)

> I'm not sure that to create another shared lib is the better, or perhaps
> you have any free time to manage it (:=)))

On one hand, you want to wok more with Krita, on the other hand you seem to
hate creating an api which is accessible to others. Sometimes you confuse
me ;-)

> hum, i has only 10 ents here. It's enough for you ?

Wij het kleine niet eert ....

> > > PD.: excuse my poor English.
> Your English is better that mine (:=)))

You are improving ;-)

Toma

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

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Digikam-devel] digikam PNG workflow...

Gilles Caulier
Le Samedi 28 Janvier 2006 14:35, Tom Albers a écrit :

> Op zaterdag 28 januari 2006 14:37, schreef Gilles Caulier:
> > > Yes, but we need to do that smart. I dont think we should simply add
> > > every meta format there is to digiKam.
> >
> > In all case, excepted Exif, there is no universal way to use all metadata
> > type.
> >
> > To resume, major metadata to drive are :
> >
> > - Exif for JPEG (already done), TIFF (embeded - TODO), and RAW (via thm
> > file provide by camera - TODO)
> > - IPTC for JPEG  (embeded - TODO), TIFF  (embeded - TODO), and RAW (via
> > thm file provide by camera - TODO)
> > - XMP for JPEG, TIFF, DNG, PNG, etc (for the far future).
>
> Ok. Thanks for this list, i was kind of lost ;-)
>
> > I'm not sure that to create another shared lib is the better, or perhaps
> > you have any free time to manage it (:=)))
>
> On one hand, you want to wok more with Krita, on the other hand you seem to
> hate creating an api which is accessible to others. Sometimes you confuse
> me ;-)

If i have more free time, I would to do the both. But i need to take a
choise...

Working with Krita isn't a priority. Actually, the only task that we can done
is to add an new DImg::ImageLoader to support krita image file format.

Making a common image plugin framework have no sence for me. There are too
many differences between digiKam and Krita.

>
> > hum, i has only 10 ents here. It's enough for you ?
>
> Wij het kleine niet eert ....
>
> > > > PD.: excuse my poor English.
> >
> > Your English is better that mine (:=)))
>
> You are improving ;-)

It's enough to buy a little beer (:=)) ?
--
Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel