GIMP 1bit PNGs (with metadata) bug #159
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Hi,
When I convert 1 bit (black and white only) PNGs created by GIMP they become much larger than the orginal.
I think its because the metadata saved with the file is causing the bug.
The metadata are the
defaultmetadata that GIMP offered to save PNGs with.PNG with metadata
1bit.png 74,0651 bytesConverted to PDF (much larger):
1bit.pdf 172,594 bytesPNG but no metadata
1bit_no_metadata.png 69,971 bytesConverted (correct size):
1bit_no_metadata.pdf 71,352 bytesEDIT: Actually for the no-metadata PNG there was some metatdata saved: the image resolution.
Software details
GIMP 2.10.34
img2pdf 0.4.4
Debian Testing (12 Bookworm)
Conversion logs
PNG with metadata:
PNG with no metadata:
GIMP 1bit PNGs (with metatadata) bugto GIMP 1bit PNGs (with metadata) bugI think the bug may be due to the colorspace used.
I tried forcing the colorspace using the
--colorspaceoption.Surprisingly forcing the Black and White colorspace results in a PDF thats too large (the input PDF is a 1 bit Black and White image).
But forcing a Grayscale colorspace results in a correclty sized PDF!?
(The input PNG has metadata)
Why does forcing the correct Black and White colorspace casue a larger PDF?
img2pdfseems to be using aTiffImagePlugin(on a PNG) is that part of the problem?These errors are at the end of the Black and White colorspace conversion log:
Fax3SetupState: Bits/sample must be 1 for Group 3/4 encoding/decoding. DEBUG:img2pdf:encoder error -2 when writing image file DEBUG:img2pdf:Converting colorspace 1 to LFull conversion logs
Force Grayscale colorspace (result is correct sized PDF)
Force Black and White colorspace (result is a too large sized PDF)
I did some more tesing and the metadata that is triggering the bug seems to be GIMP's "Save color profile" option. GIMP's default PNG options don't have that selected, but including a color profile is part of the offical PNG spec.
Hi, could you share a png image that causes this so that I can reproduce this problem? Thanks!
Is your bilevel png image just a palette png with only 2 palette entries? The png format itself does not support bilevel images natively.
The reason the TIFF plugin comes into play is because the CCITT fax encoding compresses bilevel image data much better than the png paeth filter does.
I've pushed some commits which will not include the ICC profile saved by GIMP for bilevel images. See #164 and https://gitlab.gnome.org/GNOME/gimp/-/issues/3438 for details.
Can you confirm that fixes this issue and then close it if it does?
Sorry for the delay.
I've attached the files that I used in my first comment.
(Attached as zip file,
not sure if that will work here?)PNG with metadata
1bit.png 74,0651 bytesConverted to PDF (much larger):
1bit.pdf 172,594 bytesPNG but no metadata
1bit_no_metadata.png 69,971 bytesConverted (correct size):
1bit_no_metadata.pdf 71,352 bytes(Note that
1bit_no_metadata.pngactually has resolution metadata.)I think so. To create a bilevel image in GIMP I use
Image > Mode > IndexedColormap > Use Black and White (1-bit) paletteI also have this selected
Remove unused and duplicate colors from colormapin the same dialog.I'm not very competent with compiling apps. I just run with what's in my distribution's repository. But I'll take a look into it.
Aha, whoops, sorry, when you wrote:
I thought that I had to wait for a follow-up. Sorry for the misunderstanding! :)
I now looked into it a bit more and I'm able to confirm your observation and understand the problem. This is indeed another instance of the GIMP bug https://gitlab.gnome.org/GNOME/gimp/-/issues/3438 but this time for PNG images and not for TIFF images. My solution for issue #164 only covered TIFF images and thus this issue is not fixed.
The PNG format supports 1-bit (bilevel) grayscale images but that's not the kind of image produced by GIMP. Instead what you showed here are palette images but with only two colors in the palette: black and white.
So the solution to this problem would be to add some code similar to what was added for TIFF which auto-detects palette PNG images with only two colors as they are created by GIMP and drop the ICC profile for those.
Here is a patch that should work:
tl;dr I'm not comfortable using PIP.
I should have replied back. I don't understand PIP and what it does and what changes it makes to a system.
I've seen a few warnings about PIP being risky and a potential source of malware (obviously not your code).
I'm short of time at the moment (who isn't?!) so I can't dig into PIP some more and try to figure out what it does and what its risks are (and if I'm honest I'm not sure I want to!)
I'm not a developer, just a Linux user who has had to look under the hood a few times.
@monobot no problem! I just wanted to give you the opportunity to test if those changes do what you expect. That way we reduce the chance of me fixing something that is not really the problem you observed. If you don't want to try out the diff I posted for whatever reason that's totally fine. I think and hope the diff fixes what I understood as your problem. It is obviously not your responsibility to test any diff.
I'm happy you reported this problem and hope that this is fixed with the next release!
If you don't use pip, where do you obtain img2pdf from?
@josch. Thanks for giving me the chance to test the changes.
It's not that I don't want to test the changes, it's I'm not able to!
PIP is totally new to me and I've no idea what it does (and more importantly what it does behind the scenes).
I install img2pdf using Debian's
aptinstaller.I just run
sudo apt install img2pdfand it gets installed.Is pip a common way for regular users to install apps? I thought it was more for developers.
Thanks for working on this issue. And thanks for img2pdf, it's an extremely useful app.
Then you are in luck: I'm also maintaining the img2pdf package in Debian so once I release a new version here I'll also upload that version to Debian unstable. :)