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

bugzilla-daemon at bugs.documentfoundation.org bugzilla-daemon at bugs.documentfoundation.org
Fri May 12 09:48:24 UTC 2017


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

--- Comment #69 from Tomaz Vajngerl <quikee at gmail.com> ---
(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.

-- 
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/20170512/62635e63/attachment.html>


More information about the Libreoffice-bugs mailing list