Welcome!
Gwenview is a fast and easy to use image viewer for KDE. For more information,
have a look at
the overview.
News
Qt Image Decoders Stepping on Each Others
Aurélien
- 2012.03.30
A weird bug
In December last year, Falk Krönert filled a strange bug: Gwenview failed to load some PNG images, which other applications were able to display flawlessly. I couldn’t reproduce it back then with Gwenview 2.7.3, so couldn’t dig any further.
Falk did not give up so easily though. After further investigations, he discovered the bug only happened with images whose width would be 2560 or 2808. Since I still couldn’t reproduce it, he provided me with a QEmu image of his openSUSE installation so that I could investigate (now that is one dedicated bug reporter!)
Investigating
Running the QEmu image, I was finally able to reproduce the bug. I started investigating, installing the necessary packages to build Gwenview and my beloved cgdb, learning how to use Zypper in the process.
Step one, an image format from the past…
I quickly discovered Qt was not able to discover the image format of the PNG. The code looked like this:
QBuffer buffer;
buffer.setBuffer(&mData); // mData contains the first 256 bytes of the image
buffer.open(QIODevice::ReadOnly);
QImageReader reader(&buffer);
mFormat = reader.format();
if (mFormat.isEmpty()) {
return false;
}
In the case of this image, “mFormat” was supposed to contain “png”, but it was empty instead.
In case you are not familiar with Qt image plugin code, it works like this: Qt provides a base class, QImageIOHandler, which image decoders must inherit from. so there is a QJpegHandler, a QPngHandler and so on. Some of these handlers are provided by Qt directly in QtGui.so, others are provided by Qt and kdelibs (and possibly others) as plugins installed in “plugins/imageformats”.
Here is QImageReader::format() code:
QByteArray QImageReader::format() const
{
if (d->format.isEmpty()) {
if (!d->initHandler())
return QByteArray();
return d->handler->canRead() ? d->handler->format() : QByteArray();
}
return d->format;
}
Debugger was telling me d->handler was correctly created by initHandler(), but QPngHandler::canRead() was never called!
Quite puzzled by this, I finally resorted to place a breakpoint in QImageIOHandler constructor. Once I hit the breakpoints, I printed the backtrace, and was astonished to find myself inside the PCX handler provided by kdelibs! This explained why QPngHandler::canRead() was not called, QImageReader was calling PCXHandler::canRead(), which unsurprisedly returned false.
This does not explain how Qt decided the image was a PCX in the first place. To decide which handler to use, initHandler() calls all implementations of QImageIOHandler::canRead(), the first one to answer true wins. PCXHandler::canRead() implementation is not very selective: it returns true if the first byte of the image is 10 (According to Wikipedia it should be possible to check at least the first two bytes, need to look into this).
Here is an hex-dump of the first bytes of the PNG image:
89 50 4e 47 0d 0a 1a 0a 00 00 00 0d 49 48 44 52 |.PNG........IHDR|
00 00 0a 00 00 00 00 02 08 02 00 00 00 1b 8e 12 |................|
There are a few 10 (0a in the dump) values but the first byte is definitely not 10.
Maybe the PCX loader is looking at the wrong position? I decided to place a breakpoint in PCXHandler::canRead() and print device->pos(). Sure enough, it sayd the position was 18, instead of the expected 0… If you look at position 18 (starting from 0) in the dump there is indeed a 0a value.
It is interesting to look at what this 0a stands for: The PNG specification tells us a PNG starts with an 8 byte signature, followed by a series of chunks. The first chunk must be an IHDR chunk. This chunk starts with “IHDR”, followed by four bytes representing the image width, in most significant byte order. This means the first four bytes in the second line of the dump (00 00 0a 00) are the image width, and indeed, 0a00 is the hexadecimal for 2560… Do you remember the bug was only happening for some image sizes? If the width had been 2559, the IHDR chunk would have started with 00 00 09 ff, and thus the PCX handler would not have identified this image as a PCX.
Another format gets in…
While the PCX handler could be improved to use more than one byte as a signature, it is not the real problem: had device->pos() been correctly set to 0, it wouldn’t have identified the image as PCX. QImageIOHandler::canRead() documentation explicitly says:
When reimplementing canRead(), make sure that the I/O device (device()) is left in its original state (e.g., by using peek() rather than read()).
Someone was not playing by the rules and was altering the device position before PCXHandler::canRead() was reached.
I was starting to suspect one of the other image handlers was doing something nasty. To try to isolate the culprit, I first removed all KDE image plugins but the PCX handler. No luck, still buggy. I then removed all Qt image plugins (PNG was still there as it is one of those built into QtGui.so) Bingo! The image was now being correctly identified. Using a quick dichotomy, I found out the TGA plugin was the nasty boy.
QTgaHandler::canRead() looks like this:
bool QTgaHandler::canRead(QIODevice *device)
{
if (!device) {
qWarning("QTgaHandler::canRead() called with no device");
return false;
}
QTgaFile tga(device);
return tga.isValid();
}
Looking at the code you can probably guess it: QTgaFile constructor does not take care of not altering QIODevice state. Looking at the Git history for this handler shows it was copied from QtQuick3D to Qt before the 4.8.0 release, which explains why there was no problem when running Gwenview on top of Qt 4.7.
It is a bit sad however that this code was brought in instead of using KDE TGA handler, which has been around for a while, does not suffer from this bug and have (limited) write supports whereas the Qt handler is read-only.
Fixing time
I worked around this bug in Gwenview by taking advantage of the fact that QImageReader accept an optional “format” parameter, which can be used as a hint: QImageReader will first try to use an image handler which supports this format.
I was not using this feature until now because I thought passing a format would make QImageReader fail if the image was not of the specified format. It turns out I was wrong: the format parameter is just a hint, if the image cannot be loaded with a handler implementing this format, QImageReader will try the others. I should probably propose a patch for the documentation to reflect that.
The real fix however is to teach QTgaHandler proper manners. I just posted a fix on qt-project.org, hopefully it will get in.
Gwenview 2.8.2 (from upcoming KDE SC 4.8.2), has the work-around in but if you haven’t upgraded yet, you can fix the bug by simply removing the TGA handler plugin. Look for a file named libqtga.so. It should be in:
- openSUSE (64 bits): /usr/lib64/qt4/plugins/imageformats/
- Ubuntu|Debian (64 bits): /usr/lib/x86_64-linux-gnu/qt4/plugins/imageformats/
(I don’t know the location for 32 bits systems)
So to summarize, a rogue TGA handler was tricking a sloppy PCX handler into identifying a PNG file into a PCX file, what a mess!
What’s new in Gwenview from KDE 4.8
Aurélien
- 2012.01.27
Now that KDE 4.8 has been released, it’s time to recap all changes you will find in Gwenview.
The main change is the addition of animations when viewing images: crossfading between images and nicer-to-use comparisons. You can learn more from this previous blog article.
This change was not nice for users of some graphic cards whose OpenGL drivers do not support what Gwenview tries to do. I decided to play it safe for now: animations in Gwenview now use software rendering by default. For better performance, you can enable OpenGL rendering in the configuration dialog.
This new version of Gwenview also comes with a lot of smaller changes, some of them caused by the limitations which were introduced by the new animation system.
Scrolling and Zooming
- No more scrollbars: A bird-eye view lets you scroll the image.
- Nicer zoom cursor. I realized Qt now supports truecolor cursors, so I drew a nicer magnifying glass cursor instead of the black+white+1bit-alpha-channel version. Holding down Ctrl to zoom won’t bring you back to the 90s anymore!
- Pressing ‘F’ toggles zoom-to-fit on and off.
- More consistent behavior: SVG images can now be scrolled using the same shortcuts as scrolling raster images.
Global User interface changes
- The “sidebar collapser”, the little arrow on the left of the view which let you hide the sidebar is gone. It has been replaced by a button in the statusbar.
- Labels for some of the toolbar buttons have been removed, reducing its width. It should now be more usable on small netbook-like screens.
Tools
- The red-eye reduction and crop tools no longer show floating widgets over the image, a thin bar slides from the bottom of the window instead.
Behavior
- Compared images follow thumbnail view order: previously when one selected two or more images to compare them, they would not necessarily appear in the same order as in the thumbnail bar.
- Arrow-key navigation in zoom-to-fit mode. This one has been requested by quite a few people. When an image is in zoom-to-fit mode, you can go to the previous and next image with the arrow keys. When you zoom in, arrow keys are used to scroll the image. This is very similar to the behavior provided by phones or digital cameras.
Video support
- The on-screen-display is now transparent.
- One can use the left and right arrow keys to seek
- A late addition: an undocumented shortcut (P) to toggle playback
- Note that video support is a bit fishy right now: it seems Phonon does not always play well with its video widget being embedded in a QGraphicsView, known symptoms are wrong colors or wrong aspect ratio. Hopefully this will improve in the next releases.
4.8.1 should bring you its usual series of bug fixes, among them is generating thumbnails for all images of the current folder, not only the currently visible ones. This fix is a bit bigger than usual *.1 fixes, so testers are welcome: the code lives in Gwenview git repository, in the “gen-all-thumbnails” branch.
I hope you enjoy this new Gwenview!
Oups, my burst shots are all shuffled!
Aurélien
- 2012.01.05
At the end of December my wife and I were invited with other parents to my daughter last dance lesson of the year.
Of course, I brought my camera with me. I shot a little bit more than 160 pictures from the one hour lesson (if that sounds like a crazy number, then you probably don't have kids...).
Some of them were shot in burst mode, where the camera continuously takes a few pictures per second, increasing the chances the wannabe photographer gets at least one decent picture (and partially explaining the embarrassing large number of shots...)
Importing, aka, the mistake
Back home, I imported the pictures with Gwenview importer and started to comb through them to get rid of the cruft.
Burst mode is fun, but Gwenview importer does not play nice with it: by default it renames imported pictures using the shot date found in the image EXIF information. I like this feature because I find it more expressive to have a picture named "2011-12-17_12-47-47.jpg" than "pict0234.jpg". It has one big drawback though: the precision of time information stored in EXIF is one second. When one shoots in burst mode, more than one picture per second is produced... In such a situation, Gwenview importer inserts a "_n" suffix just before the extension dot, where "n" starts at "1" and is increased until the importer can create a file name which does not exist. It gets even a bit nastier when you realize Gwenview importer does not necessarily import pictures in file order, meaning the "n" values do not necessarily match the order in which the pictures were taken... not good.
Workarounds
I want to address this issue correctly in KDE SC 4.9, but meanwhile here are some workarounds.
If you haven't yet imported your burst-mode pictures, you can either disable image renaming altogether or change the "Rename Format" from "{date}{time}.{ext.lower}" to "{date}{time}_{name.lower}.{ext.lower}". This way imported images will still carry the original image name and will be properly ordered. File names will be a bit ugly, but at least you will be safe.
Configuring Gwenview importer to append the original file name at the end of imported pictures
If you have already imported the pictures it gets a bit more tricky. I looked at the EXIF information my camera recorded and noticed pictures have a "Exif.Panasonic.SequenceNumber" tag (yes, that sounds vendor-specific :/). This tag is set to 0 for normal pictures, but starts at 1 and goes up for burst-mode pictures. I thus put together "pict-exif-rename", a quick Python script using pyexiv2 to rename all images, appending a suffix based on the sequence number if it is greater than 0.
I pushed "pict-exif-rename" as a github gist, maybe you will find it useful.
It would be interesting to hear from different camera owners about the presence of the "Exif.Panasonic.SequenceNumber" tag (or an equivalent). You can quickly check its presence by running "exiv2 -Pkv a_picture.jpg | grep SequenceNumber". All pictures taken with my camera (Panasonic DMC-FS16) have this tag, it is set to 0 for non burst-mode pictures.
Oups, my burst shots are all shuffled!
Aurélien
- 2012.01.04
At the end of December my wife and I were invited with other parents to my daughter last dance lesson of the year.
Of course, I brought my camera with me. I shot a little bit more than 160 pictures from the one hour lesson (if that sounds like a crazy number, then you probably don’t have kids…).
Some of them were shot in burst mode, where the camera continuously takes a few pictures per second, increasing the chances the wannabe photographer gets at least one decent picture (and partially explaining the embarrassing large number of shots…)
Importing, aka, the mistake
Back home, I imported the pictures with Gwenview importer and started to comb through them to get rid of the cruft.
Burst mode is fun, but Gwenview importer does not play nice with it: by default it renames imported pictures using the shot date found in the image EXIF information. I like this feature because I find it more expressive to have a picture named “2011-12-17_12-47-47.jpg” than “pict0234.jpg”. It has one big drawback though: the precision of time information stored in EXIF is one second. When one shoots in burst mode, more than one picture per second is produced… In such a situation, Gwenview importer inserts a “_n” suffix just before the extension dot, where “n” starts at “1″ and is increased until the importer can create a file name which does not exist. It gets even a bit nastier when you realize Gwenview importer does not necessarily import pictures in file order, meaning the “n” values do not necessarily match the order in which the pictures were taken… not good.
Workarounds
I want to address this issue correctly in KDE SC 4.9, but meanwhile here are some workarounds.
If you haven’t yet imported your burst-mode pictures, you can either disable image renaming altogether or change the “Rename Format” from “{date}_{time}.{ext.lower}” to “{date}_{time}_{name.lower}.{ext.lower}”. This way imported images will still carry the original image name and will be properly ordered. File names will be a bit ugly, but at least you will be safe.
Configuring Gwenview importer to append the original file name at the end of imported pictures
If you have already imported the pictures it gets a bit more tricky. I looked at the EXIF information my camera recorded and noticed pictures have a “Exif.Panasonic.SequenceNumber” tag (yes, that sounds vendor-specific :/). This tag is set to 0 for normal pictures, but starts at 1 and goes up for burst-mode pictures. I thus put together “pict-exif-rename”, a quick Python script using pyexiv2 to rename all images, appending a suffix based on the sequence number if it is greater than 0.
I pushed “pict-exif-rename” as a github gist, maybe you will find it useful.
It would be interesting to hear from different camera owners about the presence of the “Exif.Panasonic.SequenceNumber” tag (or an equivalent). You can quickly check its presence by running “exiv2 -Pkv a_picture.jpg | grep SequenceNumber”. All pictures taken with my camera (Panasonic DMC-FS16) have this tag, it is set to 0 for non burst-mode pictures.
Crossfade!
Aurélien
- 2011.10.19
I have been a bit quiet lately, but haven’t been slacking 
Among other things, I started working on implementing one of the oldest most-wanted feature of Gwenview: crossfade transitions between images. I have pushed the code to Gwenview git repository. It still lives in topic branches for now though.
I first worked with an evolution of the QWidget-based code. This is quite stable but it is too slow at HD (1920×1080) resolution. You can find this work in the “agateau/xfade” branch.
I thus decided to bite the bullet and start a massive refactor of the code, rebasing it on QGraphicsView with an OpenGL viewport. This is the much-faster-but-currently-full-of-regressions “agateau/xfade-qgv” branch.
This change makes Gwenview much smoother to use when going through images but it also helps quite a bit in comparison mode: images move around when selected and unselected, making it easier to track where they go.
I recorded a short video to demonstrate the current state of the xfade-qgv branch. It demonstrates both going through images and image comparison. In this video Gwenview runs on a HD monitor. Note that I had to record it with a digital camera, desktop recorders did not produce a smooth animation, so the video quality is not exactly optimal.
(Watch on blip.tv)
I hope I can bring the xfade-qgv branch back to feature-parity with master so that it can be merged in before Soft Feature Freeze (October 27th!).
June 2011 wrap-up
Aurélien
- 2011.07.07
8th of July, high time for June wrap up...
I was away for a little less than two weeks in June, as I attended the Qt Contributor Summit (see report) and a Canonical Sprint.
Gwenview
Most of my time this month was spent on Gwenview, polishing it to be ready for the KDE SC 4.7 release. Here is the list of changes I made:
Black screen fixes
Thumbnails are now automatically refreshed when they are modified from a KIPI plugin or outside Gwenview. Additionally, the user can press F5 in thumbnail mode to force a thumbnail refresh.
In the importer, the "Import all" button is now only enabled if there are documents to import.
The crop tool got reworked:
The widget now remains visible when zooming and scrolling
The widget adjusts its position when the window is enlarged
The crop side handles are always visible even when one zoom to
a point where only part of the crop selection is visible
Other smaller bug fixes...
"Common UI mistakes in KDE applications" series
I didn't write any new article for my series on common UI mistakes in KDE applications but I created [a page to link them all](/article-series-2/common-ui-mistakes-in-kde-applications/).
I would like to add links to the page from the articles themselves but I need advice on the best way to do this without causing Planet KDE and Planet Ubuntu to repost them. Any idea?
Desktop Summit
I registered for the Desktop Summit, and will hopefully be holding a workshop there, more on this later.
Skanlite
Finally I did some work on Skanlite, which I use quite a lot to scan my receipts.
Removed crosshair cursor from view scrollbars
Added colon for property labels
Moved checkbox labels to the right
Proposed use of KIntNumInput and KDoubleNumInput to replace home-made widgets (not in yet)
I have other ideas for Skanlite. Time will tell if I get some of them done in July (and if Kåre, Skanlite maintainer, accepts them of course)
As usual, if you want to, you are welcome to support me.
Hunting down black screens
Aurélien
- 2011.06.03
Today I spent some time on Gwenview, trying to get rid of an annoying bug: when you browse images in fullscreen or when you zoom into large images, sometimes the screen goes black for a few milliseconds (bug 227155)
The changes ended up being a bit more involved than I expected, but I got rid of most black screens. You may still get some when you go to a document of a "different kind" (going from a photo to an SVG for example) but you should not see black screens anymore when going through photos or zooming them in.
I fixed a few regressions and I am quite confident it is now stable, but Gwenview could use more testers for this change. If you use KDE master (the fixes are not in Beta 2), just go through your images, manipulate them and if you find some weirdness, file a bug, help all of us enjoy a black-screen-less photo browsing world!
April May 2011 wrap-up
Aurélien
- 2011.05.28
Woah... I have been neglecting my blogging duties lately... I spent the first two weeks of May away from home: Started with a Canonical sprint, followed by 2 days at Ubuntu Developer Summit (UDS), followed by 2 days at Solutions Linux. I didn't manage to write any April wrap-up post while I was away and it felt lame to write one in the middle of May so I am going to sum up both April and May in this post.
KMessageWidget
KMessageWidget got integrated into kdelibs in time for 4.7! I am quite happy with this. There are one or two bugs I need to address and a few features I would like to add later, but it is already useful.
It feels good to read about other projects starting to use it. I am looking forward to being surprised by a KMessageWidget poping up in applications I use.
Gwenview
Besides KMessageWidget, I worked a bit on Gwenview, mostly fixing bugs:
Fixed build with libjpeg-turbo
Improved the image info sidebar:
Fixed display of megapixel count
Show tooltips for cropped texts
Made it possible to select text
Some work on keyboard handling:
Prevent Nepomuk description field from stealing focus
Made it possible to switch between two images with Tab and Shift+Tab
Added a shortcut to the "Synchronize document views" action (Ctrl+Y)
At startup, focus the current document view, instead of the zoom slider
When browsing the trash, it is now possible to restore files
Fixed the nasty "Images are renamed on double-click" bug: If you ran KDE in double-click mode, double-clicking an image would show it but it would also trigger the inline rename, if you then pressed "space" to go to the next image it would stay there and replace the image name with " "...
Do not block the UI while loading KIPI plugins. That one has been bothering me for a while: before this fix, Gwenview would block while loading plugins when you first clicked the "Plugins" menu. Now it loads them in the background and show a disabled "Loading..." entry in the menu.
Replaced some custom widgets with KMessageWidget
Got rid of the error dialog which appeared sometimes when an image failed to load
UDS and Solutions Linux
These two days at UDS was quite productive. It felt good to hang out again with Kubuntu regulars and to get to meet others like Michał Zając and Alex Fiestas (another KDE developer getting involved in Kubuntu, yeah!) for the first time.
Alex gave me some interesting feedback on KMessageWidget, which he started to use in Bluedevil control module.
I am also particularly pleased I was able to work with Jonathan Thomas on some UI polish for Muon. You may have read about it on Jonathan blog. And Muon is now using KMessageWidget too, how awesome is that?
I would have preferred to stay the full week at UDS but I also wanted to attend Solutions Linux, a French Linux exhibition where I have been helping manning the KDE booth for a few years now. So I flew back from Budapest to Paris in the early morning of Wednesday.
Solutions Linux was great as usual. Contrary to previous years, we didn't have any Kubuntu CD. This year we gave away some nice OpenSuSE DVD. I had a bunch of Kubuntu goodies however: there were some leftover stickers and pens from last year which I brought back this year. And I still have some left for Solutions Linux 2012! (Yes I got a lot of goodies last year)
As usual we were located next to our GNOME friends. It seems every year they aim for a more minimalist booth: last year the booth was sometimes unmanned... but on the last day this year they managed to reach a whole new level: a computer-less booth! And to say people do not believe us when we tell them GNOME is all about removing options :). Since we are competitors, but gentlemen nevertheless, we lend them a laptop on which they ran the GNOME 3 live DVD.
I played a bit with GNOME 3: it's quite nice actually, there are a few ideas I really like. I am probably going to install it on my machine to play with it a bit more.
Diary
In other news, I started writing a daily diary. Sometimes at the end of the day I feel like I haven't been doing anything, writing down tasks I did like this avoid that feeling and helps improving my mood :). It should also be quite helpful to write future wrap ups.
I keep this diary in a plain-old paper-based notebook as I came to really enjoy the feeling of writing lines with a pen on plain paper and taking a break from the keyboard, but I am a bit torn: I would love to have a way to grep my diary! Unfortunately I don't think anyone has created grep-able notebooks yet, too bad.
March 2011 wrap-up
Aurélien
- 2011.04.04
4th of April, time for March wrap-up…
What happened in March?
Gwenview compare mode
In last month wrap-up, I presented my work on Gwenview compare mode, but was not satisfied with the user interface for the compare mode: I thought it was too busy. I simplified it by getting rid of the concept of best-candidate, instead you just select more than one (and up to 6) documents and Gwenview will show them side by side. The only user interface specific to compare-mode is a small HUD at the bottom of the document views, allowing you to either deselect the document or trash it.
After a few improvements like adding a synchronize feature, +/- select buttons for items in the thumbnail bar and highlighting of the current item in the thumbnail bar, I decided it was good enough to be merged to master. There are still a few adjustments I want to do, but nothing too intrusive.
Compare two images
Or go crazy and compare 6 of them… (I hope you have a big screen!)
Compare mode works in fullscreen too
Communication
Spent some time preparing my slides for the two presentations I gave at the KDE 4.6 Release Party organized by the Toulibre association in Toulouse. The event was really great, a warm thank-you to Toulibre. I think both presentations went rather well, except for some hiccup while demonstrating Gwenview Importer. Presentations have been recorded, videos as well as slides should be online soon.
I also wrote a new post for my series on common UI errors in KDE applications: Being GNOME friendly. It received a mixed reception, but given the subject, that was to be expected.
Other contributions
Since I took KDE Partition Manager as an example of margins being wrong in my UI errors article, I tried to make up for pointing fingers by patching the problem. Patch has been accepted. Here is a montage showing the space savings:
Note that you should also get a bit more usable space when using Oxygen theme, even if it reduces the effects of double-margins.
I also resumed my use of RSIBreak, “thanks” to the return of my left wrist pain. This led me to port it from QSystemTrayIcon to KStatusNotifierItem. Patch is in, you can now enjoy nicer tooltips and mouse-over effects (and even get a fully functional RSIBreak if, like me, you find yourself running Unity 2D in a nested session from within a KDE session, but I guess it’s not a common situation…)
What’s planned for April?
For April I’d like to make the latest adjustments to Gwenview compare mode and maybe start working on some metadata-related bugs… I am not too sure yet, we’ll see. I am also attending KDE UX Sprint in Berlin, which I am looking forward to. Who knows what will come out of it?
So, not much planned, but that does not mean I plan to slack! Don’t worry, your contributions will be put into good use
