Bug 143635 - Ambiguous meaning of 'Original size' in Image Properties type tab
Summary: Ambiguous meaning of 'Original size' in Image Properties type tab
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsDevEval
Depends on:
Blocks: Images
  Show dependency treegraph
 
Reported: 2021-07-31 08:45 UTC by Telesto
Modified: 2024-03-16 16:58 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
Screencast (750.84 KB, video/mp4)
2022-01-18 08:38 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2021-07-31 08:45:31 UTC
Description:
Ambiguous meaning of 'Original size' in Image Properties type tab 

Steps to Reproduce:
1. Open attachment 173985 [details]
2. Select the image & Press F4
3. type Tab
4. Check keep ratio
5. Width: Relative to (Paragraph Area)
6. Press OK
7. with image selected, press F4
8. Uncheck relative
9. Notice an unwanted size change
10. Press original size 13,47 cm x 20,05.. Kind of expected: 5,54 cm x 8,25 cm (or something in that direction)

Actual Results:
13,47 cm x 20,05 (so the embedded image dimensions)

Expected Results:
Dimensions equaling what's present on screen before the changes (so kind of 'reset' but different)


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 2a151d1d5bc055d5e0011460b6ec42ea9f34f880
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL
Comment 1 Diana 2021-08-02 15:20:49 UTC
confirm in 

Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: ac80ec817eb07c77a51bc0729985a473c734182e
CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win
Locale: ru-RU (ru_RU); UI: en-US
Calc: CL
Comment 2 Heiko Tietze 2021-08-09 13:37:27 UTC
Don't understand you expectation, maybe due to the steps. "Relative to" turns the 5.54cm into 33% - do you think "Original" should revert it to 100%?
Comment 3 Telesto 2022-01-18 08:38:07 UTC
Created attachment 177627 [details]
Screencast
Comment 4 Telesto 2022-01-18 09:12:51 UTC
(In reply to Heiko Tietze from comment #2)
> Don't understand you expectation, maybe due to the steps. "Relative to"
> turns the 5.54cm into 33% - do you think "Original" should revert it to 100%?

Well obviously this bug report is a mixture of issues. Relative increasing size (as it has no decimal value). Unchecking relative breaking ratio in a whole..

So you want to go back.. before you made any change (so pressed OK).. yes, you have UNDO. But well sometimes you take the wrong turn and ask yourself well what happened here.. And start with the dialog (and before you know.. you are fighting the dialog)

So at some point you want the size back, and you press "original size" prior to those relative changes.. which break Aspect Ratio (and those things I do forget).. And you again get something unexpected in the given context

What 'original size' isn't that clear. 
* Original size of Image without DPI is screen DPI and number of pixels. 
* And image with DPI will choose original size based on embedded DPI. 
* Or in my case, in wanted original size to be the size before relative change.

Anyhow I get the 'original size' button in Crop tab (which defines what you get ). But it's more mystery box in Type tab.

I think that 'Original size' surely being bad label :-). Size multi-interpretable (dimensions or file size?).

Original; original from what? And why is it the 'original' dimensions. And image without DPI embedded doesn't have 'original dimensions'. It's attributed some dimensions.

And if an image inserted being bigger compared to Writer page size, it will automatically shrink the image to fit on page.. Which can be seen as "the original size" (as inserted in document). But maybe the image original size is 50x100cm; dimensions calculated fallback screen DPI (in case of a high res image without embedded DPI) 

Some genetic label, might be better. Something like Default Dimensions. It feels as surprise button in advance :-), being cryptic enough to not entail much of expectation.. And can't disappoint. 

List of certain options: 
Default dimensions
Restore dimensions
Initial dimensions
Embedded image dimensions
Default image dimensions
Restore image dimensions
Comment 5 Heiko Tietze 2022-01-20 09:38:48 UTC
(In reply to Telesto from comment #4)
> What 'original size' isn't that clear. 
> * Original size of Image without DPI is screen DPI and number of pixels. 
> * And image with DPI will choose original size based on embedded DPI. 
> * Or in my case, in wanted original size to be the size before relative
> change.

From the UX/my POV it's the first option. You don't revert the last size modification but all. Switching from absolute to relative and back shouldn't affect the image size (likely filed in another ticket). And with "Keep ratio" I expect the other value to follow changes at the first whether absolute or relative.
Comment 6 Telesto 2022-01-20 10:46:09 UTC
(In reply to Heiko Tietze from comment #5)
> (In reply to Telesto from comment #4)
> > What 'original size' isn't that clear. 
> > * Original size of Image without DPI is screen DPI and number of pixels. 
> > * And image with DPI will choose original size based on embedded DPI. 
> > * Or in my case, in wanted original size to be the size before relative
> > change.
> 
> From the UX/my POV it's the first option. You don't revert the last size
> modification but all. Switching from absolute to relative and back shouldn't
> affect the image size (likely filed in another ticket). And with "Keep
> ratio" I expect the other value to follow changes at the first whether
> absolute or relative.

1) I'm not really able to match NEW with you're remarks.. Which part did you exactly confirm?

2) Slightly out of scope of my initial report. 

Level 1 Initial size
The dimensions of an image will be calculated based on available pixels & DPI.
If DPI is embedded in the file embedded DPI will be used to calculate dimensions. If not available the fallback will be screen DPI (didn't if there was some change here, Tomaz was working on something).

'original size' means is to me dimensions embedded in file. A fallback size because lack of DPI is 'some size'. You can technically say: it's the original size at import time for LibreOffice. But to it's an arbitrary size from user perspective with 'advanced level' of knowledge.

Level 2 Correction
If the image dimensions calculated at 'level 1' exceed page margins it will be downsized to fit within margins regardless of the original dimensions (for Writer; didn't check the rest)

If you press original size it will restore the 'level 1' dimensions. Which isn't by definition the size at insertion time (as it shrinks to page margins) which can be perceived as 'original size' from user perspective. 

Which is yet again one of ambiguity's of 'original size' And produces often a non-functional result (image of 50x30 on A4 paper).
Original size works (only) perfectly for for image who fit within page margins anyhow..

Another issue being that 'original size' being less useful
* where DPI isn't embedded in file (pretty common)
* A DPI being embedded, but far to low (have seen this couple of times)

I personally prefer a smaller image by dimensions (not file size) with high DPI instead of hug image with low DPI

Point being: I still not totally grasp what 'original size' exactly attempting to do. In my perception it only works out in say 50% of the cases. 

I also struggle with the label - aside from functionality part. It's more default/initial dimensions. 

-------------------
Off topic

Being able to define image size on 'crop tab' (called scale) and "type tab" also not great (but well that's Bug 132853)

And I would love some feedback of consequences of manual defined dimensions for DPI (on the type tab). So increase of dimensions lowering the DPI. And decrease of dimensions increasing DPI. When resizing an image mostly to take DPI account (to prevent crappy quality). Another interesting option would be defining size by DPI.

Dialog space isn't the issue. If it exceeds the limits of what a Word processor should be able to do, well.. I would take usefulness as benchmark; I think it's useful (but well I'm not the general public)
Comment 7 Heiko Tietze 2022-01-21 08:03:26 UTC
(In reply to Telesto from comment #6)
> 1) I'm not really able to match NEW with you're remarks.. Which part did you
> exactly confirm?

The fact that you don't get back to the initial values.
Comment 8 QA Administrators 2024-01-22 03:11:57 UTC Comment hidden (obsolete)
Comment 9 wjsim 2024-03-16 16:58:00 UTC
Repro in:

Version: 24.2.1.2 (X86_64) / LibreOffice Community
Build ID: db4def46b0453cc22e2d0305797cf981b68ef5ac
CPU threads: 16; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded


Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 6a064b1967e06e40be40817deff99d00c1a8554f
CPU threads: 16; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded