Created attachment 175769 [details] image compression form When you change the image file format form a lossless format into a lossy format and vice versa, then the file size may increase and the image quality may decrease. In the 7.2.1.2 version, the image compression form always select the jpeg format, even if the former file format is PNG.
You filed bug 145160 and bug 145161 probably without searching existing bugs first. Please do and see if a duplicate, seems bug 119634.
(In reply to Timur from comment #1) This bug isn't a duplicate of bug 119634 because it isn't related to PDF export.
See bug 77407 comment 9.
Duplicate of bug 146929? The settings will be remembered across the session.
Writer was a duplicate of fixed bug 146929, but since Impress was also mentioned, I change to Impress and set New.
This problem still appears with 7.2.5.2.0 version in Impress, Writer and Draw. The issue is that the selected image format isn't by default the image format of the source image which has to be compressed. If I open the image compression form, it should automatically change the selected output image format : - if the former image type is png, then select png by default for the compressed image, - if the former image type is jpeg, then select jpeg by default for the compressed image. Next the user can change the image ouput image format before clicking on the "ok" button.
(In reply to Jérôme from comment #6) > This problem still appears with 7.2.5.2.0 version in Impress, Writer and > Draw. Did you not see that Writer was fixed, of course in master 7.4+? So 7.2 is not relevant for changing the title. Just wait.
Confirming that my patch isn't working with Impress, yet. Adding the missing piece. Regarding the detection whether the source is JPEG or PNG and to use the correct algorithm: a) I wonder if the internal bitmap has any relation to the source; the compression algorithm can obviously used at both. But more relevant is b), if we want to remember user settings we cannot pick a default here. So I make this ticket a duplicate and will submit a patch for the missing bit. *** This bug has been marked as a duplicate of bug 146929 ***
Back to NEW following the discussion in bug 146929. The compression type should be excluded from what we remember as user choice and m_xLosslessRB or m_xJpegCompRB set active depending on the original format. It's an easy hack, see svx/source/dialog/compressgraphicdialog.cxx (and https://gerrit.libreoffice.org/c/core/+/129894)
Images can be compressed in Calc too.
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, ...). Thus I mean this report isn't just an enhancement proposal. It proposes to avoid the ODF file size to increase when an image is "compressed" with this dialog.
@Ruslan: In addition to changing the bug status to ASSIGNED, please also assign the bug to yourself. Now, I've done this for you.
See bug #98932. The form of compression must be retained if the old image used indexed colours : - retain indexed colours if they were indexed, - apply the user's global preferences if they were not indexed.
Hi, I am Asif and am interested in implementing this easy hack. It would be helpful if you could clarify following things: 1. If the compression type is set by default to the original format of the image , won't it conflict with user preference the next time the user opens some other image(in the same session
(In reply to Asif from comment #14) > Hi, I am Asif and am interested in implementing this easy hack. > It would be helpful if you could clarify following things: > > 1. If the compression type is set by default to the original format > of the image , won't it conflict with user preference the > next time the user opens some other image(in the same session From what I see, the decision is laid out in comment 9. Of course it might not be optimal for every single scenario, but it seems like the best default. By "conflict with user preference", I assume you mean the expectation in the user's head.
Yes. If the user wants the same compression type to be used for every image during the session regardless of the format of image, this new feature would conflict right?
(In reply to Asif from comment #16) > Yes. If the user wants the same compression type to be used for every > image during the session regardless of the format of image, this > new feature would conflict right? The current behaviour selects the same compression type for every image. This inflates the file size and decrease the images quality when mixing lossless or lossy compression format of former images. If the user want to select the format depending on each former format, this infers a cognitive overload. If we implement the behaviour which selects the compression type depending on the former image format : - if the user always wants the same format, they must always select the button in the same place without cognitive overload, - if the user wants the most efficient format in terms of size and quality, they don't have to do anything. So, from the user's point of view, selecting the most efficient format by default is a good compromise.
Thanks it is clear now
I'm marked as a reviewer for the patch that Asif pushed to gerrit (180758). However, I haven't mastered the internal workings of Libreoffice. Could some someone else review this patch ?
(In reply to Jérôme from comment #19) > I'm marked as a reviewer for the patch that Asif pushed to gerrit (180758). > However, I haven't mastered the internal workings of Libreoffice. > Could some someone else review this patch ? Please always include the full link to a patch instead of just an ID. This saves a lot of time. https://gerrit.libreoffice.org/c/core/+/180758 Easy hack definer is Heiko, so he should be added as a reviewer.