[Digikam-users] Suggestion for a Showfoto

[Lawrence Plug]

Hello:


On Fri, 11 Apr 2008 08:46:07 +0200 (CEST), "Arnd Baecker"
<arnd.baecker at web.de> said:
> On Wed, 9 Apr 2008, Lawrence Plug wrote:
> >
> > Rather than have the tools selected from a dropdown menu, an alternative
> > would be to have the tools within tabs stacked vertically, which then
> > individually drop down to show their respective sliders etc when
> > selected.  --snippage--
> 
> I like this variant.
> 
> Another option here would be to just have a subset
> of tools visible. Something like "tool collections", e.g.
> - one with a default subset
> - another  collection with all tools,
> - and user-definable subsets (which can be saved and loaded)
> 

That would be a nice option, as would the ability to tear off tools into
floating windows as suggested elsewhere in thread.

> >
> > On a related note (perhaps I should open a different thread) it would be
> > FANTASTIC if showfoto would operate nondestructively on RAWs.
> 
> Well, this is the next step and discussed in
> http://bugs.kde.org/show_bug.cgi?id=125387
> Having such a tool collection (whatever you want to call it ;-)
> would be the visual representation of the "action lists".
>
> ((What I would like a lot if such actions could be easily
> exchanged/shared; this might also be related to
> scripts written in KROSS; http://bugs.kde.org/show_bug.cgi?id=146866 ))

Good to hear it is in development.

I suppose a way to exchange/share is to write all PP parameters for an
image into a sidecar file which can be reused, emailed, etc. This is the
rawtherapee method (and some other SW I guess). The parameters for the
final version of the image are written to a text file when you save the
png/jpeg/tiff, plus you can take 'snapshot' files of the PP parameters
as you work on the image in case you want to revert. For parameter sets
you are likely to use over and over, you name these and save into an
archive.

RT also keeps a running list of actions applied to the image. You can
click back into it to revert to a previous state. Screenshot here
(actions on left panel):
http://ljplug.smugmug.com/photos/277935562_WesCp-X2.jpg


> Code-wise all this will be a substantial change.
> As discussed before: Maybe the most tricky bit is how to treat changes of
> parameters in the chain of tools. Eg., if a crop is at the beginning,
> followed by a levels adjustment, noise reduction and some sharpening,
> then changing the crop means that everything in the chain has to be
> re-computed.
> In order that this works sufficiently smoothly for the user,
> maybe it can only be done on the preview. Only when OK
> is selected, all steps are executed on the full image...

I'm sure it would be a substantial change to code. My own coding is in a
very different field, but i can at least imagine the job involved. 

Regarding speed of execution: Those operations which are particularly
slow (sharpening, resizing, noise reduction) might be applied only to a
preview while others immediately to the entire image.

Here is an order-of-operations:
http://www.rawtherapee.com/?mitem=4&faqid=20

With RT, you do need to wait for some operations, but it certainly is no
slower (faster, I'd say) than current showfoto workflow. The result is
very tolerable in terms of speed (I use both digikam and RT primarily on
a Opteron 2.4Ghz with 3GB, but also my 1.6GHz Pentium laptop). It is
speedier than megabuck commercial apps I've demoed, like lightzone (a
java cow, in addition).


> BTW: Shouldn't also the raw conversion itself (including lense
> correction) be put at the top of the pipeline?

Do you mean distortion correction (barrel, pincushioning) and
antivignetting etc? I personally think this should be grouped with
transform tools (like resizing and rotating) -- all of which most users
will/should do first, before colour, sharpening etc

Regarding putting RAW conversion at the top of the pipeline.. In the
rawtherapee model (as in above URL), all the PP operations we are
discussing --colour, exposure, sharpening, transforms-- are part of the
conversion pipeline in that they occur _before_ a raster png/tiff/jpeg
image is generated.  The demosaicing algorithm used is set in a
preferences dialogue. I won't pretend to understand the details of
underlying algorithms, but my experience is very positive. Especially
operations like highlight recovery from raw are very, very good.  Of
course, you can also open non-raw images in RT.

I'm using RT as an example here because it works well for me, not to put
down showfoto (I want that to be clear :-).  Gabor, RT's developer, has
a nice piece of work from my user standpoint, including his demosaicing
algorithms and CIELAB colour use.  Integrating it's strengths with
showfoto/kipi's greater selection of tools (CIMG, filters, etc) would
make for a killer photo processing application in my view. And with
digikam's very strong and always improving
browsing/tagging/database/archiving underneath, it would be even better
:-)


cheers
Lawrence




> Best, Arnd
> 
> > cheers
> > Lawrence
> >
> > ** screenshot of the rawtherapee layout, with white balance and
> > sharpening tools open.
> > http://ljplug.smugmug.com/photos/277201951_u8QY4-X2.jpg
> >
> >
> >
> > On Wed, 09 Apr 2008 13:54:03 -0400, "Scott Chevalley"
> > <avalon at osguru.org> said:
> > >
> > >
> > > Marcel Wiesweg wrote:
> > > >> Hi! I have made mockups (2) of the Showfoto. This PDF is my suggestion for
> > > >> faster (=better) workflow when editing multiple photographs.
> > > >> Hopefully this would open some discussion about the Showfoto's GUI and
> > > >> questions about can it be polished even more? I think that digiKam already
> > > >> has great GUI and professional options for photo management, now it's
> > > >> editor needs polishing ;-)
> > > >>
> > > >
> > > > Taking the main point (as it appears to me):
> > > > Moving from separate dialogs to integrating the settings in the sidebar and
> > > > the preview in the main area.
> > > >
> > > > This is an interesting idea, generally in KDE and other software there is a
> > > > move away from modal dialogs towards non-modal solutions like the one
> > > > suggested here. It is a valid point; the dialog is modal, so the window in
> > > > the background cannot be used anyway. It would be interesting to hear the
> > > > opinion of the people here on this list, as well as the opinion of a
> > > > usability expert.
> > > >
> > > > Technically, such a change requires a larger amount of work. The main window
> > > > need to be adapted, the base classes of the current image plugin dialogs need
> > > > to be refitted into the new framework, and (at least with trivial changes)
> > > > each image plugin need to be ported.
> > > >
> > > > _______________________________________________
> > > > Digikam-users mailing list
> > > > Digikam-users at kde.org
> > > > https://mail.kde.org/mailman/listinfo/digikam-users
> > >
> > > As a mostly-lurker on the list, I just thought I'd throw my 2 cents in
> > > and say that I like the mockup.  I think it follows more closely the
> > > flow that other image/raw editors take, so would be easier for users to
> > > get up to speed.
> > >
> > > I also see how being able to switch between images to apply the current
> > > tool to each is much better than the modal dialog method.
> > >
> > > The only additional suggestion would be to somehow speed up the preview
> > > of the modification, because some of the tools take a long time to do
> > > what they do and try to do it for even the most miniscule change in
> > > parameters.
> > >
> > > Scott
> > > _______________________________________________
> > > Digikam-users mailing list
> > > Digikam-users at kde.org
> > > https://mail.kde.org/mailman/listinfo/digikam-users
> > _______________________________________________
> > Digikam-users mailing list
> > Digikam-users at kde.org
> > https://mail.kde.org/mailman/listinfo/digikam-users
> >
> >
> _______________________________________________
> Digikam-users mailing list
> Digikam-users at kde.org
> https://mail.kde.org/mailman/listinfo/digikam-users