Issue 104146 - image corruption on save : unexpected modification of its original size
Summary: image corruption on save : unexpected modification of its original size
Alias: None
Product: Impress
Classification: Application
Component: save-export (show other issues)
Version: OOO310m18
Hardware: PC All
: P3 Trivial (vote)
Target Milestone: OOo 3.1.1
Assignee: wolframgarten
QA Contact: issues@graphics
Depends on:
Blocks: 101565
  Show dependency tree
Reported: 2009-08-11 09:38 UTC by jbf.faure
Modified: 2010-06-07 11:49 UTC (History)
6 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

bugdoc reworked from generic_fr.sxi TCM testfile (302.77 KB, application/vnd.oasis.opendocument.presentation)
2009-08-11 09:40 UTC, jbf.faure
no flags Details
new bugdoc with different images (73.57 KB, application/vnd.oasis.opendocument.presentation)
2009-08-11 12:32 UTC, jbf.faure
no flags Details
A fix (2.26 KB, patch)
2009-08-14 15:08 UTC, thb
no flags Details | Diff
proposed simpler fix (607 bytes, text/plain)
2009-08-14 16:40 UTC, Armin Le Grand
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description jbf.faure 2009-08-11 09:38:53 UTC
OOo 3.1.1 RC1 FR under Ubuntu 8.04.
During tests on issue 103896, I found a surprising defect:
- open attached bugdoc generic_fr.odp
- check the original size of the image on first slide : 10.16 x 4.44 cm
- go to the 2nd slide and slightly modify the size of animated image with the
blue ball.
- without moving from this slide, save the file under another name and reload it.
- go back to the first slide : the image is became fuzzy
- select this image > right click > original size => it is smaller ! (2.54 x
1.12 cm)

I you save the file when the first slide is shown, the image is not corrupted.
The bug has been reproduced under Ubuntu, XP and MacOS
The bug occurs also with DEV300_m54 (tested only under ubuntu for this version)

Comment 1 jbf.faure 2009-08-11 09:40:11 UTC
Created attachment 64063 [details]
bugdoc reworked from generic_fr.sxi TCM testfile
Comment 2 wolframgarten 2009-08-11 10:48:04 UTC
Reproducible. Reassigned.
Comment 3 jbf.faure 2009-08-11 11:16:08 UTC
If you save on the same file, the bug results in a data loss, you can't restore
the quality of the image. So, it is a stopper for OOo 3.1.1 ?

Kind regards
Comment 4 wolframgarten 2009-08-11 11:35:55 UTC
If this happens for every graphic in every file this would be a showstopper. If
this happens only with the graphic in this testfile I would not see it as a stopper.
Comment 5 jbf.faure 2009-08-11 12:31:32 UTC
Ok, I understand. Please try the following attachment.

Kind regards
Comment 6 jbf.faure 2009-08-11 12:32:44 UTC
Created attachment 64065 [details]
new bugdoc with different images
Comment 7 uwe.luebbers 2009-08-11 15:05:18 UTC
How many issues do we have for this problem?
It sounds to me like issue 103896, this issue was rejected as a stopper by the
status meeting. This issue has target 3.2 as decided by the meeting. Please see the
protocol and the logfile.
Comment 8 uwe.luebbers 2009-08-11 15:12:12 UTC
OK, after readíng the issue a second time I see the difference. 
Now I understand, sorry.
Comment 9 thb 2009-08-14 15:08:07 UTC
Created attachment 64164 [details]
A fix
Comment 10 thb 2009-08-14 15:17:58 UTC
So - attached patch fixes the bug, with the drawback that on save, all pics that
only have a preview set will need to get reloaded. A somewhat smarter fix would
cache the unique ID for the original graphic, but I figured that's a bit too
involved for a 3.1.1 showstopper fix - which I would *strongly* recommend this for.

Background: if a graphic has only its preview loaded (does not happen for all
graphics, you need jpeg or png (with appropriate interleaving)), and someone
requests a save, then those SdrGrafObjs will return the *wrong* graphic ID
(namely, the one from the preview graphic - note that
SdrGrafObj::GetGraphicObject() does *not* force the original graphic to be
swapped-in, when called from unoshap2.cxx). This reportedly has (obviously
depending on swap state) killed whole documents, so I would not want a 3.1.1
with this bug in ...
Comment 11 thb 2009-08-14 15:20:07 UTC
Sorry for not being clear enough - what happens here is that OOo saves *the
preview graphic*, e.g. a 64x64-or-somesuch resolution version of *all* affected
images, instead of the original one.
Comment 12 Armin Le Grand 2009-08-14 16:38:52 UTC
AW: Was in 3.1, too, but was covered by another error that primitives always
forced swa-in. This was fixed for 3.1.1 and triggered this error.
The fix looks good, but is unnecessarily complex for a 3.1.1 fix. It's
sufficient to add a true as parameter to the GetGraphicObject() call in
unoshap2.cxx. GetGraphicObject IS prepared to force a swap-in already. I will
add the change as patch, too.
Comment 13 Armin Le Grand 2009-08-14 16:40:10 UTC
Created attachment 64167 [details]
proposed simpler fix
Comment 14 Armin Le Grand 2009-08-14 17:15:51 UTC
AW: BTW: From my POV it is a bad design decision to have implemented the preview
image to be hold in the same GraphicObject as member of SdrGrafObj as the
original image. Maybe a redesign should be considered to add a 2nd GraphicObject
called PreviewImage and using it in dedicated situations only. Just my 2 cents...
Comment 15 clippka 2009-08-17 15:29:45 UTC
thanks aw, a good fix to solve the issue at hand. I have created a cws swapfix01
on OOO310 and I urgently vote that this becomes a show stopper.
Comment 16 clippka 2009-08-18 09:30:13 UTC
fixed in cws spawfix01
Comment 17 clippka 2009-08-18 09:30:46 UTC
verified in cws, back to qa
Comment 18 wolframgarten 2009-08-18 09:52:24 UTC
Verified in CWS.
Comment 19 thorsten.ziehm 2010-06-07 11:49:12 UTC
This issue is closed automatically. It is in state 'verified/fixed' since 2
releases (OOo 3.1.1 and OOo 3.2). The policy [1] indicates that such older
issues should be closed.

If this issue still occur in a current build (OOo 3.2.1 or >DEV300m80) please
reopen the issue and set the target accordingly.

[1] :