[Libreoffice-bugs] [Bug 34133] Add ability to automatically compress and resize images

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=34133

Yousuf Philips (jay) <philipz85 at hotmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rb.henschel at t-online.de,
                   |                            |vstuart.foote at utsa.edu

--- Comment #66 from Yousuf Philips (jay) <philipz85 at hotmail.com> ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20170511/6ab2c2a1/attachment.html>