New features of Lximage qt image viewer
118 views
Skip to first unread message
PCMan
Mar 16, 2014, 10:42:11 AM3/16/14
to lxde-list, razo...@googlegroups.com
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!
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
Mar 16, 2014, 2:03:28 PM3/16/14
to razo...@googlegroups.com, lxde-list
Does the upstream for QGraphicsView accept patches...?
I have been quietly following this project with real interest.
--
--
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 email to razor-qt+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Sérgio Marques
Mar 16, 2014, 7:19:19 PM3/16/14
to Razor-qt Group, lxde-list
Don´t forget to update strings for translation.
Regards
--
--
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 email to razor-qt+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Sérgio Marques
PCMan
Mar 17, 2014, 12:14:28 AM3/17/14
to razo...@googlegroups.com, lxde-list
On Mon, Mar 17, 2014 at 2:03 AM, gary sheppard <rhy...@gmail.com> wrote:
> 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.
> Does the upstream for QGraphicsView accept patches...?
> I have been quietly following this project with real interest.
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. :-)
PCMan
Mar 18, 2014, 3:39:12 AM3/18/14
to kra...@kde.org, lxde-list, razo...@googlegroups.com
On Mon, Mar 17, 2014 at 4:32 PM, Kevin Krammer <kra...@kde.org> wrote:
> On Monday, 2014-03-17 ,16:15:40 you wrote:
>> On Mon, Mar 17, 2014 at 3:31 PM, Kevin Krammer <kra...@kde.org> wrote:
>> > 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.
>
> I can see two options:
> 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
> On Monday, 2014-03-17 ,16:15:40 you wrote:
>> On Mon, Mar 17, 2014 at 3:31 PM, Kevin Krammer <kra...@kde.org> wrote:
>> > On Sunday, 2014-03-16, 22:42:11, PCMan wrote:
>> >> 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
>> >> 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.
>> >
>> > 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.
>
> I can see two options:
> 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
Mar 18, 2014, 4:41:42 AM3/18/14
to razor-qt, lxde-list
On 03/18/2014 08:39 AM, PCMan wrote:
>> 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
>> 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!
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.
Reply all
Reply to author
Forward
0 new messages