Version: 4.4.00 (using KDE 4.4.0) OS: Linux Installed from: Ubuntu Packages Kolourpaint removes the JPEG Comment field that is used to annotate jpeg pictures. Why? No other graphics programs does this that I know of. Description: I use the linux utility jhead to edit the JPEG comment field, thus: $ jhead -cl "My comment" mypicture.jpg I now have a jpeg comment: $ jhead mypicture.jpg File name : 1-01.jpg File size : 23234 bytes File date : 2010:03:01 21:23:52 Resolution : 160x225 Comment : My little comment I then edit the picture with Kolourpaint: $ kolourpaint mypicture.jpg ...And the comment is removed: $ jhead mypicture.jpg File name : 1-01.jpg File size : 23234 bytes File date : 2010:03:01 21:23:52 Resolution : 160x225 Would be really grateful if this was fixed. Keep up the great work!
Seems to be a Qt problem: http://bugreports.qt.nokia.com/browse/QTBUG-10568
Ahem, I dont understand. The case is not that the image contains a comment but cannot be read by Qt apps. After the image has been edited and saved with Kolourpaint it no longer exists. Have tried this literally thousands of times. Or, do you mean that Kolourpaint, being a Qt app, does not read the comment when reading the image into RAM for editing, and then saves the image back to HD without the comment?
Yes. Qt does not read the comments therefore they get lost.
Qt5 now reads and writes the comment (however it prefixes it with the string "Description:")
Thanks for the update Mr Koller. I don't wish to sound ungrateful, but I fail to see how this behaviour can be considered an improvement? The comment should just be left as it is, neither prefixed, suffixed or changed in any way from the original file. What if a database started to prefix the contents in its tables? That would be disaster. In my version it is still just removed. So I can not confirm what you say here. But is it really so hard for the developers to just let the comment be? If I could program I would change it myself. But I cant. :-) /Göran
You're right, it's no perfect solution. I just described an "improved" behaviour of the underlying Qt library which kolourpaint uses to read/write image files. There was no change in kolourpaint itself in this regard. Note that kolourpaint does not do the read/write of the image data on its own - it uses the Qt library, which is not perfect in this regard and that is the reason why the current situation is suboptimal. I started to see if I could improve the situation for jpeg files to use a second library, but I have no perfectly working solution right now, sorry.