[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Joining koffice development team
From:       Philippe Rigault <prigault () oricom ! ca>
Date:       2006-02-05 20:34:03
Message-ID: 200602051534.03160.prigault () oricom ! ca
[Download RAW message or body]

Hi Bart,

> >  - RAW filters
> > 	- Generic framework for various CCD geometries
> > 	- Improved algorithms for demosaicing (interpolation of CCD data -> RBG)
> > 	- Full support for popular raw formats (e.g Nikon's NEF and Canon's
> > CRW), including EXIF data edition and 'Save as RAW'
>
> Basically we are planning on using the external dcraw application for this,
> so I fear that most of the changes you'd want to make will need to be done
> there. From what I know, it's a monolithic block of code that might not be
> the best and most nice place to start with, though.
This approach is exactly what I would like to avoid in the long run, because 
the RAW->RBG conversion _must_ be totally controlled by the user (with 
graphical feedback) instead of left uncontrolled to dcraw. Most basic 
corrections should be applied to the CCD raw data prior to interpolation 
(demosaicing) and not to the final RGB, otherwise significant image 
degradation can occur, even in 16-bit. So the graphical interface should give 
control of transform functions to the user and show dynamically what the 
result of the combined transformations looks like. Only then can it 
export/save as RGB.

Of course, the user could script this, but he should be in control of the 
components. A typical usage is when you have shot a large number of images in 
the same setting, you typically:
 - Use a graphical tool to fine tune the settings
 - Run these settings for the sequence of images
Some images in the sequence might call for a special treatment (say 2-stops 
more light because the image is too dark), so one can access the settings for 
this image, change only that one (Levels/Curves), and reprocess this image.  

In that regard, the Nikon approach (Capture software and NEF format) is 
relatively correct: the NEF image is composed _only_ of:
 - Raw CCD data (untouched after acquisition by the camera)
 - Data for RAW->RBG, including camera settings (EXIF)
The Capture software sucks however (unstable, very slow, memory hog, and of 
course no scripting since this is foreign in the MS world). Krita could leap 
in front of all software I know of if this step is done correctly.

The RAW->RBG is the most critical part for making the difference between an 
amateur and a professional product, because the huge number of images taken 
by digital cameras could take an inordinate amount of time just to pass the 
selection process.

The current processing software is in such a sorry state that most pro 
photographers shooting high volume (sports, photojournalists, fashion) have 
to resort to using the in-camera algorithms and save to JPEG instead of using 
RAW formats, which is the luxury that currently only studio/nature 
photographers use. I want to help make a piece of software that corrects this 
state, giving both a much better control (Krita as a graphical interface) and 
much better throughput (scripting can be distributed onto a processing 
cluster) to digital photographers.

My plan is to essentially tear apart the different dcraw components in 
modules, add interfaces that control image transformations that happen 
_before_ interpolation, such as:
 - Chromatic aberration corrections (these are lens-specific, so one can 
imagine reading the lens type in EXIF and selecting a correction by default 
that has been calibrated with that lens). No other software that I know of 
deals with this correctly.
 - Color balance / camera white balance
 - Contrast curves
 - Sharpening
 - Color space conversions
 - Judging sharpness, in order to quickly select images from a sequence
 - Demosaicing algorithm choice.

Dcraw could be very helpful though, because reverse-engineering manufacturer's 
settings/encodings can be a royal PITA.

If you want to read more about demosaicing and advanced imaging algorithms, I 
suggest:

1. R. Kimmel.  Demosaicing: Image reconstruction from color CCD samples.   
IEEE Trans. on Image Processing,  8(9):1221-8, Sept. 1999  (PDF)  and  some 
color results
available (publication #22) at http://www.cs.technion.ac.il/~ron/pub.html

>
> >  - Added functions/interfaces for photo edition
>
> At the moment we're in a feature/string freeze, but after that you're more
> than welcome to add this kind of stuff (or develop it separately in
> playground, like Cyrille does).

Sure, I am talking about long term development here.

Philippe
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]