The image size will decrease after using the compression feature
Steps to Reproduce:
1. Open the attached file
2. Right click the image and select Original size (image increases in size)
3. Right click the image and select compress
4. Press OK
5. Right click the image and select Original size -> quite a small image
Image should keep the original dimensions
User Profile Reset: No
Build ID: 8672113ead4e403c55e31b1d9a3d1e0f3b299577
CPU-threads: 4; Besturingssysteem:Windows 6.2; UI-render: standaard;
Locale: nl-NL (nl_NL); Calc: CL
but not in
Build ID: e8938fd3328e95dcf59dd64e7facd2c7d67c704d
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
Created attachment 133430 [details]
Telesto: What kind of compression do you use? Which settings do you have made in the dialog?
The embedded image has no dpi information, therefore there exist no "original size" because the size of the pixels is unknown. If you click on "Original size" in step 2, LibreOffice uses an ersatz, likely your screen resolution. Calculate the dpi and use the same dpi in the compression dialog.
I have used:
1. JPG Quality 90: Reduced image resolution checked set to width 400px, height 529 px and resolution 96 PPI (screen dimensions 10,58x14.00 cm)
2. JPG Quality 90 without reduced image resolution checked
both with same result; a very small image with an apparent dimensions of 0,40 cm x 0,53 cm at 2500 PPI
No issues with the png compression
Apparently LO sets 1px = 1/100 mm. For me LO chooses for the original png-image a size of 8,47cm × 11,22 cm at 120ppi for its 400 pixel × 530 pixel size.
Expected behavior for the jpg image:
the same same ersatz value is used for the jpg image and dialog fields are disabled
the dpi value or width or height respectively, which the user sets in the dialog, is used.
I see this error already in Version: 220.127.116.11
Build ID: f3e25ec0581f5012f54d8810dcddd5824f4ee374
CPU Threads: 4; OS Version: Windows 6.1; UI Render: default;
Locale: de-DE (de_DE); Calc: group
The image has no dpi set, and uses the same default as the ersatz as the png image and so shows the same size in Version: 18.104.22.168.alpha0+
Build ID: 40b1e8266e47792d354cd457c652bfb0f0a21e69
TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2015-02-11_00:13:43
Build ID: e9fbe1f7cd28de2a9da8089d89e903406165eb56
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-04-25_00:22:55
sets 96dpi although it is 120dpi for me and I set that is the dialog too.
The fixed for bug 65695 and bug 85761 are likely related.
Would a bibisect be helpful?
** Please read this message in its entirety before responding **
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/
2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword
Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!
(The following is my very naive understanding after 3 days of playing with graphics - but seems to me like NOTABUG.)
I don't expect original size would be from "before a compression". It would be a comparison of the compressed "filesize" with the "display size", wouldn't it? Since the display size can stretch or shrink the actual view size, it is good to know the actual dimensions - particularly for cropping values which are calculations from the original size (if I understand correctly).
Created attachment 160192 [details]
1. Open the attached file
2. Open the compress Image dialog
- Actual dimensions 16,93 x 12,70 cm (nothing 'actual'. It's based on my screen)
- The apparent dimensions: 16,93 cm c 12,70 ad 95 DPI (dimension suggest 96 dpi)
3. Reduce image resolution: default settings 2001 width x 1500 Height 300 dpi Lanczos. Jpg compression
4. Press Ok
5. Open the compress dialog again
- Actual dimensions 52,94 cm x 39,69 cm (2001 x 1500px)
- Apparent dimensions: 16,93 x 12,70 cm at 300 dpi
8. Format -> Image -> Properties -> Type Tab
9. Press Original size button (21,00 cm Height x 29,70) -> so limited page size, A4
So lacking DPI setting in file, it's based on screen DPI. However different monitors different DPI settings/image sizes. Corel Paint Shop Pro uses a 'default' settings at 200 DPI for images lacking a resolution. Instead of using the screen resolution as reference.
The different between actual dimensions (suggesting 'real measure') and apparent dimensions quite confusing at minimum. Also what's meant with "apparent" dimensions open for debate, IMHO. Increase the size of the image and the apparent dimensions change (of course) + DPI will be lower. Recompress the image with "Reduce image resolution" at default settings and you have an image of 300 DPI with the same dimensions.
Always using the apparent resolution would solve a part of the problem. Except I'm not sure what happens on a high DPI screen.. Is there a difference on screen (Writer/Calc/Draw) between the size of the image on 96 dpi and 120 dpi screen?
Another solution would be some random - not screen based setting - at say 200dpi (and an option to change it in Expert configuration), if no resolution is set.
The "actual dimensions" are used the Image Properties Type tab (original size button) as the "original size' which is misleading at minimum.