Created attachment 124298 [details] screenshot png Ubuntu 14.04 amd64 LO 5.1.2.2 Build ID 1.5.1.2~rc2-0ubuntu1~trusty0 locale fr-FR (fr_FR.UTF-8) Open an image in Draw. Crop it. Compress it (200dpi bicubic jpeg) → image gets randomly stretched Workaround : Open image → compress it → then crop it → it displays right. Workaround was not needed in previous version(s).
Please attach test file. Workaround was not needed in previous version(s). - which version? Thanks
Created attachment 124305 [details] test_file
Workaround was not needed in previous version(s). - which version? 4.1 branch
Hello all, I confirm this bug. I'm using Libreoffice x86_64 for Windows. I confirm it affects both Draw and Writer. I tested earlier versions, and this bug seems to have been introduced in version 5.1.2, as version 5.1.1.3 isn't affected. How to reproduce (using version 5.1.2.2): - In writer or draw, insert an image in the document - crop the image - compress the image (I tested compressing to 300 dpi, everithing else as default) ==> bug I'm going back to version 5.1.1.3, as I use this feature a lot. Best regards, Fábio Melo Pfeifer
NEW per comment 4.
That problem also occurs in Ubuntu 16.04 Version: 5.1.2.2 Build ID: 1:5.1.2-0ubuntu1 Threads CPU : 8; Version de l'OS :Linux 4.4; UI Render : par défaut; Locale : fr-FR (fr_FR.UTF-8)
Bug still present in 5.1.3.2 Ubuntu 14.04 and 16.04
Works here, meaning the lower image is not distorted after compression with a resolution of 200 or 96 and bicubic interpolation. Version: 5.1.3.2 Build ID: 5.1.3.2 Arch Linux build-1 CPU Threads: 8; OS Version: Linux 4.5; UI Render: default; Locale: de-DE (de_DE.UTF8)
Heiko, had you cropped your image BEFORE compress it ? If only compress, no problem. If crop THEN compress, image is stretched or even disappear !
(In reply to Gérald Maruccia from comment #9) > Heiko, had you cropped your image BEFORE compress it ? That did the trick. When I compress the cropped image it disappears (white out, handles remain). /confirmed
Still not fixed in version: 5.1.4.2 Build ID: 1:5.1.4-0ubuntu1~trusty1 Threads CPU : 4; Version de l'OS :Linux 3.16; UI Render : par défaut; Locale : fr-FR (fr_FR.UTF-8) If done AFTER cropping, « compress » stretches image…
Created attachment 125886 [details] compress after cropping → stretch image in 5.1.4.2
( no critic intended - just curious ) Why a thing that worked for so long gets suddenly broken ? ( and does not get fixed with new version yet being reported )
(In reply to Gérald Maruccia from comment #13) > ( no critic intended - just curious ) > > Why a thing that worked for so long gets suddenly broken ? Such a break is called a regression. We don't know the reason yet, because no one has bibisected it: https://wiki.documentfoundation.org/QA/Bibisect If you want to get involved in quality assurance and bug triaging, please join the #libreoffice-qa channel, say hello and stick around: https://wiki.documentfoundation.org/Website/IRC
same problem in Impress Version: 5.1.3.2 Build ID: 644e4637d1d8544fd9f56425bd6cec110e49301b CPU Threads: 4; OS Version: Linux 4.0; UI Render: default;
Problem still present in Version: 5.1.5.2 Build ID: 1:5.1.5~rc2-0ubuntu1~xenial1
Is bibisection really needed as we already when the bug was introduced : « Hello all, I confirm this bug. I'm using Libreoffice x86_64 for Windows. I confirm it affects both Draw and Writer. I tested earlier versions, and this bug seems to have been introduced in version 5.1.2, as version 5.1.1.3 isn't affected. How to reproduce (using version 5.1.2.2): - In writer or draw, insert an image in the document - crop the image - compress the image (I tested compressing to 300 dpi, everithing else as default) ==> bug I'm going back to version 5.1.1.3, as I use this feature a lot. Best regards, Fábio Melo Pfeifer » from some comments above ?
Crop-then-compress bug is still present in Version: 5.2.0.4 Build ID: 1:5.2.0~rc4-0ubuntu1~trusty1
(In reply to Gérald Maruccia from comment #17) > Is bibisection really needed as we already when the bug was introduced Yes. While "between 5.1.1.3 and 5.1.2.2" is a start, bibisection is more granular and thus helps.
(In reply to Björn Michaelsen from comment #19) > (In reply to Gérald Maruccia from comment #17) > > Is bibisection really needed as we already when the bug was introduced > > Yes. While "between 5.1.1.3 and 5.1.2.2" is a start, bibisection is more > granular and thus helps. Mmm yes quite logical. I was wondering because reading documentation did not help me understand how to help LOteam about that bug… Is there a tool to download - as the one Mozilla provides for bibisecting Firefox ? That may seem a minor bug - but when using those crop & compress features dozen times daily at work, it is a big pain in the … workflow.
(In reply to Gérald Maruccia from comment #20) > Mmm yes quite logical. I was wondering because reading documentation did not > help me understand how to help LOteam about that bug… Is there a tool to > download - as the one Mozilla provides for bibisecting Firefox ? There is no tool other than the git version control system: https://wiki.documentfoundation.org/QA/Bibisect
Version: 5.2.0.4 Build ID: 1:5.2.0~rc4-0ubuntu1~trusty2 …bug still there
@raal, @xisco: Can we get this bibisected?
Is this bug still present in 5.2.1(rc2) ?
(In reply to Heiko Tietze from comment #10) > (In reply to Gérald Maruccia from comment #9) > > Heiko, had you cropped your image BEFORE compress it ? > > That did the trick. When I compress the cropped image it disappears (white > out, handles remain). I get the same thing, but I do not understand what does mean compressing an image with a resolution larger than the resolution of the original image. When compressing an image, what image has to be compressed, the image stored in the document or the part of the image which is visible ? In the case of a cropped image, to which image the image data given in the compression dialog is applicable? to the visible part or to the whole image? Best regards. JBF
Resolution of the image is relative to its size in final document. If original image is 7Mo and 300dpi for a 10x15cm size if I reduced its size to 5x7,5cm it becomes 600dpi resolution and still weights 7Mo. If I don't need that 600dpi in the final document because printing quality is enough with 300dpi, compress is the answer and allows to keep resolution at 300dpi and therefore reduces « weight » < 1Mo. I understand why it's not a default behavior because one has to deal again with the properties of that image in the document. But in case you work daily on the same template document compress is very useful for final production. And moreover this used to work like a charm ;-)
We need dev input to move this forward. @caolan, @meeks, @maxim: Any thoughts?
Problem still there in Ubuntu 16.10 Version: 5.2.2.2 Build ID: 1:5.2.2-0ubuntu1 Threads CPU : 8; Version de l'OS :Linux 4.8; UI Render : par défaut; Locale : fr-FR (fr_FR.UTF-8); Calc: group
(In reply to Yousuf Philips (jay) from comment #23) > @raal, @xisco: Can we get this bibisected? This seems to have begun at the below commit. Adding Cc: to Chris Sherlock; Could you possibly take a look at this one? Thanks 088891b7b6c325ed3dbca34db651af30c3b6529a is the first bad commit commit 088891b7b6c325ed3dbca34db651af30c3b6529a Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Thu Feb 18 00:01:21 2016 -0800 author Chris Sherlock <chris.sherlock79@gmail.com> 2016-02-13 05:08:01 (GMT) committer Tomaž Vajngerl <quikee@gmail.com> 2016-02-14 20:51:08 (GMT) commit f8355221ae62b89a706f2d04b63eda658f3ccfa5 (patch) tree 6a01919926776dc5c36ffb825dc69b46ba66fbac parent 19fb09dce67d29d480ff39c538209b887f661dc9 (diff) tdf#85761 vcl: JPEG export does not save PPI values correctly source f8355221ae62b89a706f2d04b63eda658f3ccfa5 git bisect log # bad: [6380ca07b05f68dedcaa379302cfe1fa478571c4] source 60b74fe1775e647545d2da1fcc58a4c63ec18aa5 # good: [1f670510f08cb800cbae2a1dd6ea70d3542e4721] source 49c2b9808df8a6b197dec666dfc0cda6321a4306 git bisect start 'origin/master' 'oldest' # bad: [38f37b8ec1a2d199bb957cfd2581df7d1b273b74] source c0da1080b61a1d51654fc34fdaeba373226065ff git bisect bad 38f37b8ec1a2d199bb957cfd2581df7d1b273b74 # good: [6998931a34ad75eb555f882fbed223e585548721] source 1fbd073828ef52f5206aed4643226bae9fb85f4f git bisect good 6998931a34ad75eb555f882fbed223e585548721 # good: [b283fbadb387862ea0f09058430317906e1a78b5] source 1fc4cb57755cdfb9ab65c112435997874fb057cd git bisect good b283fbadb387862ea0f09058430317906e1a78b5 # bad: [06c6e9147b4de27ea6a67a02a7b14b24a93fea29] source 0f8f733eaf54c00f79d086c2b2867c7a8b1bcc6c git bisect bad 06c6e9147b4de27ea6a67a02a7b14b24a93fea29 # good: [742f38455777a16ab4580f75b1768d786033b3b3] source 3ff9dd6ff36f21d9bea1851cea05a4ed4228722d git bisect good 742f38455777a16ab4580f75b1768d786033b3b3 # good: [04eda0bcbbf8a58ee9d13136627b693bd8c9c426] source 2edd7bed44f1e2d67238a383ac3338e7c7da5086 git bisect good 04eda0bcbbf8a58ee9d13136627b693bd8c9c426 # bad: [4d7acb106348a95ba749c72df7e65da242ba3259] source d3f83ffa0e85a697af2cbf50a55dd7308609cf56 git bisect bad 4d7acb106348a95ba749c72df7e65da242ba3259 # bad: [7f086f6923dd4add0e9952a0be5aa3d1528e437b] source 0c423808961d9f4fed673e83e559d7a178400810 git bisect bad 7f086f6923dd4add0e9952a0be5aa3d1528e437b # bad: [6f5a4a9170ccef677f42b3f279f6bd6eeb46d1ce] source 1ef5733c155df0151f78f226797af5e26b7b1513 git bisect bad 6f5a4a9170ccef677f42b3f279f6bd6eeb46d1ce # good: [1a1ec1e0c88c83c03384af490318fa00b2c35585] source 654f6ff28d7a148950b48ed8905d8f13a015a5b5 git bisect good 1a1ec1e0c88c83c03384af490318fa00b2c35585 # good: [1555f3076599d867708d2d697d7c5fb4295cdb90] source b7c807faeb18a87dc8ad5bc1ae68ca5cb3999a66 git bisect good 1555f3076599d867708d2d697d7c5fb4295cdb90 # good: [2dfba22f622cb4671fbcdd716e11553966479762] source 19fb09dce67d29d480ff39c538209b887f661dc9 git bisect good 2dfba22f622cb4671fbcdd716e11553966479762 # bad: [088891b7b6c325ed3dbca34db651af30c3b6529a] source f8355221ae62b89a706f2d04b63eda658f3ccfa5 git bisect bad 088891b7b6c325ed3dbca34db651af30c3b6529a # first bad commit: [088891b7b6c325ed3dbca34db651af30c3b6529a] source f8355221ae62b89a706f2d04b63eda658f3ccfa5
(In reply to Gérald Maruccia from comment #13) > Why a thing that worked for so long gets suddenly broken ? Also an additional reason - there is no automatic test to check for this scenario yet. So when we change something we test it "by hand", but this doesn't check all corner cases or other scenarios that could be affected by the change (like in this case). An automatic test would solve this as the build would fail because the test would fail and we would need to fix this right away. Let's see if we can get a test for this in..
Thanks you all for explanations, and time. Glad to see that problem will get a fix sooner or later ;-) If I may do anything to help let me know ?
Hello, This regression was introduced by the same commit as in bug 99286, thus setting this one as RESOLVED DUPLICATED. *** This bug has been marked as a duplicate of bug 99286 ***