Rotating EPS leads to colour loss

Bug #29627 reported by Jan Strube
8
Affects Status Importance Assigned to Milestone
Gwenview
Fix Released
Medium
kdegraphics (Ubuntu)
Triaged
Medium
Unassigned

Bug Description

I rotated a jpeg image (imported by digikam).
Clicking the right arrow to browse to the next image brought up a pop-up window to ask if I want to save the modified image. I confirmed with <Enter>
Unfortunately this resulted in the image file being of length 0 bytes...

Performing the same actions on an eps image led to its losing its colors...

Luckily I had backups, but I'm a bit disappointed to have a program in my distro that has bugs as serious as this.

Revision history for this message
Jan Strube (jan-strube-gmx) wrote :

I already filed a bug upstream

Revision history for this message
Phil Bull (philbull) wrote :

Thanks for the report.

Could you link to the upstream bug in this bug report, please?

Revision history for this message
Phil Bull (philbull) wrote :
Changed in gwenview:
status: Unconfirmed → Needs Info
status: Unconfirmed → Needs Info
Revision history for this message
Phil Bull (philbull) wrote :
Revision history for this message
Achim Bohnet (allee) wrote :

Hi Jan,
are you sure upstream still watches sf.net bug tracker?
gwenview is developed in KDE svn repo and uses KDE's
bugzilla. See help->report bug in gwenview.

Questions:

o what type of image (jpeg?) was truncated to zero

o In gwenview did you use Edit -> rotate left/right
or Plugins -> image -> rotate?

Revision history for this message
Jan Strube (jan-strube-gmx) wrote :

Hi,
as the bug report states I was using jpeg.
I used the rotate button.

Thanks for looking into this.

Revision history for this message
Achim Bohnet (allee) wrote :

Hi Jan,

I can't reproduce it currently in up to date dapper.
AFAIR I could last Wednesday (but this was very
late in the night)

Can you try again?

Achim

Revision history for this message
Jérémie Corbier (jcorbier) wrote :

As there is no response from the reporter I am closing this bug. Feel free to reopen this bug if the problem still exists in Dapper.

Changed in gwenview:
status: Needs Info → Rejected
Revision history for this message
Jan Strube (jan-strube-gmx) wrote :

Just installed Dapper. Seems to be fixed.
Thanks,
    Jan

Revision history for this message
Jan Strube (jan-strube-gmx) wrote :

Aehh. Never mind. Please re-open the bug.
Rotating EPS images as follows leads to color loss.WTF ?
Open EPS image.
click the rotate clockwise button
click the right arrow ('next') button
confirm with enter.
go back and enjoy the corrupted image.

Please tell me you can reproduce this ?
Jan

Revision history for this message
Phil Bull (philbull) wrote :

Could you attach a screenshot of the corruption problem, please? And also a small example EPS file if possible.

Also, what version of the package do you have installed?

Thanks

Changed in gwenview:
status: Rejected → Needs Info
Revision history for this message
Jan Strube (jan-strube-gmx) wrote : gwenview showing the bug

This is a screenshot of gwenview after rotating the image.
You can see both versions, because the filefolder preview on the right pane hasn't updated, yet.

Revision history for this message
Jan Strube (jan-strube-gmx) wrote : colorless eps

pic after the faulty transformation.

Revision history for this message
Jan Strube (jan-strube-gmx) wrote : colorful eps

pic before the faulty transformation

Revision history for this message
Jan Strube (jan-strube-gmx) wrote : Re: rotating truncates image to 0

This is with gwenview 1.3.1-0ubuntu4

Revision history for this message
Jan Strube (jan-strube-gmx) wrote :

This is not Ubuntu-specific. I have installed gwenview on another machine with konstruct. The problem exists there also.

Revision history for this message
Phil Bull (philbull) wrote :

Thanks Jan, upstream have been very quiet on this issue, so i don't think we're going to get a fix any time soon. I've made another upstream comment, so fingers crossed. This is a data loss bug too :(

Patches welcome.

Revision history for this message
Phil Bull (philbull) wrote :

OK, I can confirm the EPS issue but I can't reproduce the truncation issue.

Changed in gwenview:
assignee: nobody → kubuntu-team
status: Needs Info → Confirmed
Revision history for this message
In , Matěj Laitl (f-matej) wrote :

Version: 1.3.92 (using KDE KDE 3.5.3)
Installed from: Gentoo Packages
Compiler: GCC 4.1
OS: Linux

This bug applies to *SOME* JPEGs.
When I try rotate a jpeg image, it displays correctly.
But when I save it, a thin row of pixels (usually 5 to 10 pixels thick - depends on the image) is magically transfered from top to bottom. (or other directions)

If I rotate the original image, but save it in PNG instead of JPEG, the problem is gone.

This problem also aplies to Flip and Mirror operations.

This seems related to new JPEG lossles rotation capability introduced in 1.3.92

I'm gonna upload images where this occurs.

I checked it in GV versions: 1.3.92 and SVN revison 572689 (dated 2006-08-13)

Revision history for this message
In , Matěj Laitl (f-matej) wrote :

Created attachment 17356
Original Image

Revision history for this message
In , Matěj Laitl (f-matej) wrote :

Created attachment 17357
Rotated Image

Note the image only seems to be B/W. Technically it's full RGB.

PS: Like the girls? ;-)

Revision history for this message
In , Danakil-kde (danakil-kde) wrote :

Same problem here with this picture : http://danakil.free.fr/linux/bug_if_rotated.jpg
http://danakil.free.fr/linux/right_rotated.jpg -> bug

I don't know if this is important but this picture was resized with the "Resize images..." kipi plugin

Revision history for this message
In , Matěj Laitl (f-matej) wrote :

Still occurs with gwenview 1.4.0 using KDE 3.5.5

Revision history for this message
In , Aurélien Gâteau (agateau) wrote :

This is because the JPEG image dimensions are not a multiple of the MCU size see [1] for an explanation). In this case, there are three solutions to perform a rotation:

1: Apply a lossless rotation, keeping the odd pixels around. Rotating the image the other way will give you back the original image.

2: Apply a lossless rotation, but trim the offending pixels, in your case this would reduce the height of the rotated image from 900 to 896. Rotating the image the other way won't give you back the original image.

3: Apply a lossy rotation, which would give a correct image, but would probably loose some details.

For now, Gwenview adopts a conservative behavior and use #1. What do you think should be done? let the user choose the solution? select #2 or #3 without asking?

If you want to try #2, edit imageutils/jpegcontent.cpp, find the line that says:

  transformoption.trim = false;

and change it to:

  transformoption.trim = true;

[1]: http://www.impulseadventure.com/photo/jpeg-minimum-coded-unit.html

Revision history for this message
In , Matěj Laitl (f-matej) wrote :

Oh, thanks for the nice explanation...

Is it possible to apply a lossy rotation only to the partial MCUs on the sides, while keeping lossless for the rest? Looks like a good compromise for me.

Trimming an image a little (the worst case would be 15 pixels) is not IMHO transparent for user... It alters composition or user-made margins etc.

How often you rotate & save multiple times? I prefer small quality loss to erasing a small part of image.

(maybe stupid) idea: If it saved rotated JPEGs with slightly lower compression ratio, would it eliminate the quality loss?

Revision history for this message
In , Matěj Laitl (f-matej) wrote :

Oh, now I know that i can't be only partially lossy.

So the best solution IMHO:
offer 2 or 3 to an user, and add configuration options:
  always 2.
  always 3.
  ask before each save of rotated odd-sized jpeg.

what about the "maybe stupid idea"?

Now i will only resize my JPEGs to multiples of 8.

Revision history for this message
In , Aurélien Gâteau (agateau) wrote :

Thanks for your suggestions, I will think about it.

As of your "maybe stupid idea": I think it could compensate for some quality loss, but it won't eliminate it and would of course result in a larger file.

Revision history for this message
Rich Johnson (nixternal) wrote :

Still present in Gwenview 1.4.0 (KDE 3.5.5) in Kubuntu 7.04 (Feisty)

Revision history for this message
Rich Johnson (nixternal) wrote :

Just noticed a similar, if not same, bug on the KDE tracking system. In the case of the reporter it was with a JPEG image. I added my note concerning it also appears with .eps files as well.

Adding upstream bug tracking number for KDE

Changed in gwenview:
status: Unconfirmed → Unknown
Revision history for this message
In , Rich Johnson (nixternal) wrote :

This same bug/issue also occurs for me with .eps files. A bug has been reported on the Ubuntu Bug Tracker (Malone) concerning this as well.

https://launchpad.net/distros/ubuntu/+source/gwenview/+bug/29627

Using:
 Gwenview 1.4.0
 KDE 3.5.5

Changed in gwenview:
status: Unknown → Confirmed
Revision history for this message
Rich Johnson (nixternal) wrote :

wrong upstream bug originally reported.

Changed in gwenview:
status: Unknown → Confirmed
Changed in gwenview (Ubuntu):
assignee: Kubuntu Bugs (kubuntu-bugs) → nobody
affects: gwenview (Ubuntu) → kdegraphics (Ubuntu)
Changed in kdegraphics (Ubuntu):
status: Confirmed → Triaged
Revision history for this message
In , Posix-ru-w (posix-ru-w) wrote :

Hi guys,

the same here. KDE 4.5, openSUSE 11.3.

> rpm -qa gwenview
gwenview-4.5.0-170.2.i586

What's about patch or something like this?

Revision history for this message
In , BajK (kaiuwebroulik2) wrote :

I found a solution for myself: Rotating the image, then cutting the out-of-place-part, flipping it (since it is upside down), and attaching it to the top. -> done :D
Still annoying.

Changed in gwenview:
importance: Unknown → Medium
Revision history for this message
In , Alexander van Loon (avanloon) wrote :

Any news on this? Because I just witnessed this bug occur with Gwenview 2.7.2 on KDE 4.7.3.

Revision history for this message
In , Octavian Petre (octavsly) wrote :

gwenview 2.6.4 on KDE 4.6.5 is OK

Revision history for this message
In , Mark S. (invalidopcode) wrote :

With Gwenview 2.7.4 on KDE 4.7.4, I can still reproduce this bug using Matěj Laitl's original pictures.

Revision history for this message
In , Myriam Schweingruber (myriam) wrote :

*** Bug 153066 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Aurélien Gâteau (agateau) wrote :

*** Bug 273417 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Aurélien Gâteau (agateau) wrote :

*** Bug 252693 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Martin Klapetek (martin-klapetek) wrote :

Still present in 4.10.3.

Changed in gwenview:
status: Confirmed → Unknown
Changed in gwenview:
status: Unknown → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.