Issue 122758 - Progressive corruption of rotated images
Summary: Progressive corruption of rotated images
Alias: None
Product: Impress
Classification: Application
Component: editing (show other issues)
Version: 4.0.0-dev
Hardware: All Unix, all
: P3 Normal (vote)
Target Milestone: 4.0.0
Assignee: AOO issues mailing list
QA Contact:
Keywords: regression
Depends on:
Blocks: 122836
  Show dependency treegraph
Reported: 2013-07-16 08:50 UTC by rgb
Modified: 2017-05-20 11:41 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---
jsc: 4.0.0_release_blocker+

ALG: patch to add initialization to allocated mask (598 bytes, patch)
2013-07-16 12:43 UTC, Armin Le Grand
no flags Details | Diff
3.4.1 - 4.0.0 comparison (615.02 KB, image/png)
2013-07-18 01:46 UTC, Ariel Constenla-Haile
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description rgb 2013-07-16 08:50:52 UTC
On an empty Impress file, insert a picture and rotate it. On editing area will show OK, but on thumbnail panel will start to show corruption. Now go to presentation (F5) and return to editing mode: the picture on the editing area gets corrupted. Now go to presentation mode again: the picture is corrupted.

Note that the picture file inside the odp presentation do not present problems, it's the presentation that fails to display properly the rotated picture, but if you export the presentation to pdf, you get the corrupted image. If I open the odp file on Okular, it displays without problems.

See the following webm video to view to problem in real time:

(you can open it with VLC or MPlayer, for example). The video have some glitches, but you can see the progressive picture corruption.

Problem does not happen on 3.4.1 (even if some moire effect is visible on thumbnail panel), so setting "regression" as keyword.
Comment 1 Armin Le Grand 2013-07-16 10:05:51 UTC
ALG: Could not reproduce on Win7 or Mac, thus for now setting to Unix, all.
Also could not reproduce on xubuntu 64bit with a fresh build (r1503264). Trying further.
BTW: What ImageFormat is used to transport to presentation and PDF export? It's hold in the Metafile, but need to check the format. Evtl. it's a format for which we updated the suppurt library recently - and that on linux...?
Comment 2 Armin Le Grand 2013-07-16 10:17:15 UTC
ALG: Can someone who can reproduce that please define exactly on what system this happens?
Comment 3 Armin Le Grand 2013-07-16 12:40:59 UTC
ALG: Found after some debugging on linux. First, I could reproduce it, it's independent from #122753#. Reason is that the 1-bit mask added before the bitmap is rotated is *nit* innitialized under linux. Either this has changed in vcl or the X-implementation itself. Adding initialization to non-transparent (COL_BLACK) makes all work well. Preparing patch...
Comment 4 Armin Le Grand 2013-07-16 12:43:41 UTC
Created attachment 81088 [details]
ALG: patch to add initialization to allocated mask
Comment 5 SVN Robot 2013-07-16 12:51:15 UTC
"alg" committed SVN revision 1503696 into trunk:
i122758 Initialize Mask with non-transparent
Comment 6 SVN Robot 2013-07-16 12:55:39 UTC
"alg" committed SVN revision 1503698 into branches/AOO400:
i122758 integrated fix from trunk
Comment 7 jsc 2013-07-16 13:02:32 UTC
granted showstopper flag, fix available
Comment 8 Armin Le Grand 2013-07-16 13:11:19 UTC
ALG: Is system-specific, on win mask-bitmaps with depth 1 get initialized, and on mac these are not even used. One more remark: The initial bitmap to start with had to be one *without* alpha channel; with alpha-channel this error would not have happened since adding a default one would not have been necessary.
Comment 9 rgb 2013-07-18 01:15:07 UTC

AOO400m3(Build:9702)  -  Rev. 1503704
2013-07-11 12:55:09 (Thu, 11 Jul 2013) - Linux x86_64

downloaded from here:

problem is NOT fixed. Picture gets quickly corrupted. Do I need to reopen the issue or the fix was not merged on this review?
Comment 10 rgb 2013-07-18 01:22:47 UTC
Ignore last comment. I did not realize that previous RC was still on memory when I installed the new one, so I get an hybrid monster that did not work.

I confirm that on 

AOO400m3(Build:9702)  -  Rev. 1503704
2013-07-16 14:49:37 (Tue, 16 Jul 2013) - Linux x86_64

the fix is working. 

Sorry for the noise.
Comment 11 Ariel Constenla-Haile 2013-07-18 01:46:53 UTC
Created attachment 81098 [details]
3.4.1 - 4.0.0 comparison

As a follow up of this, the same rotated image looks better in 3.4.1 than in 4.0.0
By better I mean that the image borders on 3.4.1 are more straight lines; and the image has more "pixelation" in 4.0.0 (compare Juliette Binoche's nose, and also the blue glass pearl mobile)
Comment 12 jsc 2013-07-18 07:57:28 UTC
I have tested the new Linux RC from Ariel on Ubuntu and the described problem is fixed. But I agree that there is a regression with the border but that is a new issue from my perspective and should be fixed in the next version.

In your comparison have you rotate the images exactly by the same degree? Andre mentioned that a slightly difference can result in a minor different viewing.

Armin or Andre can tell us more ...
Comment 13 Armin Le Grand 2013-07-18 09:20:52 UTC
ALG: Yes, a new task will be fine. The fallback has options for smoothing, but these seem not to be activated. Anyways, a better sys-level support for transformed bitmaps (as for Win and Mac, in vcl) would make this fallback, hand-transformed bitmaps obsolete...
Wrote but 122778 for it.