Discussion:
[Lxde-list] New features of Lximage qt image viewer
PCMan
2014-03-16 14:42:11 UTC
Permalink
Please see the blog post for the latest screenshot.
http://blog.lxde.org/?p=1086

Here is a brief list of recent changes:
* Printing support added
* Thumbnail preview (the bottom pane on the screenshot)
* Built-in tool to take a screenshot
* Slide show support
* Improved fullscreen support
* Improved preference dialog
* File properties dialog added

The image viewer is fully functional and usable now.
So, I think it's time to update the translations for it.

BTW, there is an unresolved problem.
When scaling down larger images to fit the smaller window, the image
quality is quite poor.
There's no simple solution to this issue. It's the limitation of QGraphicsView.
When enlarging the image, Qt uses smooth transformation so it works fine.
However this is not the case when shrink larger images.
The only way to avoid this is implementing my own view widget and do
image scaling by manipulating QImage objects directly, which is
non-trivial.
Maybe I should leave this for the next release.

Cheers!
gary sheppard
2014-03-16 18:03:28 UTC
Permalink
Does the upstream for QGraphicsView accept patches...?

I have been quietly following this project with real interest.

Gary
Post by PCMan
Please see the blog post for the latest screenshot.
http://blog.lxde.org/?p=1086
* Printing support added
* Thumbnail preview (the bottom pane on the screenshot)
* Built-in tool to take a screenshot
* Slide show support
* Improved fullscreen support
* Improved preference dialog
* File properties dialog added
The image viewer is fully functional and usable now.
So, I think it's time to update the translations for it.
BTW, there is an unresolved problem.
When scaling down larger images to fit the smaller window, the image
quality is quite poor.
There's no simple solution to this issue. It's the limitation of QGraphicsView.
When enlarging the image, Qt uses smooth transformation so it works fine.
However this is not the case when shrink larger images.
The only way to avoid this is implementing my own view widget and do
image scaling by manipulating QImage objects directly, which is
non-trivial.
Maybe I should leave this for the next release.
Cheers!
--
--
You received this message because you are subscribed to the Google
Groups "Razor-qt" group.
For more options, visit this group at
http://groups.google.com/group/razor-qt?hl=en
---
You received this message because you are subscribed to the Google Groups
"Razor-qt" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.
PCMan
2014-03-17 04:14:28 UTC
Permalink
Post by gary sheppard
Does the upstream for QGraphicsView accept patches...?
I have been quietly following this project with real interest.
It's not the problem of qt4 QGraphicsView.
It seems to be the limitation of QPainter and it's a known bug.
https://bugreports.qt-project.org/browse/QTBUG-30682
Of course, it's easy to scale the image using QImage and keep an copy
of the scaled image around.
Then, set the scaled image to a QLabel, but that's not a good solution.
This simple way, however, can increases the memory usage dramatically
when the image is enlarged a lot.
So, we need to use some more difficult ways to avoid the memory copy.
Luckily, I already figured out a new way to workaround this today. :-)
Post by gary sheppard
Gary
Post by PCMan
Please see the blog post for the latest screenshot.
http://blog.lxde.org/?p=1086
* Printing support added
* Thumbnail preview (the bottom pane on the screenshot)
* Built-in tool to take a screenshot
* Slide show support
* Improved fullscreen support
* Improved preference dialog
* File properties dialog added
The image viewer is fully functional and usable now.
So, I think it's time to update the translations for it.
BTW, there is an unresolved problem.
When scaling down larger images to fit the smaller window, the image
quality is quite poor.
There's no simple solution to this issue. It's the limitation of QGraphicsView.
When enlarging the image, Qt uses smooth transformation so it works fine.
However this is not the case when shrink larger images.
The only way to avoid this is implementing my own view widget and do
image scaling by manipulating QImage objects directly, which is
non-trivial.
Maybe I should leave this for the next release.
Cheers!
--
--
You received this message because you are subscribed to the Google
Groups "Razor-qt" group.
For more options, visit this group at
http://groups.google.com/group/razor-qt?hl=en
---
You received this message because you are subscribed to the Google Groups
"Razor-qt" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.
--
--
You received this message because you are subscribed to the Google
Groups "Razor-qt" group.
For more options, visit this group at
http://groups.google.com/group/razor-qt?hl=en
---
You received this message because you are subscribed to the Google Groups
"Razor-qt" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.
Sérgio Marques
2014-03-16 23:19:19 UTC
Permalink
DonŽt forget to update strings for translation.

Regards
Post by PCMan
Please see the blog post for the latest screenshot.
http://blog.lxde.org/?p=1086
* Printing support added
* Thumbnail preview (the bottom pane on the screenshot)
* Built-in tool to take a screenshot
* Slide show support
* Improved fullscreen support
* Improved preference dialog
* File properties dialog added
The image viewer is fully functional and usable now.
So, I think it's time to update the translations for it.
BTW, there is an unresolved problem.
When scaling down larger images to fit the smaller window, the image
quality is quite poor.
There's no simple solution to this issue. It's the limitation of QGraphicsView.
When enlarging the image, Qt uses smooth transformation so it works fine.
However this is not the case when shrink larger images.
The only way to avoid this is implementing my own view widget and do
image scaling by manipulating QImage objects directly, which is
non-trivial.
Maybe I should leave this for the next release.
Cheers!
--
--
You received this message because you are subscribed to the Google
Groups "Razor-qt" group.
For more options, visit this group at
http://groups.google.com/group/razor-qt?hl=en
---
You received this message because you are subscribed to the Google Groups
"Razor-qt" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.
--
Sérgio Marques
Kevin Krammer
2014-03-17 07:31:11 UTC
Permalink
Post by PCMan
BTW, there is an unresolved problem.
When scaling down larger images to fit the smaller window, the image
quality is quite poor.
There's no simple solution to this issue. It's the limitation of QGraphicsView.
Have you tried using a QListView in IconView mode and backing it with a simple
QAbstractListModel derived class that returns appropriately scaled images?

Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
PCMan
2014-03-18 07:39:12 UTC
Permalink
Post by Kevin Krammer
Post by PCMan
BTW, there is an unresolved problem.
When scaling down larger images to fit the smaller window, the image
quality is quite poor.
There's no simple solution to this issue. It's the limitation of QGraphicsView.
Have you tried using a QListView in IconView mode and backing it with a
simple QAbstractListModel derived class that returns appropriately scaled
images?
Brilliant idea!
Thanks, but I am afraid I misunderstood your original mail.
I thought the problem was the thumbnail view but you are talking about the
main view.
If we can store the original image only, and doing the scaling for
painting the exposed area on demand, this can save a lot of memory.
True, shouldn't be that difficult as long as there is no arbitraty rotation
involved.
Well, I figured out how to workaround this.
The code is already in the latest git. :-)
Now the memory usage is lower and we can still have good image quality.
There're still some glitches, though.
What I want to do is only scaling the visible area when painting so we
don't need to cache the whole scaled image.
1) map the view rectangle to the source image, get a QImage copy of that part
and scale that
2) "build" the display data by running through the scanlines yourself
Indeed, I use option 2 to avoid copying the visible region. (Build the
subimage using QImage::constBits() of the original image).
I know you are tryting to minimize library dependencies but I vaguely remember
that some image viewers use specialized image libraries for additional speed
and runtime efficiency, e.g. qimagepblitz, imlib, the lib from ImageMagick.
Yes, they're awesome libs.
However, qimageblitz has no qt5 support.
The others are more difficult to use with Qt.
Minimizing memory usage and speed up startup is very important.
Otherwise, we already have too many good and powerful image viewers
and there's no need to write yet another one.
The focus of lximage as a default image viewer is quick startup and
the "just enough" philosophy.

Cheers!
Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
Petr Vanek
2014-03-18 08:41:42 UTC
Permalink
Post by PCMan
I know you are tryting to minimize library dependencies but I vaguely remember
that some image viewers use specialized image libraries for additional speed
and runtime efficiency, e.g. qimagepblitz, imlib, the lib from ImageMagick.
Yes, they're awesome libs.
However, qimageblitz has no qt5 support.
The others are more difficult to use with Qt.
Minimizing memory usage and speed up startup is very important.
Otherwise, we already have too many good and powerful image viewers
and there's no need to write yet another one.
The focus of lximage as a default image viewer is quick startup and
the "just enough" philosophy.
Cheers!
I definitely agree with Kevin. lximage is pretty fine for "open an image
then close" in case of eg. "what is this file?" workflow (=read: that's
how I use it). For "show photos from vacation" workflow I use another
tool which is more complex etc. (nomacs in this case).

p.

Loading...