Thank you for your report!

IMHO this is a valid and very reasonable feature/enhancement request, therefore set Status to NEW.


> (I wanted to file this idea as a feature request but I did not know how and
> where to send FRs instead of bug reports. :))

That’s simple ;-) : just do what you did (file a bug), but set the ”Importance” field of the bug report to “enhancement”. (If this is not possible directly in the bug submission assistant, do it finally on the bugzilla page.)

@ Kendy and Tomaz Vajngerl:

Hi Kendy, hi Tomaz,

you have done some important improvements to the image resampling/interpolation code in LibreOffice. Do you see any chance to implement this enhancement request (adding an UI for choosing the interpolation/rescale methode), at least partially? This would be a big progress, also in comparison to MS Office ... So please consider this.

Thank you very much!

Hi,

I can now offer you a workaround for this. In LO 4.0 I added "Compress Graphic" function to Draw, Impress and Calc. In master (to be 4.1) it is also available in Writer. With "Compress Graphic" you are now able to actually resize the picture to current "view" size (this is the default) and if the picture is smaller it will enlarge it. In "Compress Graphic" you have the possibility to choose the interpolation method. If you select "None" the QR code in the example document will become sharp. This is not the exact solution to this problem but I think it is a easy workaround.

Regards, Tomaž

(In reply to comment #3)
> Hi,
> 
> I can now offer you a workaround for this. In LO 4.0 I added "Compress
> Graphic" function to Draw, Impress and Calc. In master (to be 4.1) it is
> also available in Writer. With "Compress Graphic" you are now able to
> actually resize the picture to current "view" size (this is the default) and
> if the picture is smaller it will enlarge it. In "Compress Graphic" you have
> the possibility to choose the interpolation method. If you select "None" the
> QR code in the example document will become sharp. This is not the exact
> solution to this problem but I think it is a easy workaround.
> 
> Regards, Tomaž

Real great improvement, because imho it was a great lack regarding MsO (in our compagny many users create "composite" text documents with writer).
Any chances to have "compress graphic" menu in writer backport to 4.0 branch, or is it technically a tough work ?

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ž

(In reply to comment #5)
> 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ž

Ups..

Disregard this comment - it was meant for bug [1]. Sorry!

Backport to 4.0 branch can be problematic. I will analyze if it didn't change too much.

[1]: https://bugs.freedesktop.org/show_bug.cgi?id=34133

(In reply to comment #6)

> > - ability to compress all images in the document (only DPI makes sense in
> > this scenario)
> 
> Ups..
> 
> Disregard this comment - it was meant for bug [1]. Sorry!

No, no, no ... no disregard. Really interesting ideas , especially, imho, ability to compress  all images in "one click". This feature is a real lack  for some users in our company (comparing with Word). They "love" to include many pictures in their documents ...
> 
> Backport to 4.0 branch can be problematic. I will analyze if it didn't
> change too much.
> 

Ok! If I dare : don't waste to much time on this backport and stay focused on your improvements ideas... ;-)

Hi All, 

Compressing images is a great thing but this feature request was not about this. I wanted to set how the image should be rescaled when displaying. I tried it in LO 5.0.3.2. I did the following steps:

- Open a new LibreOffice text document
- Create a 2x2 pixel image in Gimp, a black-white checkboard and copy it to the clipboard
- Edit -> Paste Special -> Bitmap
- Right click on the image -> Compress Image
- Compression Options: Lossless compression, Compression=9, untick "Reduce Image Resolution" unchecked
- Resize the image by the green control points
- ??? The result is a blurred image
- Right click the image again -> Compress Image
- ??? Instead of Lossless, still JPG is selected
- I adjust Lossless and 9 again
- Width=2, Height=2, Interpolation=None, OK
- ??? the image is still blurred

The only way how I can scale the image with keeping unblurred pixels is to set the dimensions manually, for example 200 instead of 2. This is not good because of the following reasons:
1. The saved odt document will store the enlarged (200x200) picture instead of the original (2x2) which is a waste of resources.
2. I have to set the new width to n*original_width and n*original_height where n is an integer to keep unbiased pixels. Defining inaccurate new width and height would distort pixels.

The best would be to have a new menu item called "Display Image" right below the Compression Image in the local menu. It would allow to choose between the following options:
- Uninterpolated
- Interpolated - Bilinear
- Interpolated - Bicubic
- Interpolated - Lanczos

What so you think?

I want to add a use for this enhancement request.

I work with computer graphics and want to document how pixels are processed, and often include tiny cutouts of a sample image wich I need to blow up to a viewable size. The blurry upscale method used to render images today gets in the way, cause I need to keep a pixel square and clear.

As a minimum, I could manage with a checkbox to use "nearest neighbor" interpolation/scaling method instead of the default.

This request should also be included for Impress, Calc and all other documenting components, so I'm taking the liberty to change the component to LibreOffice in general.

My current platform is LibreOffice 5.0.4.2 (run on Win10, but I know this is a general issue).

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

I am not sure Bug 101212 is the duplicate of this one. That one is about displaying incorrect values in the Original Size information. This bug is completely different, this is about configuring what rescaling method to use. 

I can imagine that the developer who solves this bug is able to fix that one as well but I think these bugs are only related ones, not duplicates of each other.

By the way, this bug needs several things to solve (starting from the user's perspective):

- changing the dialog to adjust/reflect what rescaling method is used if my 2x2 pixel image stored in the document has to be displayed/printed in 10x10 centimetres
- store the chosen algorithm in the in-memory data structure of LO
- store the chosen algorithm in the ODT file if it gets saved and restore it from there
- extending the ODT file format specification to be capable to store it in the file in a standard way
- adding some macro interface to make in able to be manipulated
- everything else I forgot to enumerate above. :)

So, this enhancement can be pretty complicated but I still think - four years after it came up at first - it should be done.

As the original reporter of Bug 101212, I concur with csongor@halmai.hu : both bugs are related (they concern the same component), but not exactly duplicates:
- Bug 56468 originally was about being able to choose the rescaling algorithm.
- Bug 101212 is more about the "metrics" of re-scaling.
(Especially present when cropped images are re-scaled)

However, it makes sense to group them if the component is re-written, especially in the light of some comments here that I found here:

> DPI calculation of cropped images is not working correctly
This is not only true with cropped images - calculation of DPI of re-sampled images is often incorrect (see 101212). Re-sampling cropped images come with the additional problem that the cropped boundaries are often not properly scaled.

> Store the chosen algorithm…
Indeed, the dialog box should "remember" (could also be settable with LO preferences) the chosen settings for re-sampling: algorithm, but also image quality (DPI and jPEG quality setting), as these are often chosen same for a given document, depending on its use.

Here's another example of how it could be useful: bug 87450 shows in attachment 110994 [details] an imported SVG chart with an embedded upscaled heatmap: large coloured squares that should be displayed sharp and not rescaled.