Created attachment 182201 [details]
A 1 bit monochrome PNG.

Created attachment 182202 [details]
The exported PDF which has an rgb image instead of monochrome

Confirmed on Windows

Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: dc92a4d973086ce8a6a5f75ba0f4d4c9ca05537a
CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded

I will look into this issue later today

(In reply to Paris Oplopoios from comment #4)
> I will look into this issue later today

No need - it's not related to PNG export anyway.

This issue is "by design" - at least partially. I'm not sure it can be addressed in the short term at least. 

The new libpng based PNG reader doesn't read to a 1-bit and other palette based Bitmap formats anymore. This is generally to minimize the number of esoteric Bitmap formats we need to support and to improve the performance as the back-ends don't support palette surfaces in general anymore.

So what happens in this case is that we read in the 1-bit PNG into Bitmap, but as we don't want 1-bit Bitmap, we just enable the switched in libpng to convert from 1 to 8bit and from palette to RGB. The result of that is that we read-in an 8-bit RGB Bitmap. Then at PDF export we can't just reuse and store the PNG, which is still associated (I think), because PDF uses it's own lossless format, so we instead look and write the content of the Bitmap - which will be RGB 8-bit.

What we can do here is to check the original PNG file or store some "origin" information into the Bitmap class, and then convert the Bitmap to a palette based 1-bit Bitmap (which shouldn't cause any loss of information).

(In reply to Tomaz Vajngerl from comment #6)
> What we can do here is to check the original PNG file or store some "origin"
> information into the Bitmap class, and then convert the Bitmap to a palette
> based 1-bit Bitmap (which shouldn't cause any loss of information).

We do keep the original 1bpp image, placing it in the ODF archive's Pictures directory.

For now though, the resulting PDF is simply larger bcz of embedding an 8bpp bitmap into a stream. But do we need to generate PDF with 1bpp images? 

Other than size of the PDF what is the justification? I guess for "fidelity" to the original--but then PDF is a presentation format not an exchange format. The 8bpp grayscale will look better than 1bpp. 

And in this sample we're working with the full image on document canvas--what happens when the original image has been masked, clipped or otherwise edited (i.e. image filtered). An 8bpp or 24bpp image is going to be required then, right?

So unless this is really easy, then reasonable to => WF

> I guess for "fidelity" to the original--but then PDF is a presentation format not an exchange format. The 8bpp grayscale will look better than 1bpp.

This is actually quite important. When sending things to print it is important to preserve 1 bit images as such. They are printed "directly" whereas grayscale and RGB images are interpolated causing the edges between black and white to become blurry.

At the very least LO should convert the 1 bit image to grayscale, not RGB.

I agree that in general indexed images are not worth supporting. However 1 bit images are an exception here, because they have widespread still today.

A practical example. Suppose you have a document that has a line art illustration with cross hatching and the like. You _really_ want to print that so that all edges remain sharp, otherwise it will look mushy and ugly. The only way to guarantee this is to put a 1-bit image in the PDF. If it is in grayscale or RGB you are at the mercy of the RIP. If it has code that detects RGB and grayscale images that "happen to be" monochrome you might get crisp looking output. But it's a lottery at that point.

(In reply to V Stuart Foote from comment #7)
> We do keep the original 1bpp image, placing it in the ODF archive's Pictures
> directory.

Yes, the original is available, but you don't put PNG inside PDF - so reading again would again produce a 8-bit RGB Bitmap. 
 
> For now though, the resulting PDF is simply larger bcz of embedding an 8bpp
> bitmap into a stream. But do we need to generate PDF with 1bpp images? 

No - I don't think so.

> Other than size of the PDF what is the justification? I guess for "fidelity"
> to the original--but then PDF is a presentation format not an exchange
> format. The 8bpp grayscale will look better than 1bpp. 

It will look exactly the same - no matter if it's 1bpp or 8bpp.
 
> And in this sample we're working with the full image on document
> canvas--what happens when the original image has been masked, clipped or
> otherwise edited (i.e. image filtered). An 8bpp or 24bpp image is going to
> be required then, right?

If the Bitmap is changed in any way (resized for example), it's converted to 24-bit RGB. If it's just metadata (crop for example) then it depends - not sure what happens with PDF. 
 
> So unless this is really easy, then reasonable to => WF

Well, it's an issue, but low priority.

(In reply to Jussi Pakkanen from comment #8) 
> At the very least LO should convert the 1 bit image to grayscale, not RGB.

This should be possible by fudging the PNG importer[1] to create such a Bitmap. The problem is 1-bit doesn't necessarily mean black and white... it can be for example red and green, so you need to detect that it is actually black and white (or that both are a gray value).

[1] vcl/source/filter/png/PngImageReader.cxx

The issue is still present.

Version: 24.8.2.1 (X86_64) / LibreOffice Community
Build ID: 0f794b6e29741098670a3b95d60478a65d05ef13
CPU threads: 16; OS: Linux 6.11; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Flatpak
Calc: threaded