Suggestion for a Showfoto

On Thu, 10 Apr 2008 19:02:35 +0000, ""Sveinn í Felli (IMAP)""
<[hidden email]> said:

> Possibly these tabs could behave as windows if undocked
> (w/drag'n'drop), then people would be able to decide whether
> to spread their tools all over their multi-screen xinerama,
> or to compact everything down on a smaller screen.

I agree - the option of choosing between separate windows or stacked
tabs would be a nice solution. I sometimes also work on 1200x3200
dual-head, and detachable would be best here.

I don't know the limits, if any, of the KDE interface .. To the
developers - any chance of such an interface option in the future?

Lawrence

(by the way, thanks from this newbie to the original poster for the
mockup and encouragement for discussion)

>
> Just my centimes;
>
> regards
>
> Sveinn í Felli
>
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users

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

[Arnd Baecker]

On Wed, 9 Apr 2008, Lawrence Plug wrote:

> I'm another mostly-lurker on this list, and a new one,  but am a daily
> user of digikam. I like the mockup a great deal. It would improve
> showfoto's usability and appearance quite a bit. I'll offer up one
> suggestion for a modification to the mockup, which I would prefer
> slightly.
>
> 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.  This is the way that rawtherapee, for example, organizes
> tools. I find it very convenient (I use rawtherapee for ORFs). The tools
> are stacked in the order that they would generally be used (WB and
> exposure at the top, noise reduction near the bottom), and more than one
> tool can be opened at a time.

I like this variant.

> The advantage of this is that all the related tools are visible (visual
> cue to user), and because several can be open at one time, it is
> possible to see their settings even when not adjusting that particular
> tool. I find this useful. The commonly used tools i just leave open,
> others are nearly always closed.

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)

> The tools would be grouped into broader categories of transform tools,
> filters etc.. exactly as shown in the mockup.
>
> Ideally, I'd like to be able to open and close a tool with a keystroke.
> eg. ctrl-s drops down (or up) sharpening.
>
> On a related note (perhaps I should open a different thread) it would be
> FANTASTIC if showfoto would operate nondestructively on RAWs, like
> rawtherapee does, rather than the converted images. Perhaps this is
> already in the pipeline.

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 ))

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...

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

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"
> <[hidden email]> 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
> > > [hidden email]
> > > 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
> > [hidden email]
> > https://mail.kde.org/mailman/listinfo/digikam-users
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users
>
>

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

Hello:


On Fri, 11 Apr 2008 08:46:07 +0200 (CEST), "Arnd Baecker"
<[hidden email]> 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"
> > <[hidden email]> 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
> > > > [hidden email]
> > > > 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
> > > [hidden email]
> > > https://mail.kde.org/mailman/listinfo/digikam-users
> > _______________________________________________
> > Digikam-users mailing list
> > [hidden email]
> > https://mail.kde.org/mailman/listinfo/digikam-users
> >
> >
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users

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

[Gilles Caulier-4]

2008/4/11, Lawrence Plug <[hidden email]>:

> Hello:
>
>
>
>  On Fri, 11 Apr 2008 08:46:07 +0200 (CEST), "Arnd Baecker"
>  <[hidden email]> 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

With digiKam for KDE4, there is a new tool which group all these
correction in the same plugin :

http://digikam3rdparty.free.fr/Screenshots/LensFunPlugin/

It use LensFun library to fix Lens distorsions.

http://lensfun.berlios.de/

This tool can fix automatically an image using Exif info... LensFun
has a database of camera+lens to perform corrections.

Best

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

[Lawrence Plug]

On Fri, Apr 11, 2008 at 04:50:16PM +0200, Gilles Caulier wrote:

> 2008/4/11, Lawrence Plug <[hidden email]>:
> >
> >  > 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
>
> With digiKam for KDE4, there is a new tool which group all these
> correction in the same plugin :
>
> http://digikam3rdparty.free.fr/Screenshots/LensFunPlugin/
>
> It use LensFun library to fix Lens distorsions.

That's excellent.

Is there a URL that summarizes KDE4 features/additions?  Or a
howto for compiling and testing the KDE4 version? kde in general,
and especially 4, is new to me, but point me in the right
direction and I can probably figure it out.
 

thanks
Lawrence

> http://lensfun.berlios.de/
>
> This tool can fix automatically an image using Exif info... LensFun
> has a database of camera+lens to perform corrections.
>
> Best
>
> Gilles Caulier
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users

--
...
Q: How many Zen masters does it take to screw in a light bulb?
A: None.  The Universe spins the bulb, and the Zen master stays out
        of the way.
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Gilles Caulier-4]

2008/4/11, Lawrence Plug <[hidden email]>:

> On Fri, Apr 11, 2008 at 04:50:16PM +0200, Gilles Caulier wrote:
>  > 2008/4/11, Lawrence Plug <[hidden email]>:
>  > >
>
> > >  > 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
>  >
>  > With digiKam for KDE4, there is a new tool which group all these
>  > correction in the same plugin :
>  >
>  > http://digikam3rdparty.free.fr/Screenshots/LensFunPlugin/
>  >
>  > It use LensFun library to fix Lens distorsions.
>
>
> That's excellent.
>
>  Is there a URL that summarizes KDE4 features/additions?

Not yet in www.digikam.org. still todo, but i'm currently very buzy at
home to restore my kitchen and my bathroom...

You can seen a little review on dot.kde.org done by me and Mik :

http://dot.kde.org/1207150254/

Not all is listed here of course. I plan to do another review on
dot.kde.org later, when 0.10.0-beta1 will be published.

Here there are few digiKam 0.10.0 screenshots :

http://polishlinux.org/kde/kde-4-tour-digikam-010/
http://polishlinux.org/kde/kde-4-rev-790000-better-stability-and-performance/

>Or a
>  howto for compiling and testing the KDE4 version? kde in general,
>  and especially 4, is new to me, but point me in the right
>  direction and I can probably figure it out.

well, i never compile KDE4 (:=))) I have no more free time to do it...
Under Mandriva 2008.0, all devellopement packages are available. I
install it. that all.

To compile digiKam for KDE4, follow this page :

http://www.digikam.org/?q=download/svn

... at the bottom. Unforget to read the README file for more details
about all depencies. Let's me hear if more comments are need...

Best

Gilles Caulier

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

[Lawrence Plug]

On Fri, Apr 11, 2008 at 06:26:42PM +0200, Gilles Caulier wrote:
> >
> >  Is there a URL that summarizes KDE4 features/additions?
>
> Not yet in www.digikam.org. still todo, but i'm currently very buzy at
> home to restore my kitchen and my bathroom...

ah.. The dreaded renovations. Good luck :-)

The screenshots and descriptions for 0.10.0 look promising.  I'll
give Mandriva a try. One more linux distribution won't
hurt  ;-)

thanks for links

Lawrence

>
> You can seen a little review on dot.kde.org done by me and Mik :
>
> http://dot.kde.org/1207150254/
>
> Not all is listed here of course. I plan to do another review on
> dot.kde.org later, when 0.10.0-beta1 will be published.
>
> Here there are few digiKam 0.10.0 screenshots :
>
> http://polishlinux.org/kde/kde-4-tour-digikam-010/
> http://polishlinux.org/kde/kde-4-rev-790000-better-stability-and-performance/
>
> >Or a
> >  howto for compiling and testing the KDE4 version? kde in general,
> >  and especially 4, is new to me, but point me in the right
> >  direction and I can probably figure it out.
>
> well, i never compile KDE4 (:=))) I have no more free time to do it...
> Under Mandriva 2008.0, all devellopement packages are available. I
> install it. that all.
>
> To compile digiKam for KDE4, follow this page :
>
> http://www.digikam.org/?q=download/svn
>
> ... at the bottom. Unforget to read the README file for more details
> about all depencies. Let's me hear if more comments are need...
>
> Best
>
> Gilles Caulier
>
> >
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users

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