[Digikam-devel] [Bug 103176] 16bit/channel framework for digikam

Gilles Caulier caulier.gilles at free.fr
Mon Nov 7 11:40:21 GMT 2005


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



More information about the Digikam-devel mailing list