[Bug 103176] 16bit/channel framework for digikam

[Gilles Caulier]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=103176         




------- Additional Comments From caulier.gilles free fr  2005-11-06 20:19 -------
To clarify any points about my current jobs in digiKam, these are fresh new about 16 bits/color/pixel and RAW files support :

1/ RAW file support in 8 bits/color/pixel complete on my computer. showfoto and image editor can load (not save) all RAW file format supported by dcraw program. I have also fixed parsing code to identify RAW files with current dcraw::parce.c implementation. This is fix any problem with DNG file format.
This code is ready to commit. I will done it after 0.8.0 release date planed to november 15.

2/ DImage is currently in development and based on Renchi Raju implementation :
  - RAW files can be loaded in 16 bits/color/pixel using dcraw.
  - TIFF files can be loaded in 8/16 bits/color/pixel.
  - PNG files can be loaded in 8/16 bits/color/pixel
  - JPEG files can be loaded and saved in 8 bits/color/pixel. All metadat are preserved (JPEG/IPTC/COM).
  - ALL others image file format are loaded using QImage interface in 8 bits/color/pixel.
  - TODO  :
       * writing save PNG/TIFF methods
       * writing load/save PNM methods in 8/16 bits/color/pixel.
       * writing save digikam comments in PNG and PNM (like with JPEG files)
       * Metadata support for TIFF file (IPTC).
       * image editor and showfoto intergration (acutally DImage works with a dedicaced small image viewer based on image editor canvas).
       * Fixed all image filters in digikam/libs to support 16 bits/color/pixel.
       * Fixed all image plugins in digikam core and DigikamImagePlugins to support 16 bits/color/pixel.

... And that all for 0.9.0 release (outch...)

If there are any volonters to help me in this large task, please let's me hear...

Regards

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

> ------- Additional Comments From caulier.gilles free fr  2005-11-06 20:19
> ------- To clarify any points about my current jobs in digiKam, these are
> fresh new about 16 bits/color/pixel and RAW files support :
>
> 1/ RAW file support in 8 bits/color/pixel complete on my computer. showfoto
> and image editor can load (not save) all RAW file format supported by dcraw
> program. I have also fixed parsing code to identify RAW files with current
> dcraw::parce.c implementation. This is fix any problem with DNG file
> format. This code is ready to commit. I will done it after 0.8.0 release
> date planed to november 15.

Are there more infos about digikams way to this future? Cause this is a
fundamental change this sounds like a 0.9 trunk. Goes current 0.8.x after
release in maintenance mode (bug fixing only)? Are there plans for a KDE 4
port?

> 2/ DImage is currently in development and based on Renchi Raju
> implementation : - RAW files can be loaded in 16 bits/color/pixel using
> dcraw.

Cause there are now some project developing this RAW file loading code do you
see any room for collaboration? ufraw use its fork, Krita has now dcraw.c in
repository, too and of course there is the original code of Dave Coffin.
There are some alternative libs for for decoding and demosaicing but dcraw is
somehow still in the lead.
I can ask him on the rawfile ML if he has any interests in creating or
supporting a lib-style structure that is better suited for this task? Or is
it better for digiKam here to create its own way?
 
>   - TIFF files can be loaded in 8/16 bits/color/pixel.
>   - PNG files can be loaded in 8/16 bits/color/pixel
>   - JPEG files can be loaded and saved in 8 bits/color/pixel. All metadat
> are preserved (JPEG/IPTC/COM). - ALL others image file format are loaded
> using QImage interface in 8 bits/color/pixel. - TODO  :
>        * writing save PNG/TIFF methods
>        * writing load/save PNM methods in 8/16 bits/color/pixel.
>        * writing save digikam comments in PNG and PNM (like with JPEG
> files) * Metadata support for TIFF file (IPTC).

As I wrote as comment in Toms blog:
The problem is, that we need a good support for writing a 16bit image format
including transfer of metatags. Using RAW as digital negative is IMHO a wrong
approach. Better use a common 16bit format like tiff, png or dng (tiff-like).
For transfering metatags from raw to the processed image type my 'rawimage'
kfile plugin shows a pragmatic solution until exiv2 is ready do fancy stuff
like this.
 
>        * image editor and showfoto intergration (acutally DImage works with
> a dedicaced small image viewer based on image editor canvas).

Here I see also a conversion part as you can not show 16bit pics on a monitor
(or printer(?)) Maybe it would be wise to make there a strong separation so
that it would be possible to support color management in a remote future.

> * Fixed all
> image filters in digikam/libs to support 16 bits/color/pixel. * Fixed all
> image plugins in digikam core and DigikamImagePlugins to support 16
> bits/color/pixel.

Yes, that is the hard-working part

> ... And that all for 0.9.0 release (outch...)

Ah, I see this answers a part of my question on top of this mail :-)

>
> If there are any volonters to help me in this large task, please let's me
> hear...

I really would like to step in. But you are one of this fast programmers that
I feel inadequate in being a help. But you know that I have strong interests
as power user in digikam image processing part. Do you see a chance to step
in for a person like me with so limited time, less KDE background and no
knowledge about digiKams code? :-)

Bye

  Thorsten

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

[Gilles Caulier]

Le Dimanche 6 Novembre 2005 22:52, Thorsten Schnebeck a écrit :

> > ------- Additional Comments From caulier.gilles free fr  2005-11-06 20:19
> > ------- To clarify any points about my current jobs in digiKam, these are
> > fresh new about 16 bits/color/pixel and RAW files support :
> >
> > 1/ RAW file support in 8 bits/color/pixel complete on my computer.
> > showfoto and image editor can load (not save) all RAW file format
> > supported by dcraw program. I have also fixed parsing code to identify
> > RAW files with current dcraw::parce.c implementation. This is fix any
> > problem with DNG file format. This code is ready to commit. I will done
> > it after 0.8.0 release date planed to november 15.
>
> Are there more infos about digikams way to this future?

Reading current TODO  file in svn.

> Cause this is a
> fundamental change this sounds like a 0.9 trunk.

DIMage come from 0.9.x serie and will support RAW files in 16
bits/color/pixel.
0.8.x (excepted 0.8.0) will includes RAW file support in 8 bits/color/pixel
only because these serie are based on imlib2.

> Goes current 0.8.x after
> release in maintenance mode (bug fixing only)?

not only bug fixing. I will add image properties sidebar. This code is ready
to commit and come from 0.8.1

> Are there plans for a KDE 4
> port?

yes. I need another developper to do this point. It's can be a long task and
requires any tests. KDE 4.0 isn't planed for a near future and when can plan
this task for 0.9.0.

>
> > 2/ DImage is currently in development and based on Renchi Raju
> > implementation : - RAW files can be loaded in 16 bits/color/pixel using
> > dcraw.
>
> Cause there are now some project developing this RAW file loading code do
> you see any room for collaboration?

dcraw do not exist in libs, only like a command line tool. Take a look in
dcraw project page. There is no collaboration with other projects. I used a
_LARGE_ free time to manage digikam & co, and i have _NO_ free time to speak
with other projects about a shared lib. Sorry for this bad sound, but this is
the libkipi experience...

> ufraw use its fork,

==> are you seen in ufraw code. The guy who have coded thing gimp plugin is
really wrong !!! The code cannot be used by me.

> Krita has now  
> dcraw.c in repository, too and of course there is the original code of Dave
> Coffin.

==> Good sound. I will take a look.

> There are some alternative libs for for decoding and demosaicing
> but dcraw is somehow still in the lead.

yes.

> I can ask him on the rawfile ML if he has any interests in creating or
> supporting a lib-style structure that is better suited for this task?

sure, but any improvement can be done without create a shared lib especially
to apply gamma and white point settings available in 8/bits/color/pixel to 16
bits/color/pixel.

> Or is
> it better for digiKam here to create its own way?
>
> >   - TIFF files can be loaded in 8/16 bits/color/pixel.
> >   - PNG files can be loaded in 8/16 bits/color/pixel
> >   - JPEG files can be loaded and saved in 8 bits/color/pixel. All metadat
> > are preserved (JPEG/IPTC/COM). - ALL others image file format are loaded
> > using QImage interface in 8 bits/color/pixel. - TODO  :
> >        * writing save PNG/TIFF methods
> >        * writing load/save PNM methods in 8/16 bits/color/pixel.
> >        * writing save digikam comments in PNG and PNM (like with JPEG
> > files) * Metadata support for TIFF file (IPTC).
>
> As I wrote as comment in Toms blog:
> The problem is, that we need a good support for writing a 16bit image
> format including transfer of metatags. Using RAW as digital negative is
> IMHO a wrong approach. Better use a common 16bit format like tiff, png or
> dng (tiff-like). For transfering metatags from raw to the processed image
> type my 'rawimage' kfile plugin shows a pragmatic solution until exiv2 is
> ready do fancy stuff like this.

DImage RAW file support is only read only ! to save 16 bits/color/pixel image,
you must always use TIFF or PNG file format (there is a lib to write DNG
files ?)

I know exiv2, and i currently learn this framework. The only bad point is that
cannot support i18n currently (like libexif)...

>
> >        * image editor and showfoto intergration (acutally DImage works
> > with a dedicaced small image viewer based on image editor canvas).
>
> Here I see also a conversion part as you can not show 16bit pics on a
> monitor (or printer(?)) Maybe it would be wise to make there a strong
> separation so that it would be possible to support color management in a
> remote future.

yes using a dedicaced color management lib. I will take a look too...

>
> > * Fixed all
> > image filters in digikam/libs to support 16 bits/color/pixel. * Fixed all
> > image plugins in digikam core and DigikamImagePlugins to support 16
> > bits/color/pixel.
>
> Yes, that is the hard-working part
>
> > ... And that all for 0.9.0 release (outch...)
>
> Ah, I see this answers a part of my question on top of this mail :-)
>
> > If there are any volonters to help me in this large task, please let's me
> > hear...
>
> I really would like to step in. But you are one of this fast programmers
> that I feel inadequate in being a help. But you know that I have strong
> interests as power user in digikam image processing part. Do you see a
> chance to step in for a person like me with so limited time, less KDE
> background and no knowledge about digiKams code? :-)

sure, there are any small tasks to do. Take a look in TODO file from svn.

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