Bug Hunting Session
Bug 115464 - UI of export to PNG and JPG misleading for resolution
Summary: UI of export to PNG and JPG misleading for resolution
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
5.3.6.1 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: difficultyInteresting, easyHack, skillCpp
: 119149 119684 (view as bug list)
Depends on:
Blocks: Draw-Images Graphics-Export Image-DPI
  Show dependency treegraph
 
Reported: 2018-02-05 13:45 UTC by Heiko Tietze
Modified: 2019-09-23 08:28 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments
Mockup for the dialog (32.32 KB, image/png)
2018-06-08 09:05 UTC, Heiko Tietze
Details
Export as an image in Karbon (32.46 KB, image/png)
2018-06-08 17:41 UTC, Tomaz Vajngerl
Details
Mockup for the dialog (32.07 KB, image/png)
2018-06-09 07:59 UTC, Heiko Tietze
Details
Mockup for the dialog (39.62 KB, image/png)
2018-06-12 05:58 UTC, Heiko Tietze
Details
presentation minimizer for resolution (55.07 KB, image/png)
2018-09-04 10:11 UTC, andreas_k
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Heiko Tietze 2018-02-05 13:45:47 UTC
The first step to export in a higher resolution is to change the resolution, which changes the width/heigh. For instance, an object with a width of 10cm becomes 1cm when the resolution is increased by 10x. But this dependency is not clear from the UI.

Second problem, deleting the number separator (dot or comma) for a high resolution starts an internal calculation of the expected output size that takes very long and fails silently in the end (0kb).
Comment 1 Heiko Tietze 2018-02-05 14:27:52 UTC
The user expects to define the width of the output sometimes in cm but most often as pixel. As a second step he or she wants to fine-tune the resolution (dpi). But changing the pixels per inch when the width is defined in inches makes not much sense resp. would change the image width.

Proposed solution: We add a third input and show width, number of pixels, and resolution with the option to manipulate every value resulting in an update of the depending fields. The three options get radio buttons that define what of the three options is fix as we have it for RGB/CMYK/HSV in the color picker. Alternatively, we add a 4. control like a dropdown that defines what of the three controls is sticky. The resulting workflow in both cases is that I change on field resulting in an update of the second while the third is "sticky".
Comment 2 Heiko Tietze 2018-02-05 14:30:39 UTC
The issue was part of the discussion in bug 37678.
Comment 3 edera 2018-03-28 20:10:02 UTC
Confirmed:
draw and impress are vector drawing, so the expected behavior is to keep the physical size.
Increasing the resolution should increase the number of pixels.
Comment 4 Heiko Tietze 2018-06-08 09:05:34 UTC
Created attachment 142611 [details]
Mockup for the dialog

Hard to understand my own comments, but this mockup should make it clear. What kind of size (better terminology granted) is modified is selected per radio button including the third option of number of pixels. 

As cherry on top of the cake I moved the Mode/Drawing Object categories into an Options category together with the compression slider.
Comment 5 Tomaz Vajngerl 2018-06-08 11:00:54 UTC
- There is no need for radio buttons, it should be a play between 3 values where you can change any of those depending on what you want to know. In almost all cases users only care about pixels, but sometimes you want to know something like: "If I print with a 300 DPI printer and want a 12" image, what should the pixel dimension be".

- There is not drop down for pixels, that is the absolute value of the image, the only one that has the influence for the bitmap image (logical units and the ratio are a informative value only in bitmap images)

- Pixels should be top as they are most important value - pixel width and height 

- Maybe only have a switch between imperial/metric which changes both - resolution and the logical dimension unit

- Information is a lame guesstimate, almost always wrong currently. Who cares about the memory, the exact compression could be calculated instead (like in compress image dialog)
Comment 6 Heiko Tietze 2018-06-08 11:14:46 UTC
(In reply to Tomaz Vajngerl from comment #5)
> - There is no need for radio buttons

The RBs make it clear that values change depending on each other. That's the essence of this request.

> In almost all cases users only care about pixels

I never do and don't know users who think like "This drawing should have 87346832 pixels to fit nicely into my document with good printing output"

> - There is not drop down for pixels

Again, the idea of this ticket is it to make the mutual dependency between the three values clear. To be precisely, you can change two of the three parameters - but usability/simplicity wise I wouldn't do that.

> - Maybe only have a switch between imperial/metric which changes both -
> resolution and the logical dimension unit

You have a dropdown right now to select what unit you want to change - including pixels.
Comment 7 Tomaz Vajngerl 2018-06-08 17:41:37 UTC
Created attachment 142619 [details]
Export as an image in Karbon
Comment 8 Tomaz Vajngerl 2018-06-08 17:45:17 UTC
(In reply to Heiko Tietze from comment #6)
> The RBs make it clear that values change depending on each other. That's the
> essence of this request.

No, the RB's do exactly the opposite. The unselected mean they are irrelevant, disabled, which is exactly what they aren't. Noone does is like this - gimp, inkscape, krita, karbon.

> > In almost all cases users only care about pixels
> 
> I never do and don't know users who think like "This drawing should have
> 87346832 pixels to fit nicely into my document with good printing output"

We are dealing here with bitmap images - their pixel dimensions (width and height) is the most important information. The logical size and DPI is in best case included in the meta-data as a hint.

http://www.rideau-info.com/photos/mythdpi.html

Actually, looking at Karbon (see attachment 142619 [details]) - it has the ideal UI for that.  

Pixels first, then logical units and resolution.
Comment 9 edera 2018-06-08 22:54:38 UTC
(In reply to Tomaz Vajngerl from comment #5)
> - There is no need for radio buttons, it should be a play between 3 values
> where you can change any of those depending on what you want to know.

That's true, but it requires some experimenting to understand what is going on.

Radio buttons could be used to indicate what is kept fixed.
In this case, what is grayed out would be reversed with respect to Heiko proposition:

if size is "fixed", it is grayed out,
dpi can be changed, which automatically changes pixels
or
pixels can be changed, which automatically changes dpi

if dpi is "fixed", it is grayed out,
pixels can be changed, which automatically changes size
or
size can be changed, which automatically changes pixels


if pixels is "fixed", it is grayed out,
size can be changed, which automatically changes dpi
or
dpi can be changed, which automatically changes size

This would be clearer, IMO.

> In almost all cases users only care about pixels, but sometimes you want to
> know something like: "If I print with a 300 DPI printer and want a 12"
> image, what should the pixel dimension be".
> - There is not drop down for pixels, that is the absolute value of the
> image, the only one that has the influence for the bitmap image (logical
> units and the ratio are a informative value only in bitmap images)
> 
> - Pixels should be top as they are most important value - pixel width and
> height 
> 
> - Maybe only have a switch between imperial/metric which changes both -
> resolution and the logical dimension unit

As an example, for publications, the most common usage
is that we know the physical size that fits the column width,
and also know the dpi that the editor expects.
The number of pixels is really secondary.
Actually, for a vector graphics software, I would expect this to be the
most common usage during png export.


> - Information is a lame guesstimate, almost always wrong currently. Who
> cares about the memory, the exact compression could be calculated instead
> (like in compress image dialog)

Having an expected png file size information would be very helpful.
Comment 10 Heiko Tietze 2018-06-09 07:59:15 UTC
Created attachment 142621 [details]
Mockup for the dialog

Have to correct myself (the discussion with Regina and Armin was some time ago). Comment 9 describes what I have in mind. But actually there are always two parameters that can be modified at once, so the new mockup has a toggle button that locks one of the parameters, here number of pixels. Changing the dimension must result in a smaller resolution (that's how it works today). But what the user wants is a constant resolution and changing width/height ends up in more or less pixels.
Comment 11 edera 2018-06-09 08:24:46 UTC
(In reply to Heiko Tietze from comment #10)
> <...> the new mockup has a toggle
> button that locks one of the parameters, here number of pixels.

I like this lock toggle button, its action is very clear.

> <...>
> But what the user wants is a constant resolution and changing width/height
> ends up in more or less pixels.

Agreed; this should be the default case.
Adding a mockup for this case might be even more convincing ?
Comment 12 Tomaz Vajngerl 2018-06-10 16:55:25 UTC
First of - change the "number of pixels" (as you self admitted it is meaningless to the users) to pixel width and height as other programs do and users are used to. Number of pixels "clever" as number of pixels is, it is not what users have a feeling for (as you self admitted).

Locking seems superfluous to me. We just need to decide the order in the meaningful way. I would do it like this:
- change pixel width or height changes logical width and height
- change logical width or height changes pixel width and height
- change of resolution changes pixel width and height

This should work well for those people who want to just define the pixel dimensions and for those who wants to define a logical dimension and the resolution factor. 

I must again emphasize that pixel width and height is the only absolute parameter that defines the bitmap, logical dimensions or resolution is written to the bitmap as metadata (usually the resolution only) and will or will not be taken account when the bitmap is later used.

The problem with current dialog is that you have the possibility to set either the pixel dimensions or one of logical dimensions and separately the resolution. The misunderstanding for users occurred when because the change of resolution changed the logical dimension and change of logical dimensions changed the resolution. One problem was that this was not visible and the second problem was that this did not change the pixel dimensions, so users thought the change did not have any effect. Order I propose doesn't create this situations - locking can still do this.
Comment 13 Regina Henschel 2018-06-10 17:37:49 UTC
I disagree with Tomaz order. I want to export so, that the png has the same width and height as the original vector graphic object and I want to set the DPI according the purpose of the export. I do not care in how many pixels this settings result.

Using a "lock"-icon is a good idea to make clear, what can be changed and what not. That is better than the radio button in a previous mockup.

But I agree with Tomaz, that it would be better to have width and height for pixels, that is much better understandable. And for preventing to generate too huge images, the information part is sufficient.
Comment 14 Heiko Tietze 2018-06-11 06:46:49 UTC
(In reply to Regina Henschel from comment #13)
> But I agree with Tomaz, that it would be better to have width and height for
> pixels, that is much better understandable. And for preventing to generate
> too huge images, the information part is sufficient.

You had the idea with the third category resp. to show all dependencies at FOSDEM :-). 

Anyway, the user needs to know today at what input she starts to get the desired result. Changing dpi afterwards spoils the input (or vice versa). That needs to be fixed, and I'm the first to agree with simplification.
Comment 15 Regina Henschel 2018-06-11 10:23:47 UTC
(In reply to Heiko Tietze from comment #14)
> You had the idea with the third category resp. to show all dependencies at
> FOSDEM :-).

Yes, but showing the total pixels is useless for the user. If the user wants an image of 200px width, he surely do not want to calculate himself, how many pixel he needs for the height to keep ratio and to multiply width and height for to enter that value. So please change the mockup to have separate width and height fields in category 'Pixels'.
Comment 16 Heiko Tietze 2018-06-12 05:58:38 UTC
Created attachment 142672 [details]
Mockup for the dialog

(In reply to Regina Henschel from comment #15)
> So please change the mockup to have separate
> width and height fields in category 'Pixels'.

Different units are available right now via dropdown. If we remove the total numbers of pixels the dialog looks a bit overcomplicated; taking Tomaz comment into account that the dpi value is rather an advice we could drop the dependency and have just an input field, e.g. a combobox with common values 72,150,300..., that doesn't depend on the size.
Comment 17 Tomaz Vajngerl 2018-06-12 20:47:33 UTC
(In reply to Regina Henschel from comment #13)
> I disagree with Tomaz order. I want to export so, that the png has the same
> width and height as the original vector graphic object and I want to set the
> DPI according the purpose of the export. I do not care in how many pixels
> this settings result.

I can live with the different order. 

> Using a "lock"-icon is a good idea to make clear, what can be changed and
> what not. That is better than the radio button in a previous mockup.

I still don't understand why we need to "lock" something. All three parameters are changeable, they just depend on each other. Changing DPI that changes the logical width or height is essentially a no-op, which causes a lot of confusion now, so why allow it in the first place..
Comment 18 Tomaz Vajngerl 2018-06-12 21:16:34 UTC
(In reply to Heiko Tietze from comment #16)
> Different units are available right now via dropdown. 
No... pixels have a different meaning than logical units. We can't mix them together, or at least we need to show the final pixel dimensions (width and height) in the dialog all the time and somewhere near the (for example like Gimp does it when you create a new image).
Comment 19 Regina Henschel 2018-06-12 22:21:44 UTC
(In reply to Tomaz Vajngerl from comment #17)
> I still don't understand why we need to "lock" something. All three
> parameters are changeable, they just depend on each other.

There exists three situations:
Change widht/height length and change DPI => Pixels are calculated
Change width/height in pixels and change DPI => width/height length is calculated
Change width/height in pixels and change width/height length => DPI is calculated

So if the user changes e.g. width/height length, you cannot change DPI or pixels automatically, because there are two situations in which a length change are possible. Locking one of them makes it possible to calculate the other.

(In reply to Heiko Tietze from comment #16)
> Different units are available right now via dropdown.
You cannot offer pixel as length in this context. Because here 'pixel' do not mean a length unit, but reflects the number of color items. Only with the additional information of DPI you get a length from it. That is different from e.g. CSS.
Comment 20 Heiko Tietze 2018-06-13 07:48:12 UTC
(In reply to Tomaz Vajngerl from comment #18)
> No... pixels have a different meaning than logical units.

(In reply to Regina Henschel from comment #19)
> You cannot offer pixel as length in this context.

That's a very technical explanation and users likely do not understand the difference. The expectation is to export the image with 10cm/in or 1000px (don't think other units are used). 

To solve the issue we can make dpi an independent property or give better feedback what effect a modification has.
Comment 21 edera 2018-06-20 19:40:56 UTC
A symmetrical yet clear layout would be
3 groups (i.e. 3 lockers) of two numbers:
1) physical size (width, height) with a toggle to keep aspect ratio fixed
2) pixel size (width, height) with a toggle to keep aspect ratio fixed
3) dpi (width, height) with a toggle to keep their ratio fixed

In this way the user can choose what to fix, and what to control,
and see immediately the outcome of the changes.
Comment 22 Regina Henschel 2018-08-08 15:23:37 UTC
*** Bug 119149 has been marked as a duplicate of this bug. ***
Comment 23 Heiko Tietze 2018-09-04 09:54:54 UTC
*** Bug 119684 has been marked as a duplicate of this bug. ***
Comment 24 andreas_k 2018-09-04 10:11:03 UTC
Created attachment 144664 [details]
presentation minimizer for resolution

This is the dialogue from Impress presentation minimizer (Impress -> Tools -> Minimize Presentations). It's the same than use export to pdf.

can we have the same for draw. the user define at the export the compression quality and the image resolution. That's it. Size (widthe and height) of an Image should be the the same than you define it in page properties. Only the resolution change.

When you export something as pdf you didn't get asked to define the width and height of the pdf it will use the document size the user had defined.

just simple resolution and compression that's it.
Comment 25 Regina Henschel 2018-09-04 11:09:29 UTC
That dialog is not suitable, because here the origin for export is a vector graphic. A jpg or png image already consists of a specific amount of pixels, a vector graphic has no pixels at all.
Comment 26 andreas_k 2018-09-04 11:21:16 UTC
(In reply to Regina Henschel from comment #25)
> That dialog is not suitable, because here the origin for export is a vector
> graphic. A jpg or png image already consists of a specific amount of pixels,
> a vector graphic has no pixels at all.

pixel graphics consist of an size (width and height) and a resolution. Some apps change the size and resolution to pix width and height cause they don't care about resolution. But as you already define the paper size in draw only resolution is needed to get a usefull result.

In image shrink in impress or writer, ... also have resolution and compress rate.
Comment 27 Dirk Munk 2018-09-04 16:48:27 UTC
This bug is reported on Draw, but Writer has the same problem.

Word processors like Writer work with documents made up in inch or cm / mm. So when I design a writer document, the pages are set up in cm. If I want to export such a document to a jpg or png file, the only thing I want to do is set the proper dpi setting. When I do that, the document size (in cm) should stay the same, unless I explicitly want to change it.. 

At present Writer seems to calculate the number of pixels the graphics file will have, based on the size in cm, en the screen resolution (96 dpi). That image seems to exist when the UI is shown. When I change the dpi setting, the size of the document in cm also changes. I will then have to change the size of the document in cm, and then Writer will recalculate the image, but based on the pixels, not with the original odt document as input! That will always result in lower quality. At least this is how it appears to be happening.

If you want to make changes to the size of the document in inch or cm or pixels, that's fine with me. Normally you begin with the dpi setting, and then you change the size of the document, you can use inches, cm, or pixels as desired size. The graphics document should always be calculated from the original odt file, never recalculated from some intermediate graphics file made up out of pixels.