Bug 146929 - Compression settings for images should remember user's choice
Summary: Compression settings for images should remember user's choice
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.2.0.4 release
Hardware: All All
: medium enhancement
Assignee: Heiko Tietze
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Image-Compression-Dialog
  Show dependency treegraph
 
Reported: 2022-01-23 08:19 UTC by Luc Tartier
Modified: 2024-01-04 15:10 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
Dialog box: remember user's choice please (113.75 KB, image/jpeg)
2022-02-07 15:05 UTC, Luc Tartier
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Luc Tartier 2022-01-23 08:19:30 UTC
Description:
Every time I write a text with images, I want to compress them.
The trouble is I have to untick "Reduce image resolution" and if I choose PNG compression, I have to slide from 6 to 9.
It would so much more convenient to have LibreOffice Writer remember user’s choice, at least within one document.
Can you please make this ? I think it would make writer more usable for everybody.
LT

Steps to Reproduce:
1. right clik on image
2. choose compress image
3. make a choice, try again on another picture, you will have to choose again...
4. It is annoying to stay polite... :-)

Actual Results:
Actual result is that you loose time and nerves...

Expected Results:
I would expect to make a choice on the first image and not to have to choose over and over the same thing.



Reproducible: Always


User Profile Reset: No



Additional Info:
Who would want a losseless compression factor of 6 ?
There is no reason not to compress better = it is lossless
Comment 1 Luc Tartier 2022-02-07 15:05:37 UTC
Created attachment 178125 [details]
Dialog box: remember user's choice please

Please don't make people make over and over the same choices:
No, I don't want to change resolution...
No, I don't want to compress less than 9 for png or always 80 for jpg...

Thank you !
Luc Tartier
Comment 2 Dieter 2022-02-07 15:40:44 UTC
Luc, thank you for your report. I confirm the behaviour, but i think it's an enhancement request and not a bug. So let's ask Design-Team. If LO remember the setting, this should also be the case for every setting in this dialog

cc: Design-Team
Comment 3 Heiko Tietze 2022-02-08 10:27:57 UTC
No question for the type and quality but the image dimension/resolution too? Doesn't it depend much on the actual image?
Comment 4 Luc Tartier 2022-02-08 11:02:23 UTC
(In reply to Heiko Tietze from comment #3)
> No question for the type and quality but the image dimension/resolution too?
> Doesn't it depend much on the actual image?

Hi,
The first time you start LO, you could have some presets like changing resolution...

But when you add like me a lot of pictures, you don't want to untick any of the presets. Just let LO remember our choices, please.

Thanx
LT
Comment 5 Dieter 2022-02-08 16:59:48 UTC
(In reply to Heiko Tietze from comment #3)
> No question for the type and quality but the image dimension/resolution too?
> Doesn't it depend much on the actual image?

Quality might also depend on actual image, but I think most of the times you have iamages with similar settings in a document. So yes, I would expect, that LO remains last setting of resolution, too. But of course, this can be discussed.
Comment 6 Heiko Tietze 2022-02-10 13:47:19 UTC
So let's do it. I wonder what's the best way to implement this. We don't want to store user input across sessions but within. Caolan, what's your advice?
Comment 7 Caolán McNamara 2022-02-10 21:28:17 UTC
I think this particular dialog is 
svx/source/dialog/compressgraphicdialog.cxx
if the desire is to *not* store some config so its saved and restored on the next restart of LibreOffice then some static variables to save the state for the application lifetime might be enough, for example in svx/source/dialog/charmap.cxx:55 we do that

so there could be f.e. a static sal_Int32 nQuality = 6, set that to m_xQualitySlider in ::Initialize and then call SlideHdl(*m_xQualitySlider) and maybe "::Update" could set the value from m_xQualitySlider back to that static nQuality so user changes to it are persistent until the next restart of LibreOffice.

I suppose there could be an additional argument that the dialog should be using the already detected input type of the image to preselect whether jpg/png is the best choice of output. Probably png is the best choice unless the input is already jpg.
Comment 8 Commit Notification 2022-02-20 21:18:44 UTC
Heiko Tietze committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/90546b02d70cb9a9c3ee88428d99635a2f7eb22a

Resolves tdf#146929 - Remember user input for the compress dialog

It will be available in 7.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 9 Heiko Tietze 2022-02-21 07:11:09 UTC
The dialog remembers user-settings across the session now. If "reduce resolution" is checked it includes width and height too. These text fields show the image dimension otherwise.
Comment 10 Heiko Tietze 2022-03-03 13:44:47 UTC
*** Bug 145160 has been marked as a duplicate of this bug. ***
Comment 11 Commit Notification 2022-03-04 15:18:12 UTC
Heiko Tietze committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/b82b38bbc896bc4e19171cb8950cbd0e95d2c23f

Relates tdf#146929 - Remember user input for the compress dialog

It will be available in 7.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 12 Jérôme 2022-03-04 19:45:08 UTC
According to https://bugs.documentfoundation.org/show_bug.cgi?id=145160#c8

a patch is missing for the missing bit.
Comment 13 Heiko Tietze 2022-03-07 08:03:40 UTC
(In reply to Jérôme from comment #12)
> According to https://bugs.documentfoundation.org/show_bug.cgi?id=145160#c8
> 
> a patch is missing for the missing bit.

Submitted via c11.
Comment 14 Jérôme 2022-03-09 09:23:37 UTC
(In reply to Heiko Tietze from comment #13)
> (In reply to Jérôme from comment #12)
> > According to https://bugs.documentfoundation.org/show_bug.cgi?id=145160#c8
> > 
> > a patch is missing for the missing bit.
> 
> Submitted via c11.

The issue is that the following use case doesn't work :
1. compress a jpeg image (select jpeg type)
2. try to compress a png image.

On step 2, the compression dialog will propose the last selected image format (jpeg) instead of detecting the png image type and automatically select the png image format.

Of course, restoring the last choice of image format is still usefull when the image format isn't jpeg or png (or a few lossless image formats like gif, ...).
Comment 15 Heiko Tietze 2022-03-09 09:29:41 UTC
(In reply to Jérôme from comment #14)
> ... the compression dialog will propose the last selected image
> format (jpeg) instead of detecting the png image type and automatically
> select the png image format.

I bet the internal format is independent from the source and PNG/JPEG are just two methods. Tomaz, can you clarify this please.
Comment 16 Timur 2022-03-09 10:08:02 UTC Comment hidden (obsolete)
Comment 17 Heiko Tietze 2022-03-09 14:17:03 UTC
(In reply to Timur from comment #16)
> What is c11?

Comment 11
Comment 18 Tomaz Vajngerl 2022-03-10 00:48:51 UTC
(In reply to Heiko Tietze from comment #15)
> I bet the internal format is independent from the source and PNG/JPEG are
> just two methods. Tomaz, can you clarify this please.

Not sure what you mean exactly with "internal format". When we create (raster) graphic objects, either from the document or when the user inserts an image, we uncompressed it into a bitmap and keep the original compressed stream in the memory. If the bitmap is changed (for example resized, a graphic filter is applied), the original compressed stream is lost, so the graphic doesn't have it anymore and only uncompressed bitmap is available. If such a graphic object is saved in a document, we compress it as PNG, otherwise we save the compressed stream (if it is compatible with the document).

With the compress graphic dialog the user can resize the bitmap and has the choice in the way it is compressed, so regardless of what the original compressed format is, we take the uncompressed bitmap, resize it and compress it again using whatever settings were chosen. We can however determine what the original format is and choose what the appropriate setting is.

We probably want to match what original format is, because that is what the user expects. If the original is PNG, we should select PNG as the compression method, if the original is JPEG we should select JPEG. If the original is anything else, we should use PNG. I think we can't just recall this choice from the previous time as this depends from image to image (I think Jérôme ha a point here). What we can recall is the compression / quality settings and the choice to resize (or not) and the DPI setting (but not the image width an height).
Comment 19 Heiko Tietze 2022-03-11 09:53:58 UTC
(In reply to Tomaz Vajngerl from comment #18)
> Not sure what you mean exactly with "internal format".
The uncompressed BitmapEx. 

> We probably want to match what original format is, because that is what the
> user expects.
Still don't see the need but anyway. Reopening the duplicate.
Comment 20 Dieter 2022-03-26 07:06:51 UTC
(In reply to Commit Notification from comment #8)
> Affected users are encouraged to test the fix and report feedback.

Compression settings are now remembered => VERIFIED FIXED

Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: e8c95b796626cb9db163f5d563fa67f38a5e92b0
CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-GB
Calc: CL

Heiko, thanks for fixing it!