Bug 122257 - LO Impress: Estimated and final sizes differ in Presentation minimizer
Summary: LO Impress: Estimated and final sizes differ in Presentation minimizer
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
6.2.0.0.beta1+
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: ImpressDraw-Enhancements
  Show dependency tree / graph
 
Reported: 2018-12-21 13:03 UTC by Vera Blagoveschenskaya
Modified: 2021-06-14 09:54 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:

Attachments
screen (179.73 KB, image/png)
2018-12-21 13:05 UTC, Vera Blagoveschenskaya 		Details
presentation to test (16.02 MB, application/vnd.openxmlformats-officedocument.presentationml.presentation)
2018-12-21 13:58 UTC, Vera Blagoveschenskaya 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Vera Blagoveschenskaya 2018-12-21 13:03:29 UTC 
Description:
Estimated and final size differ in Presentation minimizer

Steps to Reproduce:
1. Open some presentation via LO Impress
2. Tools -> Minimize presentation
3. Go through the wizard to the last page. Look at the size estimated
In my case size will be reduced from 16.0 Mb to 8.3 Mb
4. Perform minimization physically
5. Look at the size in the final message

Actual Results:
Final size differs from estimated size (see screenshot)

Expected Results:
The same sizes


Reproducible: Always


User Profile Reset: No



Additional Info:
Reproduced for 

Version: 6.2.0.1
Build ID: 0412ee99e862f384c1106d0841a950c4cfaa9df1
CPU threads: 1; OS: Linux 4.14; UI render: default; VCL: kde5; 
Locale: ru-RU (ru_RU.UTF-8); UI-Language: en-US
Calc: threaded

Version: 6.2.0.1
Build ID: 0412ee99e862f384c1106d0841a950c4cfaa9df1
CPU threads: 1; OS: Linux 4.14; UI render: default; VCL: gtk3; 
Locale: ru-RU (ru_RU.UTF-8); UI-Language: en-US
Calc: threaded
Comment 1 Vera Blagoveschenskaya 2018-12-21 13:05:55 UTC 
Created attachment 147741 [details]
screen
Comment 2 Vera Blagoveschenskaya 2018-12-21 13:58:48 UTC 
Created attachment 147744 [details]
presentation to test
Comment 3 Durgapriyanka 2018-12-21 20:38:17 UTC 
Thank you for reporting the bug. I can confirm that the bug is present in

Version: 6.3.0.0.alpha0+
Build ID: 3c964980da07892a02d5ac721d80558c459532d0
CPU threads: 2; OS: Windows 6.1; UI render: default; VCL: win; 
TinderBox: Win-x86@42, Branch:master, Time: 2018-12-12_02:07:45
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded
Comment 4 Thorsten Behrens (allotropia) 2018-12-22 14:20:40 UTC 
Unclear if that is doable - Cc Vasily who was looking into that code recently.

Especially for images, relationship between compression paramaters and actual file size can be rather complex.
Comment 5 Vasily Melenchuk (CIB) 2018-12-22 16:11:10 UTC 
Current implementation (see https://opengrok.libreoffice.org/xref/core/sdext/source/minimizer/optimizerdialogcontrols.cxx#791-806) is making very rough calculation based only on desired JPG compression and resolution. This approach gives very rough estimation even for JPEG images, but here are many factors not taken into account, like removing hidden slides, cropping images, etc.

Theoretically, I see no limitations to provide more precise filesize estimation.