Using image editor canvas with Preview mode...

[Gilles Caulier-4]

Hi all,

Here :

http://digikam3rdparty.free.fr/misc.tarballs/previewwithcanvas.patch

... you can find an experimental patch to use image editor canvas with Preview Mode. This one in action can be seen here :

http://digikam3rdparty.free.fr/Screenshots/canvaswithpreview.png

The patch is not perfect. The core editor use an unique instance to run, and digiKam can crash or give strange effects if you use Preview mode and Image Editor at the same time.

Use this patch like a moc-up. It's a possible way to give a better Preview mode in the future, especially with zoming function. Like I have very improved canvas implementation this week, the zoom function speed-up and can be used as well with preview image.

Nota : preview image is not the whole image. Preview is limited to 1024x768.

Comments from users are welcome...

//----------------------------------------------------------------------

Marcel:

How i can fix easily the single image editor core instance problem ? Like we have only one instance in memory, the image data are unique and we have a conflict between preview image data and whole image data when Preview Mode and Image Editor are used at the same time.

I would to not re-implemente all core editor for preview mode. Code must be shared to reduce dupplicate implementation. There is certainly a simple way to find (:=)))

Any suggestions ? Thanks in advance...

Gilles

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

Dnia piątek 06 kwiecień 2007, Gilles Caulier napisał:
>
> Comments from users are welcome...

Well. It works. Sort of ;)

Apart from many small bugs two IMO important things:

- Fit to Window should be default (unchangeable?) for View mode
- Mouse should be used to move viewport, not to close preview

Thanks.

m.

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

[Marcel Wiesweg]

Am Freitag 06 April 2007 17:19 schrieb Mikolaj Machowski:
> Dnia piątek 06 kwiecień 2007, Gilles Caulier napisał:
> > Comments from users are welcome...
>
> Well. It works. Sort of ;)
>
> Apart from many small bugs two IMO important things:
>
> - Fit to Window should be default (unchangeable?) for View mode


> - Mouse should be used to move viewport, not to close preview

This has been implemented at user request: Click to open, click to close. Very
fast, no need to move mouse.
I dont know if it will confuse users if mouse dragging, in contrast to single
click, when the image is zoomed, will move the viewport instead of closing.

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

[Marcel Wiesweg]

> Marcel:
>
> How i can fix easily the single image editor core instance problem ? Like
> we have only one instance in memory, the image data are unique and we have
> a conflict between preview image data and whole image data when Preview
> Mode and Image Editor are used at the same time.
>
> I would to not re-implemente all core editor for preview mode. Code must be
> shared to reduce dupplicate implementation. There is certainly a simple way
> to find (:=)))
>
> Any suggestions ? Thanks in advance...

Currently DImgInterface is a singleton. The singleton is accessed from places
which could easily keep their own object, e.g. as a member of canvas:
editorwindow.cpp
imagewindow.cpp
canvas.cpp
showfoto.cpp

But it is also accessed from all image plugins, these classes:
ImageIFace (!!!)
ImageDlgBase
ImageGuideDlg
CtrlPanelDlg

Here it is necessary to have some "default" DImgInterface.

So to solve this, one could try to:
- make the DImgInterface constructor public
- add a DImgInterface object as a member variable of Canvas
- add a "DImgInterface::defaultInstance()" method (or keep the instance()
method, no need to rename) for latter classes
- add a DImgInterfacesetDefaultInstance() method to set the default instance -
called from EditorWindow. Both EditorWindows (ImageWindow, ShowFoto are
singletons themselves)

Marcel

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

[Gilles Caulier-4]

2007/4/6, Marcel Wiesweg <[hidden email]>:

> Marcel:

>
> How i can fix easily the single image editor core instance problem ? Like
> we have only one instance in memory, the image data are unique and we have
> a conflict between preview image data and whole image data when Preview
> Mode and Image Editor are used at the same time.
>
> I would to not re-implemente all core editor for preview mode. Code must be
> shared to reduce dupplicate implementation. There is certainly a simple way
> to find (:=)))
>
> Any suggestions ? Thanks in advance...

Currently DImgInterface is a singleton. The singleton is accessed from places
which could easily keep their own object, e.g. as a member of canvas:
editorwindow.cpp
imagewindow.cpp
canvas.cpp
showfoto.cpp

But it is also accessed from all image plugins, these classes:
ImageIFace (!!!)
ImageDlgBase
ImageGuideDlg
CtrlPanelDlg

Here it is necessary to have some "default" DImgInterface.

So to solve this, one could try to:
- make the DImgInterface constructor public
- add a DImgInterface object as a member variable of Canvas
- add a "DImgInterface::defaultInstance()" method (or keep the instance()
method, no need to rename) for latter classes
- add a DImgInterfacesetDefaultInstance() method to set the default instance -
called from EditorWindow. Both EditorWindows (ImageWindow, ShowFoto are
singletons themselves)

Fine for me. i need this to implement the LightTable because i will use more than one instance of Canvas/DImgInterface at the same time, embeded in a same KMainWindow. I will souns like an image editor view separated by QSplitter. This vision of a future Light Table is fine for you ?

If yes, are you free time this WE to patch source code of Canvas/DimageInterface in this way ?

Gilles

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

Dnia piątek 06 kwiecień 2007, Marcel Wiesweg napisał:
> >
> > - Mouse should be used to move viewport, not to close preview
>
> This has been implemented at user request: Click to open, click to
> close. Very fast, no need to move mouse.
> I dont know if it will confuse users if mouse dragging, in contrast to
> single click, when the image is zoomed, will move the viewport instead
> of closing.

I suppose you are right *sigh*. Consistency uber alles - that is usually
my war cry ;)

m.

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

[Marcel Wiesweg]

> Fine for me. i need this to implement the LightTable because i will use
> more than one instance of Canvas/DImgInterface at the same time, embeded in
> a same KMainWindow. I will souns like an image editor view separated by
> QSplitter. This vision of a future Light Table is fine for you ?
>
> If yes, are you free time this WE to patch source code of
> Canvas/DimageInterface in this way ?

Patch as described above is in SVN.

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

[Gilles Caulier-4]

2007/4/7, Marcel Wiesweg <[hidden email]>:

> Fine for me. i need this to implement the LightTable because i will use
> more than one instance of Canvas/DImgInterface at the same time, embeded in
> a same KMainWindow. I will souns like an image editor view separated by
> QSplitter. This vision of a future Light Table is fine for you ?
>
> If yes, are you free time this WE to patch source code of
> Canvas/DimageInterface in this way ?

Patch as described above is in SVN.

Thanks Marcel. I will probably start the new Light Table tool next week.

Are you take a look into the new Preview tool witch support Scrolling/Zooming ?

Gilles

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

[Marcel Wiesweg]

Am Samstag 07 April 2007 21:18 schrieb Gilles Caulier:

> 2007/4/7, Marcel Wiesweg <[hidden email]>:
> > > Fine for me. i need this to implement the LightTable because i will use
> > > more than one instance of Canvas/DImgInterface at the same time,
> > > embeded
> >
> > in
> >
> > > a same KMainWindow. I will souns like an image editor view separated by
> > > QSplitter. This vision of a future Light Table is fine for you ?
> > >
> > > If yes, are you free time this WE to patch source code of
> > > Canvas/DimageInterface in this way ?
> >
> > Patch as described above is in SVN.
>
> Thanks Marcel. I will probably start the new Light Table tool next week.
>
> Are you take a look into the new Preview tool witch support
> Scrolling/Zooming ?

Yes I just did. Great work!

I had one problem: See
http://digikam3rdparty.free.fr/Screenshots/zoominginpreview-artefact.png
This is created reproducibly at one zoom level. The following zoom levels were
all right again. To reproduce, zoom in 8 steps and then zoom out 5 steps.

Some minor problems (I could change most of them myself, but I don't know if I
may and should ;-) ):
- the background is black. Before it was white (or following the color theme?)

- mouse wheel zoom direction: Take a look at KPDF, konqueror. They zoom in on
Wheel_up. See here as well: http://bugs.kde.org/show_bug.cgi?id=61862

- in the preview loading, there is still one QImage::smoothScale when images
are scaled down to preview size. Should this be replaced by FastScale? If yes
would you mind to move fastscale somewhere in libs/ ?

- is zooming out , making the image smaller than the available space, really
needed?

- discoverability: will users know that they can zoom?

Marcel

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

[Gilles Caulier-4]

2007/4/8, Marcel Wiesweg <[hidden email]>:

Am Samstag 07 April 2007 21:18 schrieb Gilles Caulier:

> 2007/4/7, Marcel Wiesweg <[hidden email]>:
> > > Fine for me. i need this to implement the LightTable because i will use
> > > more than one instance of Canvas/DImgInterface at the same time,
> > > embeded
> >
> > in
> >
> > > a same KMainWindow. I will souns like an image editor view separated by
> > > QSplitter. This vision of a future Light Table is fine for you ?
> > >
> > > If yes, are you free time this WE to patch source code of
> > > Canvas/DimageInterface in this way ?
> >
> > Patch as described above is in SVN.
>
> Thanks Marcel. I will probably start the new Light Table tool next week.
>
> Are you take a look into the new Preview tool witch support
> Scrolling/Zooming ?

Yes I just did. Great work!

I had one problem: See
http://digikam3rdparty.free.fr/Screenshots/zoominginpreview-artefact.png
This is created reproducibly at one zoom level. The following zoom levels were
all right again. To reproduce, zoom in 8 steps and then zoom out 5 steps.

Damned, i cannot reproduce here, with the same image...
 

Some minor problems (I could change most of them myself, but I don't know if I
may and should ;-) ):
- the background is black. Before it was white (or following the color theme?)

Normally, it follow the theme color scheme. Are you using a fresh svn checkout ?

- mouse wheel zoom direction: Take a look at KPDF, konqueror. They zoom in on
Wheel_up. See here as well: http://bugs.kde.org/show_bug.cgi?id=61862

I will take a look. 

- in the preview loading, there is still one QImage::smoothScale when images
are scaled down to preview size. Should this be replaced by FastScale?

Yes, it can. 

If yes
would you mind to move fastscale somewhere in libs/ ?

sure, but where ? FastScale only support QImage.

- is zooming out , making the image smaller than the available space, really
needed?

right question. Its just a polishing. We will wait and seen user feedback
 

- discoverability: will users know that they can zoom?

Today, CTRL+ and CTRL- control zoom in /out. buttons on tool bar (used before to only increase/decreased thumbs size) can be used for that.

I will add a control to the status slider too. It wil be enough. I'm sure than user will discover fast this feature...

Gilles

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

Dnia niedziela 08 kwiecień 2007, Gilles Caulier napisał:
> - is zooming out , making the image smaller than the available space,
> really
>
> > needed?
>
> right question. Its just a polishing. We will wait and seen user
> feedback

Well, here it is: IMO it isn't necessary. Also some zoom factor
indicator would be useful.

m.

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

[Gilles Caulier-4]

2007/4/8, Mikolaj Machowski <[hidden email]>:

Dnia niedziela 08 kwiecień 2007, Gilles Caulier napisał:
> - is zooming out , making the image smaller than the available space,
> really
>
> > needed?
>
> right question. Its just a polishing. We will wait and seen user
> feedback

Well, here it is: IMO it isn't necessary.

ok 

Also some zoom factor
indicator would be useful.

done on my computer, using slider tool tip on status bar, witch is used to change zoom factor in preview mode...

Gilles

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

[Gilles Caulier-4]

Also some zoom factor
indicator would be useful.

done on my computer, using slider tool tip on status bar, witch is used to change zoom factor in preview mode...

and commited to svn... Look like zooming is fast using slider.

Gilles

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

Dnia poniedziałek 09 kwiecień 2007, Gilles Caulier napisał:
> > Also some zoom factor
> >
> > > indicator would be useful.
> >
> > done on my computer, using slider tool tip on status bar, witch is
> > used to change zoom factor in preview mode...
>
> and commited to svn... Look like zooming is fast using slider.
>
Thank you very much. Whining is in another post ;)

m.

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

[Marcel Wiesweg]

> > - the background is black. Before it was white (or following the color
> > theme?)
>
> Normally, it follow the theme color scheme. Are you using a fresh svn
> checkout ?
>

I have fixed the problem in SVN. The problem occurred only if the chosen theme
is "Default".

> - in the preview loading, there is still one QImage::smoothScale when
> images
>
> > are scaled down to preview size. Should this be replaced by FastScale?
>
> Yes, it can.
>
> If yes
>
> > would you mind to move fastscale somewhere in libs/ ?
>
> sure, but where ? FastScale only support QImage.

The best place for an image scaling algorithm is libs/dimg/, though it would
be a bit paradox that DImg is not supported by something  in dimg/ ;-)
Any better suggestion?

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

[Gilles Caulier-4]

2007/4/7, Marcel Wiesweg <[hidden email]>:

> Fine for me. i need this to implement the LightTable because i will use
> more than one instance of Canvas/DImgInterface at the same time, embeded in
> a same KMainWindow. I will souns like an image editor view separated by
> QSplitter. This vision of a future Light Table is fine for you ?
>
> If yes, are you free time this WE to patch source code of
> Canvas/DimageInterface in this way ?

Patch as described above is in SVN.

Marcel,

Since this patch, The corner widget on bottom/right of canvas, witch provide the pan tool, crash with showfoto. Just start showfoto, load and image, and press on the corner button...

Program received signal SIGSEGV, Segmentation fault.
0x081194aa in Digikam::DImgInterface::origWidth (this=0x0) at dimginterface.cpp:705
/home/gilles/Documents/Devel/SVN/trunk/extragear/graphics/digikam/utilities/imageeditor/canvas/dimginterface.cpp:705:23590:beg:0x81194aa
(gdb) info thread
Current language:  auto; currently c++
  2 Thread -1239880800 (LWP 15679)  0xbfffe410 in __kernel_vsyscall ()
* 1 Thread -1236486448 (LWP 15675)  0x081194aa in Digikam::DImgInterface::origWidth (this=0x0) at dimginterface.cpp:705
(gdb) backtrace
#0  0x081194aa in Digikam::DImgInterface::origWidth (this=0x0) at dimginterface.cpp:705
#1  0x0813e3bb in ImageIface (this=0x82f2a00, w=180, h=120) at imageiface.cpp:83
#2  0x0813b9bb in ImagePanIconWidget (this=0x84a8d70, w=180, h=120, parent=0x84aced0, f=65536) at imagepaniconwidget.cpp:93
#3  0x08123927 in Digikam::Canvas::slotCornerButtonPressed (this=0x8298da8) at canvas.cpp:1244
#4  0x0812a7c2 in Digikam::Canvas::qt_invoke (this=0x8298da8, _id=82, _o=0xbfcd0848) at canvas.moc :388
#5  0xb6ec2d1d in QObject::activate_signal () from /usr/lib/qt3/lib/libqt-mt.so.3
#6  0xb6ec392d in QObject::activate_signal () from /usr/lib/qt3/lib/libqt-mt.so.3
#7  0xb71dcd29 in QButton::pressed () from /usr/lib/qt3/lib/libqt- mt.so.3
#8  0xb6f5538f in QButton::mousePressEvent () from /usr/lib/qt3/lib/libqt-mt.so.3
#9  0xb6ff4834 in QToolButton::mousePressEvent () from /usr/lib/qt3/lib/libqt-mt.so.3
#10 0xb6efaf3e in QWidget::event () from /usr/lib/qt3/lib/libqt- mt.so.3
#11 0xb6e65db7 in QApplication::internalNotify () from /usr/lib/qt3/lib/libqt-mt.so.3
#12 0xb6e66d79 in QApplication::notify () from /usr/lib/qt3/lib/libqt-mt.so.3
#13 0xb758711a in KApplication::notify () from /usr/lib/libkdecore.so.4
#14 0xb6e08719 in QETWidget::translateMouseEvent () from /usr/lib/qt3/lib/libqt-mt.so.3
#15 0xb6e07696 in QApplication::x11ProcessEvent () from /usr/lib/qt3/lib/libqt-mt.so.3
#16 0xb6e176aa in QEventLoop::processEvents () from /usr/lib/qt3/lib/libqt- mt.so.3
#17 0xb6e7b7e0 in QEventLoop::enterLoop () from /usr/lib/qt3/lib/libqt-mt.so.3
#18 0xb6e7b696 in QEventLoop::exec () from /usr/lib/qt3/lib/libqt-mt.so.3
#19 0xb6e6576f in QApplication::exec () from /usr/lib/qt3/lib/libqt- mt.so.3
#20 0x08076066 in main (argc=135738252, argv=0x22) at main.cpp:133
(gdb) info args
this = (class Digikam::DImgInterface * const) 0x0
(gdb) info local
No locals.
(gdb) whatis this
type = class Digikam::DImgInterface * const


Gilles

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

[Gilles Caulier-4]

2007/4/9, Marcel Wiesweg <[hidden email]>:

> > - the background is black. Before it was white (or following the color
> > theme?)
>
> Normally, it follow the theme color scheme. Are you using a fresh svn
> checkout ?
>

I have fixed the problem in SVN. The problem occurred only if the chosen theme
is "Default".

> - in the preview loading, there is still one QImage::smoothScale when
> images
>
> > are scaled down to preview size. Should this be replaced by FastScale?
>
> Yes, it can.
>
> If yes
>
> > would you mind to move fastscale somewhere in libs/ ?
>
> sure, but where ? FastScale only support QImage.

The best place for an image scaling algorithm is libs/dimg/, though it would
be a bit paradox that DImg is not supported by something  in dimg/ ;-)
Any better suggestion?

Well, no. i'm waiting than Antonio (who have writtent this algorithm) patch the code to fix the tile side effect using high zoom factor.

Gilles

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

[Marcel Wiesweg]

> Marcel,
>
> Since this patch, The corner widget on bottom/right of canvas, witch
> provide the pan tool, crash with showfoto. Just start showfoto, load and
> image, and press on the corner button...

Ok you have the horizontal toolbar...which is a second place where a Canvas
object is created, and which I missed. Fixed in SVN.

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