Sounds like an enhancement. As long we do not have that ability in DRAW, WRITER will not have it, too. 

I see only low importance for that. LibO is not a pixel picture editing program, there are lots of alternatives, whith what pictures can be edited before they will be inserted into a LibO document. 

I believe, if someone inserts pixel pictures into a LibO document with a given resolution,  he has decided that he needs just the actual resolution and he does not want to reduce the quality of the pictures to reduce file size.

Well I'm sorry, but I think you're not leading in the right direction. 
First, most people using Writer usually don't have the skills to open Gimp / Photoshop and resize the picture, nor the knowledge about how pictures work. And I'm not asking about creating a picture editor in LO.

Second, your main competitor has this options for ages (appeared in Word 95), so you can't tell user to switch to your software if this feature is missing.
Usually, people try to send a document as an email attachement, and a 30MB file is a no-no.

Third, what I'm asking here is for simplifying the process to the end-user.
Even for a power user who knows about pictures / resolution, having to fire up Gimp / Photoshop, figure out the part to crop, resize, save to a temporary folder, drag the worked picture to the document, and then realizing it's still too large / small, is very long, painful, if not disappointing. 

Since you already have all the code required to resize the pictures and save them, and since the whole point of a WYSIWYG editor is to perform action in live, I'm asking if it's possible to add a menu action (not automatic, but manual), where Writer would do:

for each picture in document
{
   if (picture.currentSize < picture.initialSize)
   {
       Picture tmpPic = picture.resize(picture.currentSize).crop().withJPEGCompressionRatio(0.7);
   
       picture = tmpPic;
   }
}

*** Bug 34557 has been marked as a duplicate of this bug. ***

I guess it remains in LibO 3.5.0 beta 1

A bit of relevant discussion from OOo-era:
http://user.services.openoffice.org/en/forum/viewtopic.php?t=6918
http://user.services.openoffice.org/en/forum/viewtopic.php?t=3665

I add my vote to this enhancement request.

In our company many users insert photos in writer document directly from a camera or a scanner. Then they resize them ... and save 30Mb documents.

So we have documents with a 8mpx images display in 800x600 ( and sometimes less) ...

No need to have a picture editor or something automatic , only an option (like in Word in fact ....) to compress and resize photos / pixel pictures in balance with the used display size.
Possibly, but not mandatory, with some options about compression level, real crop for cropped display, resize and so on.

Something like presentation minimizer but dedicated to "pixel picture" would be a great thing.

May be this could be an enhancement for 3.7.x version ?

This is discussed in numerous thread even in ApacheOO :
 https://issues.apache.org/ooo/show_bug.cgi?id=15379 (ooold request from 2003).

May I add Cédric Bosdonnat or Michael Stahl (friendly expert for writer) to the CC list so they could be informed ?

IMHO they know about this. No sense in annoing them.

As a workaround try using freeware IrfanView or FastStone. They are (hugely popular) image viewers that can do what you want.

Set component to LibreOffice.
Though not so often: it may well be usefull to Calc too.

Recently some improvements in exporting images from Writer / Calc have been implemented.
And there is the possibility in the Presentation Minimizer (Impress, menu Tools) to reduce the actual size of images.


(Added some words to summary - makes it easier for others to find.)

Maybe an easy hack or a slightly more difficult hack?

just noticed: the context menu for an image in Impress offers: "Compress image"

(In reply to comment #13)
> just noticed: the context menu for an image in Impress offers: "Compress
> image"

If that's Cyril was asking, then there's a better option: Tools > Minimize Presentation...

Sorry, I didn't really realize what's the proposed option, so I'll add sth. 
In my view, resolution of pictures could be reduced with "Save As.." option, maybe via "Edit filter settings" currently grayed for ODT. 
LO should already contain the code which it uses for "Export as PDF".

(In reply to comment #13)
> just noticed: the context menu for an image in Impress offers: "Compress
> image"

http://www.libreoffice.org/download/4-0-new-features-and-fixes/

Graphics can be resized and recompressed with the new Compress Graphics.. popup menu function. (Tomaž Vajngerl)

    Menu function is available in Draw, Impress and Calc but not (yet) Writer.
    Supports displaying of current graphics information: original dimensions, dimensions inside of document.
    Ability to reduce image resolution with setting a new dimension (width/height in pixels and DPI).
    Lossless (PNG) or lossy (JPEG) compression with ability to set the quality and compression strength.

Hi,

In 4.1 it is also possible to compress images in Writer. I have some ideas how to improve this functionality but this will have to wait until 4.2. 

Known bugs or missing features:
- ability to remove cropped areas
- apply button (or any other action) to see the visual result of compression without leaving the dialog
- DPI calculation of cropped images is not working correctly
- ability to compress all images in the document (only DPI makes sense in this scenario)
- warnings or limitations on actions that don't make sense (for example compression of vector image will produce a bitmap image, if the size of the compressed image is greater than the original)

Other suggestions are welcome.

Regards, Tomaž

The new "compress graphic" feature is a nice tool, but it does not fully address this bug. We need a global solution. For example, when a user needs to email a large image intensive doc, they shouldn't be expected to go through every single image, and manually crop, resize, and compress. Instead, they should be given the option to compress ALL pictures in the "save as" or "export" dialog. That dialog should be able to select: 

high - high compression ratio, reduce to low DPI, smallest size, used for email  
medium - 
low - low compression, max DPI, largest size, best quality, used for print
Custom- would be nice, but not necessary

Finally, a checkbox option to permanently crop images. This save/export option should be available in writer, calc, and impress.

(In reply to comment #18)
> The new "compress graphic" feature is a nice tool, but it does not fully
> address this bug. We need a global solution. For example, when a user needs
> to email a large image intensive doc, they shouldn't be expected to go
> through every single image, and manually crop, resize, and compress.
> Instead, they should be given the option to compress ALL pictures in the
> "save as" or "export" dialog.

I wanted to point out that such a thing already exist: Presentation Minimizer.
But I now I can't find it! (LO 4.0.4.2) It's supposed to have been under Tools, right? Has it been removed?

This feature is enabled for me in LO 4.1. It's awesome, but only works in Impress. As I said, this need to be a *global* feature across Writer, Calc, and Impress.

The "known bugs" from Tomaž in comment #17 would address the outstanding issues well.  I think having these options as part of the "Compress Graphic" dialog would be a good option (the "apply to all images in file" would be particularly valuable and is what it appears Luke and others are requesting: even though in this case it wouldn't be part of an "export dialog").

In order to limit the confusion between ProposedEasyHack and EasyHack and to make queries much easier we are changing ProposedEasyHack to NeedsDevEval.

Thank you and apologies for the noise

I would like to share a complementary use case.

The first description told :
> The functionnality should not be automatic, but manual

I agree with a manual use of the final tool which provides the final images resolutions.

However, I think that the resolution (DPI) should be kept below a maximum limit at insertion time.

For example each inserted image could be altered with :
- a default maximum resolution of 300 DPI (could be changed in "settings" dialog)
- no quality change (for JPEG)
- no croping

At my office, the users are creating a lot of LO Writer documents and they won't use a simple click in order to reduce the size of the document. What should we keep images with 1200 DPI for ?

This maximum resolution at insertion time would have a huge side effect by reducing the storage use (very expensive for us when the backup has to last during 20 years).

At insertion you don't know yet the actual DPI - only when the image has been properly resized to fit a place in the document you know the actual DPI. Or do you mean at save when a new image is inserted (not saved yet in the document)?

One possibility is to check images DPI at save if it should check images or not and the DPI limits could be globally configured. So for example you could configure the maximum DPI image can have and target DPI if image exceeds maximum. By default this would be off.

Or maybe also have middle DPI where you could ask if the DPI should be reduced (for example for images between 300 DPI - 1200 DPI, 1200 DPI is the maximum).

At insertion time (or at saving time as you proposed), you can reasonably assume that the image would possibly not exceed the page dimension. This would keep enough margin in order to later crop or resize the image before exporting with the "minimizer" tool.

For example, if you have a 10 Megapixel image (4/3 form factor, 3640 pixels for the big side), it will exceed 300 dpi if you make this image fill a A4 page (21x29,7 cm or 8,3x11,7 inches or 2480x3507 pixels at 300 dpi). Note that the A4 form factor doesn't fit a 4/3 form factor of the image. The difference between those form factors and the maximum number of pixel allowed by the page (user defined maximum resolution) would help to guess the new resolution of the inserted image.

Moreover, if you take into account a 1 cm margin, the area to be fit is 2362x3390 pixels at 300 dpi. This would increases the gap between the resolution of the inserted image and the user defined max dpi.

Maybe this feature could have an option in order to tell if the margins of the page should be taken into account (in addition to the user defined max dpi).

If a user need a part of an image to fit the full page, then he/she would use a specific image processing tool or he/she would disable this feature into the settings dialog.

@Jérôme
In the vast majority of workflows, the user will only want to reduce the image quality at the end of the document creation process. LO also should not degrade image quality automatically without any user input.

While the feature you are proposing is related to this one, it is also something that most users would want off by default. Please consider filing a separate bug report.

Ok, I filed the related bug report #77407.

(In reply to comment #17)
> In 4.1 it is also possible to compress images in Writer. I have some ideas
> how to improve this functionality but this will have to wait until 4.2. 
> Regards, Tomaž

Will this be added to 4.2? I didn't see anything in https://wiki.documentfoundation.org/ReleaseNotes/4.2

It is not in 4.2 (4.2 was already released in January) and there is also nothing in for 4.3 (feature freeze is in less than 2 weeks). Maybe I will play with crop images a bit but currently I don't have time for this. If someone wants to give it a try I can give code pointers..

By addressing Bug 34555, Philippe Jung has given Writer and Calc the ability to:
- save image
- change picture
- compress image
- edit with external tools
- crop image

Now that these features are available, could the Presentation Minimizer be updated to be a "Document Minimizer" for Writer and Calc?

The situation didn't change a bit. It is not harder or easier to implement a general "document minimizer" - but somebody has to do it. Presentation minimizer is also an extension, so first I would move it into the core.

(In reply to Tomaz Vajngerl from comment #31)
> The situation didn't change a bit.

Isn't the compression as implemented sufficient?

(In reply to Heiko Tietze from comment #33)
> (In reply to Tomaz Vajngerl from comment #31)
> > The situation didn't change a bit.
> 
> Isn't the compression as implemented sufficient?

This is a feature request for a Document wide image compression/resize. Of course this can be done manually on each image, but that is not what this feature request is for. Documents can contain dozens of images. Doing it manually, it's easy to miss some and can take a long time. 

Also it's a feature users expect as word processors such as Word have had this capability for over a decade now.

If you consider to implement this feature, please have also bug 83734 "EDITING: Cropped image gets distorted when Compress Graphic is used" in mind. Such a bug should be fixed before the compression feature is used by more people than now.

*** Bug 77407 has been marked as a duplicate of this bug. ***

In bug 77407 it was requested to compress all images in a document and we discussed this request in the design meeting 2017-Apr-27. The recommendation is to compress when an image is inserted based on settings in tools > options.

   + When
     + a) on insert, b) manually
     + have a checkbox in the insert image dialog to disable the autocompression
     + insert with a fix dpi as defined in tools > options
     + select all and use the known dialog should work too
   + Where 
     + tools > options
   + What
     + apply compression to only jpg?
     + no, every image above the defined dpi level
   + What option needs to be provided
     + auto compression on/off
     + dpi with steps from 50 to 600
     + bmp and tiff should be converted & compressed as png or jpg based on their size (jay)
   + Default values
     + on by default
     + 300 dpi
       + jpg compression defaults - gimp 90%, pinta 85%, krita 80%, LO compression dialog 90%
       + png compression defaults - gimp 9, krita 9, LO compression dialog 9

> Default values
     + on by default

This might make sense for home users, but in the work place, destructive defaults are a terrible idea. From web design to marketing, the compression takes place at the very end of your workflow. You always want to work at highest quality without losing anything until you are ready to publish your content. 

Compressing objects on the front-end is backwards and will lead to data loss.

One more point. In the past I have extracted photos and audio clips from email that an family member sent me to make a memorial web page after they had passed away. They were images and mp3s inserted into a Word doc. If Word used lossy compression like people are suggesting we use, the end result would have be far worse. The more I think about it the worse this idea sounds. 

Compressing and resizing belongs on the final, publishing/exporting step. This is how all other Office suites function. This is how our Impress presentation currently functions. Trying to do this backwards by default is going to lead to data loss and unhappy users.

(In reply to Heiko Tietze from comment #37)
> In bug 77407 it was requested to compress all images in a document and we
> discussed this request in the design meeting 2017-Apr-27. The recommendation

Thanks! Good ideas.

>    + When
>      + a) on insert, b) manually
>      + have a checkbox in the insert image dialog to disable the
> autocompression

What if one copies/pastes an image from the file browser?

(In reply to Luke from comment #38)
> > Default values
>      + on by default
> 
> This might make sense for home users, but in the work place, destructive
> defaults are a terrible idea. From web design to marketing, the compression
> takes place at the very end of your workflow. ...

Understand that.
Would an option, at the place where compression is set, to turn this on/off by default, make you happy / less sad?

Compression and reducing image size are both destructive operations. Instead of making this an option at export, save, or publishing time, why are we choosing to do it at insert time? What use case other than Bug 77407 justifies this reduction in functionality and risk of data loss?

Will tools > options -> Compression settings be retroactive? If not, how will you handle the most common use case of reducing the overall document size to be shared with others? If your proposed solution doesn't address this, it doesn't resolve this bug report, only Bug 77407 which is a far less likely scenario.

I think the below additionnal settings would help.

"don't resize if original size is greater than" : with 200% of resizing dpi for example (with value expressed in percent). This would avoid to make the image interpolation ugly if the orginial resolution isn't enough for the reduced resolution.

For lossless compression : an optionnal "use indexed colours" checkbox. This could highly reduce the file size without any human perception difference with many "artificial" images.

For any image manipulation, I think the lossless or lossy image type should be preserved. In most cases, if you convert a jpeg image into a png image, you will inflate the image file size. In a many cases the image file size will inflate if you convert a png image into a jpeg with a suitable quality, especially if the lossless image uses "artificial" colours (screenshot, ...), even more if they are indexed.

(In reply to Luke from comment #38)
> This might make sense for home users, but in the work place, destructive
> defaults are a terrible idea. From web design to marketing, the compression
> takes place at the very end of your workflow. You always want to work at
> highest quality without losing anything until you are ready to publish your
> content. 

People who care about maximum quality will turn it off..

(In reply to Jérôme from comment #42)
> I think the below additionnal settings would help.
> 
> "don't resize if original size is greater than" : with 200% of resizing dpi
> for example (with value expressed in percent). 

This could go in as a custom option section that others suggested.

However, reducing the damage done doesn't address the fact that the proposed "fix" is destructive change at the start of the work flow. Destructive edits should never be applied by default or as an existing setting. They should be something the user explicitly chooses.  



> For any image manipulation, I think the lossless or lossy image type should
> be preserved. 

Yes, that makes sense.

(In reply to Cor Nouws from comment #40)
> What if one copies/pastes an image from the file browser?

The agreement was to compress on insert depending on the settings. 

> (In reply to Luke from comment #38)
> > > Default values
> >      + on by default
> > 
> > This might make sense for home users, but in the work place, destructive
> > defaults are a terrible idea. From web design to marketing, the compression
> > takes place at the very end of your workflow. ...

The admin switches the option off by default in enterprise environments.

The reason to compress on insert was that on save you wont see the effect unless you reopen the document. But if you are not happy with the insertion it's pretty easy to change the option and repeat.

@ Heiko Tietze 

As some who has used this feature in Word on a regular basis for my work, could you please explain how your proposed solution would be of any use? For example, I published a physical and electronic newsletter for my organization. For the physical copy that gets printed, I need the absolute highest quality for the images to look professional, but the electronic copies must be kept under a certain size or they cannot be emailed out. 
 
How would I or any creative professional maintain the necessary high resolution, uncompressed images for printing if the compression is done at insert time? Did you consider how this is used in the real-world before making your decision? I hope you reconsider.

(In reply to Joey Reid from comment #46)
> How would I or any creative professional maintain the necessary high
> resolution...?

Expert users switch off the option and get the max quality unless the images are compressed manually (or at some defined situations). Again, the decision was made having feedback in mind. How would you do that when the action is executed immediately before save without always nagging with confirmation boxes? The only alternative is to refuse this enhancement and to provide only manual compression, maybe with multiselection.

An other solution is be asking to the user the first time he is inserting an image. Next the user choice is saved into the user environnement.

A small indicator over the image could show if it has been automatically compressed or not. When clicking on this indicator a popup window would ask again the question to the user.

(In reply to Heiko Tietze from comment #47)
> (In reply to Joey Reid from comment #46)
> How would you do that when the action is
> executed immediately before save without always nagging with confirmation
> boxes? 

I suggest you try this feature on MS Office. 

File->Save As->Option->Tools->Compress picture

Or with our Impress Presentation Minimizer. Bug 34557 is a dupe of this.

Neither of these requires any nagging and are both easier to access then buried in with the many options under tools. And more importantly they allow you to resize your document when you are done with it. This is by far the most common use case.

> The only alternative is to refuse this enhancement and to provide
> only manual compression.

Why are you ruling out MS Office's approach? Or Impress's approach? Both of these are far more flexible.

(In reply to Jérôme from comment #48)
> An other solution is be asking to the user the first time he is inserting an
> image. Next the user choice is saved into the user environnement.
> 
> A small indicator over the image could show if it has been automatically
> compressed or not. When clicking on this indicator a popup window would ask
> again the question to the user.

Possible, but does it change the workflow? I mean it just exposes tools > options whatever to a checkbox. 

Despite that an indicator could be nice. And if it would be possible to undo the compression it's pretty easy for the user to change the inserted image. Unfortunately dev said it's not possible. Or rather it's weird to mix the automatic processing with user input. @Tomaz, please elaborate on this.

(In reply to Joey Reid from comment #49)
> I suggest you try this feature on MS Office. 
> ...
> Or with our Impress Presentation Minimizer. Bug 34557 is a dupe of this.

We had a look how MS handles compression and do suggest a similar workflow here.

"Pictures in Office are automatically compressed using the number specified in the Image Size and Quality options on the Advanced tab of the program options. By default, this is set for print (220 ppi), but you can change this." https://support.office.com/en-us/article/Reduce-the-file-size-of-a-picture-8db7211c-d958-457c-babd-194109eb9535

Actually the Minimizer workflow is exactly what you get when the auto compression option is switched off. With 

, or rather it makes no sense because mixing the automatic operation. And with the Jérôme's confirmation box you won't miss the setting once it is introduced, right?

So i had been thinking about the issue more after the meeting and here are some things that came to mind.

1) As this is a new feature to ODF documents, there are many documents that have non-optimized images in them, so these images should be optimized when a document is loaded. (Tomaz mentioned: well.. after loading in a separate thread)

2) OOXML files have the compressed dpi/ppi setting stored per-file in /word/settings.xml under <w14:defaultImageDpi>, so we should read/write and use this setting when such a file is opened.

4) This setting should also be saved and loaded into/from ODF files.

5) The global setting of this feature is going in the options dialog and the per-file setting would be in the File > Properties dialog.

(In reply to Heiko Tietze from comment #50)
> Actually the Minimizer workflow is exactly what you get when the auto
> compression option is switched off. 

So the workflow is the same as MS Office and the compression takes place at save time, correct? If that's the case, I don't have any concern.

(In reply to Luke from comment #52)
> So the workflow is the same as MS Office and the compression takes place at
> save time, correct? If that's the case, I don't have any concern.

No the workflow wouldnt be the same, as with MSO, the original image isnt discarded until the document is closed. MSO will compress the image on save, but the compressed image wont be shown in the document until the document is reopened.

Our workflow will be that the image will be compressed once it is inserted, as that will ensure the memory savings that we want to achieve.

(In reply to Heiko Tietze from comment #37)
>      + dpi with steps from 50 to 600

DPIs lower than 96 result in very bad image quality, so i'd not give users the option to set 50 and 75. DPIs above 300 arent useful for the automatic image optimization that we are doing, as even a 4k image (~10 Mega pixels) gets inserted at 573 DPI in writer.

(In reply to Yousuf Philips (jay) from comment #53)
> No the workflow wouldnt be the same...

Luke's concerns are that professional users do not have the choice to deal with uncompressed images. And if he switches of the auto compression the workflow would be the same as known from Microsoft Office with uncompressed images in the working document with an option to compress on save.

I still do not fully understand the workflow of the proposed solution. I need to work with high quality images, so I must disable compression and resizing during the draft phase. With that in mind, can I create a compressed version for sharing on the web and emailing after I finalized the document? Will your solution allow compression after a document is completed?

(In reply to Joey Reid from comment #55)
> I still do not fully understand the workflow of the proposed solution. I
> need to work with high quality images, so I must disable compression and
> resizing during the draft phase.

Yes you would disable automatic image optimization in the Options dialog to disable it at the global-level.

> With that in mind, can I create a
> compressed version for sharing on the web and emailing after I finalized the
> document?

Yes you can open the File Properties dialog and set the document-level image optimization that will take place when you save the file.

> Will your solution allow compression after a document is completed?

Yes users will have full control to enabled/disable it when they like.

I've some problem while reading "graphic professional", "full resolution image"  and Writer or Word. 
I've always thought that desktop publishing with intense graphic used other software like InDesign or Scribus ... I don't know about InDesign, but Scribus uses relative links to images ... like Writer if you check the box during insertion.
With full resolution images embedded, you will soon have a 100Mb document ... not easy to manage. It's easier with links to images in a sub-directory.

Nonetheless, I think the proposed workflow totally relevant. An automatic compression at import with the ability to fix compression in options, and also the possibility to make a global compression during saving / export seems a good idea.
In my compagny there is many professionals but "non graphic professionals" (managing graphics / images is'nt their job) who use Writer and insert many images without any consideration about size in pixels or Mb of these images. And then , they want to email the resulting document and ... sorry  maximum file size exceed.

So, for these users without an high graphic quality required, this automatic compression would be very useful.
A full resolution 4000x3000 image is oversized even for printing a 20x30cm page.

(In reply to Yousuf Philips (jay) from comment #56)
> Yes users will have full control to enabled/disable it when they like.


Images should be kept at the highest *reasonable* quality while editing. So what is the advantage to doing this on insert time if you can still compress them manually at any time? What is the use-case? Are we trying to save memory?

(In reply to Joey Reid from comment #58)
> Images should be kept at the highest *reasonable* quality while editing. So
> what is the advantage to doing this on insert time if you can still compress
> them manually at any time? What is the use-case? Are we trying to save
> memory?

You know that you should run image compression manually, but not every user knows this, cares, forgets to run. In bigger institutions this makes administrators mad, because bigger than necessary documents are flying around the mail system and need to be stored or even more problematic - backed up daily.

(In reply to Tomaz Vajngerl from comment #59)
> You know that you should run image compression manually

Well, I know I want it on the version I want to share, but not on my master or working document.


> but not every user
> knows this, cares, forgets to run. In bigger institutions this makes
> administrators mad

Again, maybe I'm not being clear. What is the advantage to compressing and resizing at insert time, rather they save time? 

I have no issue with setting sane defaults for compressing and resizing(especially if they can be turned off). For example, let’s say my system is set to 96 dpi. I create a new document without thinking about this. Insert time change, will not be recoverable. I will have to start from scratch. However, if this is handled at save time, I can change the document settings and no data will be lost as long a I remember before saving.

I share Joey's objections in doing compressing when inserting an image instead of saving the file.

Maybe the user wants to edit the image after inserting (and before saving) and the compression and other "optimizations" limit further actions on the image due to low resolution, etc.

(In reply to Joey Reid from comment #60)
> Again, maybe I'm not being clear. What is the advantage to compressing and
> resizing at insert time, rather they save time? 

Advantages:
1) User have the ability to disable the compression at insert time (users arent prompted everytime time they press Ctrl+S or click the save button in the toolbar)
2) Smaller inserted images saves memory and also results in a more responsive UI (the UI becomes very sluggish when large images are present in a document - e.g bug 78529)

> For example, let’s say my
> system is set to 96 dpi. I create a new document without thinking about
> this. Insert time change, will not be recoverable. I will have to start from
> scratch. However, if this is handled at save time, I can change the document
> settings and no data will be lost as long a I remember before saving.

As the optimization happens once the image is inserted, you should notice that the image doesnt look as shape as you remember it to be. Also you still have the image you inserted, so you can always replace the inserted image with the original image and then disable compression. As mentioned above, users dont encounter a dialog when they save, unless its a new document, so users would never see the option to enable/disable compression at save time.

(In reply to Thomas Lendo from comment #61)
> Maybe the user wants to edit the image after inserting (and before saving)
> and the compression and other "optimizations" limit further actions on the
> image due to low resolution, etc.

LibreOffice doesnt have any image editing capabilities, so i'm not sure what is being said here. The only available functions that alters the pixels in an image are the image filter functions and with optimizations only happening with large images, no low resolutions images will be produced by the optimization routine.

At save is not a good time for compression: 
Users won't have an idea that compresion will happen and informing them (or asking them further questions) at the save time is not good practice too. Users have different habits and use save at different times. Some save frequently after every action, so they could insert, resize too much, save and then realize the image should be bigger. Users that don't save often, could be in a hurry and save, close LO, then after a while open and realize the images are compressed and it is not what they want. 
MSO even doesn't show the result after save - as long as you keep the document open, it will show the original. When you close and open again - you'll see the compressed version. We don't want to use a workflow that silently does compression or potentially could compress to a lower DPI than specified. Additionally we want the user to have the control and the ability to decide on case-by-case basis.

(In reply to Thomas Lendo from comment #61)
> I share Joey's objections in doing compressing when inserting an image
> instead of saving the file.
> 
> Maybe the user wants to edit the image after inserting (and before saving)
> and the compression and other "optimizations" limit further actions on the
> image due to low resolution, etc.

Not the most common use case, and then one usually does no changes that require huge extra in image size. So maybe that can be covered by including as example the suggested waring (comment #48).

(In reply to Yousuf Philips (jay) from comment #62)
> Advantages:
> 1) User have the ability to disable the compression at insert time (users
> arent prompted everytime time they press Ctrl+S or click the save button in
> the toolbar)

The trend in UIs are for people to drag and drop. Putting a pop-up dialog up every time a user drops an image interrupts the work flow. People don't want to have to think about compression settings at insert time and often don't know their target. This is a disadvantage, because you will either have unintentional data loss or an annoying pop-up to close every time you insert things.

> 2) Smaller inserted images saves memory and also results in a more
> responsive UI (the UI becomes very sluggish when large images are present in
> a document - e.g bug 78529)

In a world of 4 TB hard drives and 32 GB of RAM this "advantage" rings hallow. As the developers point out, the problem in Bug 78529 is with out image caching. Once that's fixed, this won't be an issue. I'd rather deal with any performance issues than produce low quality output.

Every application that I have ever used that allows for compressed images puts destructive edits as an explicit, manual operation or at save time.  If these are the only advantages you can think up, than the disadvantages far out-weight the advantages. 

One more question:

Heiko Tietze said the default compression will be 90%.

So what if we insert already highly compressed images? Will this compress them again? With lossy compression, this will do nothing but result in a lower quality image. This is just another reason why this idea needs to be thought thought more carefully.

(In reply to Luke from comment #65)
> The trend in UIs are for people to drag and drop. Putting a pop-up dialog up
> every time a user drops an image interrupts the work flow.

No there wouldnt be a popup for drag and drop or copy and paste, so whatever optimization setting that has been configured at document-level will automatically happen.

> People don't want
> to have to think about compression settings at insert time and often don't
> know their target. This is a disadvantage, because you will either have
> unintentional data loss or an annoying pop-up to close every time you insert
> things.

Most users will never disable the compression settings, but for those that care to disable it, they have easy access to do so at the document-level in the insert image dialog. Most users wont visually be able to see the difference between the original image and the optimized image due to the nature of jpg compression technology, and those who do notice it will easily be able to fix it.

> In a world of 4 TB hard drives and 32 GB of RAM this "advantage" rings
> hallow. As the developers point out, the problem in Bug 78529 is with out
> image caching. Once that's fixed, this won't be an issue. I'd rather deal
> with any performance issues than produce low quality output.

Not everyone lives in such first-world luxury of having endless amounts of hard disk space, memory and lets not forget CPU power, and even if one does, why produce a 31 MB document with original images[1], when a 4 MB document with optimized images[2] is close to identical in quality.

[1] https://drive.google.com/file/d/0B6qJrVIa0SAlVHpOZFV3QUdmRjQ/view?usp=sharing
[2] https://drive.google.com/file/d/0B6qJrVIa0SAlX3BJZWlfdGs2eDg/view?usp=sharing

I wont hold my breath for when bug 78529 gets resolved, as it is a known issue that has been around for 5+ years (bug 47148) and likely will still be around for many years to come. Here is another example of images slowing down the UI (bug 100442).

> Every application that I have ever used that allows for compressed images
> puts destructive edits as an explicit, manual operation or at save time.  If
> these are the only advantages you can think up, than the disadvantages far
> out-weight the advantages. 

Guess we'll agree to disagree.

> Heiko Tietze said the default compression will be 90%.

Didnt see him saying that anywhere, comment 37 is minutes from a design meeting, and we are still researching what the most optimal compression will be from 80 to 95 percent.

> So what if we insert already highly compressed images? Will this compress
> them again? With lossy compression, this will do nothing but result in a
> lower quality image. This is just another reason why this idea needs to be
> thought thought more carefully.

We are well aware of this issue, and many others, and Tomaz is already taking such a scenario into consideration with his development work.

Development of this feature and workflow is already underway with input from the design team, so for those who still wish to debate this further, please attend one of the design meetings that happen on Thursday's at 11am UTC.

For those interested in helping ensure the feature works correctly, please submit sample documents with images that you think should or shouldnt be optimized along with the reasons, or suggest scenarios that should be taken into account.

(In reply to Yousuf Philips (jay) from comment #66)
> Most users wont visually be able to see the
> difference between the original image and the optimized image due to the
> nature of jpg compression technology, 

Most Users? Home users sure. But if want to be taken seriously by professionals, we should act like professional software and not assume the user is stupid and doesn't care about quality. The professionals I work with care very much. They calibrate their monitors and send their work to professional printers. Your line of thinking turns that kind of user off, ensuring we remain a toy for hobbyists. 

> and those who do notice it will easily
> be able to fix it.


We are talking about DESTRUCTIVE EDITS. This assumption that it can just be "fixed", is only true if the user still has access to the original, notices it, and it aware of this backwards workflow. If users are familiar with other Office or professional software, they will not be expecting this behavior. 

 
> why produce a 31 MB document with original images[1], when a 4 MB document
> with optimized images[2] is close to identical in quality.

Have you ever worked with printed material? Images can look fine on the screen, but suffer from noticeable compression when printed. Nevermind the fact we shouldn't be reapplying lossy compression without the user requesting it.

> around for many years to come. Here is another example of images slowing
> down the UI (bug 100442).

Trick unsuspecting users into using low quality images instead of fixing our rendering system is a terrible idea. I'd much rather have slow downs then have the quality of my work degraded to hide some performance bug.

> We are well aware of this issue, and many others, and Tomaz is already
> taking such a scenario into consideration with his development work.

I understand the argument for defaulting to 222 DPI unless resizing is disabled. This is how Word works and is acceptable, especially when done at save time. 

However, compression is another story. Word does not recompress images implicitly. JPEG compression is lossy. Every Time you compress a compressed image you lose quality. This is why this option should be explicit for all users. For example if I insert a 69% image and LO again recompressed at 90%, the only thing accomplished is LOSS OF IMAGE QUALITY. 

> Development of this feature and workflow is already underway with input from
> the design team, so for those who still wish to debate this further, please
> attend one of the design meetings that happen on Thursday's at 11am UTC.

Of the 22 people here that want this feature, 3 have already spoken out that the design meeting proposed approach was flawed. This was done within hours of Heiko's announcement. Hopefully this is being communicated. 


In summary, Professional Software does not performs destructive edits at insert time. This feature is going to annoy profession users who discover it after the fact. It will lead to data loss for home users who do not have access to the original. The proposed implementation comes with all of these serious negatives for 2 very weak advantages.

(In reply to Luke from comment #67)

> We are talking about DESTRUCTIVE EDITS. This assumption that it can just be
> "fixed", is only true if the user still has access to the original, notices
> it, and it aware of this backwards workflow. If users are familiar with
> ...

Hé Luke,
I think there is agreement on your point that quality is important and that the workflow must give users and organizations the control and clarity they need to reach that. We must make sure to put that process in place very well.
IMO the ideas given here fit that purpose. Is there anything missing in your opinion?

(In reply to Luke from comment #67)
> Most Users? Home users sure. But if want to be taken seriously by
> professionals, we should act like professional software and not assume the
> user is stupid and doesn't care about quality. The professionals I work with
> care very much. They calibrate their monitors and send their work to
> professional printers. Your line of thinking turns that kind of user off,
> ensuring we remain a toy for hobbyists. 

Come on.. get real. You know full well that the amount of users who will send documents to professional printers that use LO is very very low. Such people will turn this off...

Also there are many professional users (just not from the profession you have in mind) that use LO and won't care if pictures get compressed. 

> We are talking about DESTRUCTIVE EDITS. This assumption that it can just be
> "fixed", is only true if the user still has access to the original, notices
> it, and it aware of this backwards workflow. If users are familiar with
> other Office or professional software, they will not be expecting this
> behavior. 

MSO 2016 by default compresses on save to 220 DPI. You don't see it did that until next time you open a document. Nobody cares. Professional users turn this off in settings. 

> Have you ever worked with printed material? Images can look fine on the
> screen, but suffer from noticeable compression when printed. Nevermind the
> fact we shouldn't be reapplying lossy compression without the user
> requesting it.

300 DPI or more should be good enough for most cases. Who cares much about images will turn this off. Lossy compression at a high quality setting has little visual impact.

> Trick unsuspecting users into using low quality images instead of fixing our
> rendering system is a terrible idea. I'd much rather have slow downs then
> have the quality of my work degraded to hide some performance bug.

This is not about rendering system, that's just the side effect. Of course keeping the images small will have the effect that we can cache more images, swap in and out from disk the image a lot faster even when rendering system is fixed.  

> I understand the argument for defaulting to 222 DPI unless resizing is
> disabled. This is how Word works and is acceptable, especially when done at
> save time. 

And.. we will default to 300 DPI and this is the minimum in our workflow, but now I think you don't even understand the workflow.

I already explained why at save workflow is not good IMHO, but nobody attempted to refute that.

> However, compression is another story. Word does not recompress images
> implicitly. JPEG compression is lossy. Every Time you compress a compressed
> image you lose quality. This is why this option should be explicit for all
> users. For example if I insert a 69% image and LO again recompressed at 90%,
> the only thing accomplished is LOSS OF IMAGE QUALITY. 

What do you mean it does not? Of course MSO recompresses the image with JPEG which is lossy. By default. Do you even know what it means to lower the DPI? When lowering the DPI what do you think MSO uses to compress the images again?

Not only that - if you apply a filter, MSO recompresses the original with JPEG XR  lossy mode and stores it in the document. If you revert the filter you get back the "original" from that file. That's a operation with quality loss... and nobody is warned this will happen. LO is even worse here as we don't keep the original at all, but at least we want to add non-destructive filters in the future.

Anyway, I agree that there is loss of image quality, however how much of that is actually perceived. 

> Of the 22 people here that want this feature, 3 have already spoken out that
> the design meeting proposed approach was flawed. This was done within hours
> of Heiko's announcement. Hopefully this is being communicated. 

You did not demonstrate the flaws and I don't think you understand what we actually proposed. Should I line the whole workflow down again and compared with the workflow found in MSO 2016?

> In summary, Professional Software does not performs destructive edits at
> insert time. This feature is going to annoy profession users who discover it
> after the fact. It will lead to data loss for home users who do not have
> access to the original. The proposed implementation comes with all of these
> serious negatives for 2 very weak advantages.

Again - professional users will turn this off. The home users and "other" professional users shouldn't see a difference in most cases as the settings will be kept high. If they do, they will be able to turn this off on per-document basis. Idea is also that a compressed image would have a non-obtrusive marker so users can see if compression happened and could revert that as long as they stay in the session, but let's see.

I get that professionals can and will disable compression here just like they can with MSO. That has never been my concern. My concern for the past has always been about the work flow. JP gave 2 advantages which I replied to. As far as yours, this is my response.

(In reply to Tomaz Vajngerl from comment #63)


> At save is not a good time for compression: 
> Users won't have an idea that compresion will happen and informing them

No one here is asking to inform users. The concern has always been that destructive edits belong at the very end of the work flow. 

> Users have different habits and use save at different times. Some save
> frequently after every action, so they could insert, resize too much, save
> and then realize the image should be bigger.

This is just an argument for having conservative(high) DPI defaults. This has nothing to do with save time or insert time compression. 


> could be in a hurry and save, close LO, then after a while open and realize
> the images are compressed and it is not what they want.

This is not a problem in MSO and if it's a problem in LO, we're doing something wrong. Users do not expect destructive edits to happen without them asking for it. Word does not crop images, does not resize < 220 dip images, does not recompress unless the user request that at save. And if the user Checks "Do not compress images in file" Word does no destructive edits on save. 

This the right way to handle document wide resizing, compression, and cropping. 

 
> MSO even doesn't show the result after save - as long as you keep the
> document open, it will show the original.


Because MSO doesn’t do destructive edits implicitly (assuming you don't have massive files). It’s not a normal “save”. To compress your document, You have to click Save →Tools → Compress Picture. All of these occur at the end of the work flow, when you can think about your target audience.  

> We don't want to use a workflow that
> silently does compression or potentially could compress to a lower DPI than
> specified.

Most users insert images by dragging and dropping. How is this not silently compressing? 

Silently compressing and resizing images is what we are all concerned about. 

> Additionally we want the user to have the control and the ability
> to decide on case-by-case basis.

So you want to put the destructive edits at the front of the work flow where they can happen silently by a drag an drop?  Do you really think anyone knows the compression level they will need while their still creating the document? 

That's now how it works in the real world. People work with the highest reasonable quality to create a master. When they are ready to share, they want to resize/re compress their images to the target file size/output media.

The correct way to implement this feature is with a document minimizer like we do with Impress.

(In reply to Luke from comment #70)
> No one here is asking to inform users. The concern has always been that
> destructive edits belong at the very end of the work flow. 

Yes, but you can't guarantee that when you hit save it is the end of the workflow. I hit save all the time and I'm not the only one.

> This is just an argument for having conservative(high) DPI defaults. This
> has nothing to do with save time or insert time compression. 

This is all about the workflow. I'm demonstrating that it is not guaranteed save time is the end of the workflow and that there are scenarios where you could end up ruining your picture (by mistake lowering the DPI more than you wanted). 

> This is not a problem in MSO and if it's a problem in LO, we're doing
> something wrong. Users do not expect destructive edits to happen without
> them asking for it. Word does not crop images, does not resize < 220 dip
> images, does not recompress unless the user request that at save. And if the
> user Checks "Do not compress images in file" Word does no destructive edits
> on save.
 
If image is more than 220 DPI what do you think Word does with the image when you hit save? 

It takes the original, shrinks the image down to the 220DPI (by default) and compresses again (with JPEG). What q setting does it use? What interpolation algorithm does it use to shrink down? Who knows...

Everything else what you said Word (actually MSO as this is true for the whole suite) doesn't do we don't plan to do either. All this has been from the beginning a talk to resize and recompress when the image has a DPI larger than X (by default 300DPI + some margin), but instead of constantly doing it at save with not showing the final result until the next time the user opens the document, we want to do it one time at insert and show it right away. 

If you will disable image compression - the per document setting - LO won't do any destructive edits on insert too, and revert the images to original size (if still in the original session).

> Because MSO doesn’t do destructive edits implicitly (assuming you don't have
> massive files). It’s not a normal “save”. To compress your document, You
> have to click Save →Tools → Compress Picture. All of these occur at the end
> of the work flow, when you can think about your target audience.  

OMG .. we don't want to recompress every image - only massive images. Again .. save time is not the end of the workflow.

> Most users insert images by dragging and dropping. How is this not silently
> compressing? 

It is, but you see the result of the compression. Inserting image and hitting save without showing the compressed image instead - how is that not silently compressing?

> Silently compressing and resizing images is what we are all concerned about. 

Me too... even more than you.

> So you want to put the destructive edits at the front of the work flow where
> they can happen silently by a drag an drop?  Do you really think anyone
> knows the compression level they will need while their still creating the
> document? 

Who cares. As long as the result of the compression is not visible and we end up with smaller documents. That's all about. For those who care - turn it off and trigger it manually at the end.

> That's now how it works in the real world. People work with the highest
> reasonable quality to create a master. When they are ready to share, they
> want to resize/re compress their images to the target file size/output media.

Again describing the professional workflow. That's not the concern of most users.

> The correct way to implement this feature is with a document minimizer like
> we do with Impress.

That's what we plan to add too, in addition to the automatic insert time compression of massive images.

(In reply to Tomaz Vajngerl from comment #69)
> Come on.. get real. You know full well that the amount of users who will
> send documents to professional printers that use LO is very very low. Such
> people will turn this off...

This at the core of problem here. I am looking at my company’s sharepoint marketing folder now and the majorities of files are .docx and .pptx files. Yes there are plenty of Adobe formats in here to, but the sales and marketing material that’s meant to be shared in our company is mostly in MSO formats. 

Many of are here because we are professional users that care about the quality of our work. So we create large, high quality documents and then compress them when it’s time to share. This is a feature MSO has had for as long as I can remember and what users here want and in the linked bug reports.

However, it seems that Yousuf and Tomaz do not envision us as the target audience, and at the same time you want to workaround another bug in LibreOffice's graphics system by silently resizing large images(at least by drag and drop which is how most users insert images). 


Instead of resolving this issue with a manual option, you want to expand the scope to something automatically done in the background. If LibreOffice's target audience are grandmothers making cookie recipes to share with their church, silently applying lossy compression and resizing images makes sense. If our target are professionals, you should never apply lossy compression and destructive edits unless the user requests it.

Finally, I do not think Word works the way Yousuf and Tomaz thin it works. 

I unchecked "do not compress images". Restarted Word. Added a 10MB jepg image. Saved and closed. The resulting file was 10MB+100k. I shrunk the image on screen. Saved and closed. The resulting file was still 10MB+100k. I manually ran the compress wizard. The resulting file was 17k after saving. This tells me Word actively avoids destructive edits unless the user specifies it. This is the correct behavior for business software.


10 MB test file for you to try yourself:

https://upload.wikimedia.org/wikipedia/commons/f/ff/Pizigani_1367_Chart_10MB.jpg

Hi Joey,


trying to understand:

(In reply to Joey Reid from comment #72)

> ... So we create large, high quality documents and then
> compress them when it’s time to share. 

What is the sense of having documents with large size images and then compress when sharing? Is there also another use of the files where the uncompressed images are needed?

And could that be covered by a configuration where the auto-compress is turned of and you can choose to do it on command?

(In reply to Joey Reid from comment #72)
> This at the core of problem here. I am looking at my company’s sharepoint
> marketing folder now and the majorities of files are .docx and .pptx files.
> Yes there are plenty of Adobe formats in here to, but the sales and
> marketing material that’s meant to be shared in our company is mostly in MSO
> formats. 
> 
> Many of are here because we are professional users that care about the
> quality of our work. So we create large, high quality documents and then
> compress them when it’s time to share. This is a feature MSO has had for as
> long as I can remember and what users here want and in the linked bug
> reports.

We will add an option to manually trigger compression too.. as stated by Heiko already since the beginning. If you don't want automatic compression, turn it off and do it manually when you want.

> However, it seems that Yousuf and Tomaz do not envision us as the target
> audience, and at the same time you want to workaround another bug in
> LibreOffice's graphics system by silently resizing large images(at least by
> drag and drop which is how most users insert images). 

No, we don't want to work around that bug with this.

Any kind of insert..

> Instead of resolving this issue with a manual option, you want to expand the
> scope to something automatically done in the background. If LibreOffice's
> target audience are grandmothers making cookie recipes to share with their
> church, silently applying lossy compression and resizing images makes sense.
> If our target are professionals, you should never apply lossy compression
> and destructive edits unless the user requests it.

Professionals, turn this off and trigger it manually. That was our statement from the beginning.
 
> Finally, I do not think Word works the way Yousuf and Tomaz thin it works. 
> 
> I unchecked "do not compress images". Restarted Word. Added a 10MB jepg
> image. Saved and closed. The resulting file was 10MB+100k. I shrunk the
> image on screen. Saved and closed. The resulting file was still 10MB+100k. I
> manually ran the compress wizard. The resulting file was 17k after saving.
> This tells me Word actively avoids destructive edits unless the user
> specifies it. This is the correct behavior for business software.
> 
> 
> 10 MB test file for you to try yourself:
> 
> https://upload.wikimedia.org/wikipedia/commons/f/ff/Pizigani_1367_Chart_10MB.
> jpg

https://www.youtube.com/watch?v=48XfKuPCCTk&feature=youtu.be

(In reply to Joey Reid from comment #72)
> However, it seems that Yousuf and Tomaz do not envision us as the target
> audience

We always have two target audiences with LibreOffice, those who never change defaults (regular users) and those who change defaults (professional users). We have these two type of users in our UI guidelines as Benjamin and Eve.[1] So for Benjamin, someone who doesnt know or care about lossy compression, we compress his images by default so he has smaller files. For Eve, someone who may want to retain the original images that were inserted, we give her the option to enable/disable this option globally, as well as enable/disable this option per file in the insert image dialog and the file properties dialog.

[1] https://wiki.documentfoundation.org/Design/HIG_foundations#Persona

> and at the same time you want to workaround another bug in
> LibreOffice's graphics system by silently resizing large images

Whether the bugs in the graphics system are fixed or not, optimizing images automatically benefits Benjamin, but with the graphic system bugs still being around, its a greater benefit, especially when he's running a slower system.

> (at least by drag and drop which is how most users insert images).

Do you have some proof to backup this claim? I've never inserted in image by drag and drop in a word processor and know friends and family who dont either (primarily because they dont know it has the feature). Unless the image is on the desktop or the user already has the file manager open at the folder where the image is, dragging and dropping wouldnt be the most efficient means of adding an image to a document.

> Finally, I do not think Word works the way Yousuf and Tomaz thin it works. 

Well it does, as Tomaz provided in the youtube screencast in comment 74, so you must have done something wrong with your testing. If you still disagree, please attach a screencast so we can see your results.

The simple fact is that if optimization is set on a document, the user visually seeing it happen after inserting it into a document is the best way to notice and fix the issue, rather than a user only noticing it after reopening the document, as MSO does, and possibly after they have already gotten rid of the originals.

As stated before, those who want to discuss this should come to the design meeting this Thursday where people's point of view can clearly be heard and discussed, which cant be done with constant back and forth in comments.

Really interesting discussion.
I think the "2 options" workflow is nice : 

- automatic compression to xxx dpi when inserting images ... with ability to disable it (perhaps I'm a freak, but I never use drag & drop to insert image, almost always Insert -> Image or copy / paste from Draw or Gimp)

- a option to compress all images to xxx dpi when saving the document.

The xxx dpi must be a option because sometimes 220 dpi is enough.

Oh, and what will happen when I will resize the image in Writer if the "automatic compression on insert" is enabled ? If I decrease the size ... or increase it ?

I drag and drop files to insert, so I'm one of the users affected by this change. In this case, we should not silently resize or recompress images until
 
* The user has explicitly asked for it with a manual compress
* We have notified the user with a popup or overlay
* Or the user saves the document. 

For non-professionals, resizing and recompressing high DPI images automatically as long as it's not done without the user's knowledge is a good idea.  My concern has always been that we must take care to not do this without the user’s knowledge. This is only fair to the users because it is what they expect. At least with all the software I’m familiar with, destructive edits always occur at save time or when explicitly requested.

(In reply to Nicolas R from comment #76)
> - automatic compression to xxx dpi when inserting images ... with ability to
> disable it (perhaps I'm a freak, but I never use drag & drop to insert
> image, almost always Insert -> Image or copy / paste from Draw or Gimp)

You know there is an insert image button in the toolbar right? :D

> - a option to compress all images to xxx dpi when saving the document.

Yes if optimization was disabled in the document, you could then enable it in the file properties dialog and then save the document and then all images would be optimized at that time.

> The xxx dpi must be a option because sometimes 220 dpi is enough.

Yes 300, 220, 200, 150 and 96 would be available options.

> Oh, and what will happen when I will resize the image in Writer if the
> "automatic compression on insert" is enabled ? If I decrease the size ... or
> increase it ?

It will be optimized once at a specific dpi when you insert it and wouldnt be optimized again.

(In reply to Yousuf Philips (jay) from comment #78)
> It will be optimized once at a specific dpi when you insert it and wouldnt
> be optimized again.

Since we don't know whether the user will increase or decrease the size of the final image, for drag-and-drop images it should not be optimized unless the user explicitly compresses it.

This would be a very powerful feature to add.  It would make the workflow for many document creators so much quicker.

I prepare lesson plans and worksheets for English learners, I use many documents, sourced from many places.  Always, the source image is much bigger than I need.  It would be great to be able to set all images file size based on the resized images at once.

Changing bug priority back to high since the number of people in CC is higher than 20

My use case (engineer writing technical documents). The moment that LO starts to compress inserted images without my consent or feedback as a default setting I will instantly rage-quit LO and prevent it's use in my company. Destrutive saves is exactly what I hate about MS Office (until you find Options -> Advanced -> Never Compress)

Most sensible, if people really see large documents coupled with non expert users as being a problem: see that a graphic is "large" (e.g. over 2MB, or more than 300dpi after the user has rescaled it) - then offer some kind of feedback to ask the user how they would like to proceed.
Alternatively have a "shrink document" option when saving.

@ comment #83 I think it is a bad translation issue to have "automatically" in the title. The initial comment says "it should not be automatic". Instead what I understand the desire of this feature request is to have a single button / menu command that would compress / resize ALL images in a document, instead of painfully going through and doing it individually for 50 images (for example) in a big document.

So I propose removing "automatically" from the title, and adding "all images in document"

(In reply to Rik Shaw from comment #84)
> @ comment #83 I think it is a bad translation issue to have "automatically"
> in the title. The initial comment says "it should not be automatic". Instead
> what I understand the desire of this feature request is to have a single
> button / menu command that would compress / resize ALL images in a document,
> instead of painfully going through and doing it individually for 50 images
> (for example) in a big document.
> 
> So I propose removing "automatically" from the title, and adding "all images
> in document"

Yes, I totally agree.  It would greatly improve workflow for all users who create documents with lots of images if there was an option to, manually, set image compression across the whole document in one step.  While also leaving the option to choose compression for images individually.

Basically a batch option for compression that can be switched of and on.

Issue #107875 is a duplicate of this one. 

Please allow user to reduce file size by resizing and or compressing all images in one step if desired but do not automatically resize/compress all images by default.

My experience is that most people adding images to writer doesn't have the knowledge about how pictures work, as said in comment 2. Files get very heavy and is very tedious to reduce file size when validating the document...

*** Bug 132652 has been marked as a duplicate of this bug. ***

Created attachment 176325 [details]
mockup from Bug 107875

From both an ease of use and implementation perspective, this seems like the simplest approach to me.

Created attachment 176370 [details]
mockup proposal in a moderate way

The "if resolution is above" option would also prevent the file size to increase or prevent the quality to decrease or both a the same time.

*** Bug 82951 has been marked as a duplicate of this bug. ***

https://extensions.libreoffice.org/en/extensions/show/imgcell-1

What about relying on extensions?

I think optimizing the dpi of an image is a basic feature expected for Writer, Draw, Calc. Competitors do it.

This could be an advantage of Base.

For Impress, perhaps we should consider the target number of pixels on the screen rather than the dpi (although used for slide printing).

I'd desperately love it too!

As per comments 83 to 85, it would be great to have such a batch compressing and possibly a check feature to quickly see if a compression is required (some new image added for instance).