December Bug of the Month

The KDE Gardening Team selected the December “Bug of the Month”.

It is Bug 288410: KDE daemon kded4 crashes on wake up (related to power/battery change)

Reasons for the nomination:

  • the bug is one of the most reported crashes in our bug tracker,
  • a defunct kded4 process can cause several other issues,
  • it is annoying to restart the desktop just after a wake up,
  • getting a crash dialog when the laptop wakes up makes bad publicity,
  • it might be fixable, it looks like an access to a stale object pointer.

If you are able to fix it, you will receive a honorable mention in the next issue of my blog post “The Bug of the Month” on Planet KDE.

Not all developers that would be able to fix it are subscribed to this bug. If you know someone, feel free to point him here.

Comments (5)

The Bug of the Month

The KDE Gardening Team had the idea to nominate one particular annoying bug as “The Bug of the Month”. While we have literally hundreds of bugs that would qualify, only one bug per month gets nominated.

To get the initiative going, I took the liberty to select the first “Bug of the Month”:
it is Bug 324975: Volume gets restored to 100% after each knotify event.

Reasons for the nomination:

  • the bug affects practically all users, because notifications are not only used by many KDE applications, but also by the KDE Workspaces itself,
  • the bug is severe, as it can damage hardware and ears in extreme cases,
  • the bug is annoying, which was also measured by the rapid growth of votes and comments,
  • the bug seems fixable, we just did not find someone who was able to do it.

If you are able to fix it, you will receive a honorable mention in the next issue of my blog post “The Bug of the Month” on Planet KDE.

We do not have a knotify maintainer. If the issue is in knotify, please suggest a patch with anything that fixes it and create a review request at https://git.reviewboard.kde.org/ and paste the link here. If the issue is in Phonon, its backends, in gstreamer, VLC, pulseaudio, or ALSA, please suggest a patch there.

Not all developers that would be able to fix it are subscribed to this bug. If you know someone, feel free to point him here.

If we receive multiple patches, we will have to decide which of them is best suited, and nominate one of them for the fix.

Comments (4)

KDEPIM back from holidays: You got mail!

If your mail inbox was quiet during the last month, it could have two causes: Either nobody contacted you, or your KDEPIM made holidays!

Jokes aside, KDEPIM 4.14.0 was released with a refactored IMAP fetching code, in preparation for a planned GMail IMAP plugin. The refactoring includes a more modern way to fetch the mails from the server, which unfortunately broke with some specific IMAP servers not completely conforming to the IMAP RFCs.

The effect of this bug is that no mails are fetched from some IMAP servers when you check for new mail, despite new mail arrived. If you were using such a server, be prepared that with the coming KDEPIM 4.14.1 update, the bug is fixed, and your inbox might get flooded with accumulated mail.

For details and patch, see KDE bug 338186. Thanks to to Christian for the prompt fix, and all reporters and testers for providing valuable feedback!

Comments (3)

About a QML Junior Job

Few days ago, we received a bug report about the Plasma calculator widget (plasmoid). Seeing that this bug had also been reported a few months earlier, I wondered how hard it would be to fix it.

The calculator widget is written in QML, a relatively young language, so my experience is rather limited. But playing with QML widgets is very easy: you just need a text editor, change the source, and use the plasma-windowed command to launch the modified plasmoid. No compilation or installing is needed.

So did I fix the bug? Yes and no. Changing some “if’s”, I was able to fix the bug, but playing with the calculator, I noticed a severe regression: If you typed “3+4+5=6+7=” it would first calculate 12, then 25.

To be honest, I was simply too lazy to investigate further. I reverted the changes, and marked the bug as a Junior Job instead. These are bugs that KDE developers believe to be relatively easy to fix. My intention was evil: Someone else should get his hands dirty! And I got rewarded …

A few days later, Paul added a patch to the bug report, fixing it without nasty regressions. After it went through code review at reviewboard.kde.org, it had been committed to the KDE code repositories, and you can see his work starting with the coming 4.11.2 release of our software compilation.

Why am I telling you all this? First, if you are a looking for a way to contribute to KDE projects, the list of junior jobs might be a good start. If you get stuck and need help, check http://techbase.kde.org/Contribute. It contains many links for ways to contact KDE developers.

Second, as the maintainer of KDE software, you should keep an eye on bug reports. If a bug looks easy, do not fix it immediately, but mark it as a junior job instead. This way, you give new contributors a chance to start contributing. Without a list of junior jobs, you will have a much harder time finding help.

And finally, the number of Plasma widgets written in QML is growing. Even if not marked as a junior job, some Plasma bugs can be solved without much coding experience. See this bug for another example.

Leave a Comment

ImageZero 5x faster than WebP

When the initial preview version of ImageZero (IZ) had been announced, many readers were interested in benchmarks against other compression algorithms, such as JPEG-2000 or Google’s new lossless WebP. At that time, however, the WebP software was not yet ready for testing; it was not possible to benchmark the decompression time, because the software could only convert back to PNG (and PNG encoding is known to be slow), and the compression crashed on large photos.

Luckily, the 0.2 version of the WebP tools has been released, and with this, the Lossless Photo Compression Benchmark has been updated to include results for WebP and ImageZero. Here are the most interesting results:

Software / License Size (% of 3.46 GB) Compression Decompression
uncompressed 100.0% - -
bzip2 -1 (bzip2 License) 56.3% 476 s 218 s
PNG (libpng License) 42.5% 844 s 72 s
ImageZero (BSD) 41.3% 23 s 21 s
JPEG-LS (HP License) 37.4% 107 s 92 s
lossless WebP (BSD) 35.6% 7525 s 110 s
Flic (proprietary) 30.0% 210 s 231 s
Gralic (proprietary) 28.1% 1734 s 1897 s

Comments (4)

Reverse Antialiasing for Image Scaling

When enlarging screen images, for example using screen magnifier utilities such as KDE’s KMag, the antialiasing used for rendering text becomes very visible (see left image). To limit the effect, simple pixel replication is not suited, but a different scaling algorithm needs to be used. The simplest of those algorithms is the bilinear filtering method, which is quite fast, but has the disadvantage of blurring the result.

More advanced methods, such as the Mitchell filter, obtain better results, but are slower to compute and introduce new kinds of artifacts, called ringing. For more information about the kind of artifacts linear scaling methods introduce, please refer to this interpolation introduction.

Image Scaling Comparison

Several methods for non-linear image scaling were proposed, some of them especially fast, some of them optimized for pixel art, others using several megabytes of trained neuronal networks etc. There is always a trade off you have to make between the image quality, and the speed you get.

While the source code for the neuronal network-based scaler is available (as well as the trained data), it was out of scope for a simple screen magnifier, such as KMag. The algorithm should be fast (maybe the speed of a bicubic scaler), and work without additional data, so that it can be used for KMag.

Again, I was not satisfied with the methods that were previously freely available, so I developed my own version of a scaling algorithm. This time it is optimized for scaling antialiased text or rasterized vector graphics, because it effectively reverses the antialiasing process. The quality is certainly not perfect, especially when faced with thin diagonal lines, but I consider it good and fast enough to be useful in KMag. It should also be quite useful as a resolution doubler for high-resolution (“Retina”) displays, and GPU implementations should be simple.

On the right image, you can see my result, using some text and some graphics from the Oxygen team (unscaled image here). To get an impression how it looks as a screen magnifier, here is a screenshot of a Dolphin window (made by Peter Penz), and its resolution doubled version.

A description of the algorithm will follow later. Just be a bit patient, I am still learning TeX :)

Comments (17)

Fast Lossless Color Image Compression

In the research field of compression, the usual goal is to achieve the best possible compression rate. The best known algorithms, however, are very slow, and sometimes impractical for real-world applications.

When dealing with images, the situation becomes especially worse considering the fact that photo resolutions are ever increasing. Image sizes of 4500×3000 pixels (or more) are not uncommon. Uncompressed, this amounts to 40 megabytes for 24 bits/pixel, and having to wait several seconds for the image to load or save is annoying.


London Bridge (Tower Bridge) : Reflection on the River Thames
Photo by Anirudh Koul at Flickr

JPEG, the de-facto standard for image compression, while still one of the fastest methods available, has one major drawback: it compresses lossy, in other words, whenever the image is saved, some fidelity is lost. For situations where multiple load/save cycles are to be expected, for example in photo manipulation applications, this is inacceptable.

In the recent months, I have been evaluating available lossless image compression algorithms to select one that is fast, but also good in compression efficiency.

Looking at the Lossless Photo Compression Benchmark I was a bit disappointed to find out that PNG, while quite fast in decompression and offering moderate compression rates, is very slow when compressing images.

The JPEG-LS format, being significantly faster at compression compared to PNG, and even offering improved compression rates of about 15%, seemed a good choice at first. It has, however, several drawbacks: Not only is it slower than PNG in decompression, but HP also has a patent on the used context modeling. No-Go.

What does a programmer do, when he is not satisfied with what is available? Right, he re-invents the world, only to make it better: Last week, I released the initial version of ImageZero (iz, pronounced “easy”), a high-performance lossless RGB photo codec.

Being twice as fast as PNG when decompressing (and more than 20 times faster when compressing) it achieves compression ratios that are near or better than PNG for natural photos, sometimes even better than JPEG-LS for very high quality photos. ImageZero is not intended for grayscale or artificial images, but I may improve the algorithms for those image types.

Method File Size Compression Decompression
uncompressed 46380 KB - -
JLS 14984 KB 6.6 s 7.3 s
PNG 16256 KB 42.4 s 2.4 s
IZ 15496 KB 1.2 s 1.3 s
Results for the full resolution “London Bridge” photo (4507×3512 pixels)

The used algorithm is really easy: the per-pixel compression and decompression is done without any branches (except for a single branch in the bit coder), so that on today’s super scalar CPUs it can be executed very fast.

Possible uses include:
– image/thumbnail databases
– backing store for image processing apps
– future icon format

If you are interested, please help shaping the library API and file format for .iz files. We can use the kde-imaging mailing list for discussion.

Comments (44)

Older Posts »
Follow

Get every new post delivered to your Inbox.

Join 137 other followers