Should be able to read from stdin, write to stdout, messages must not go to stdout
I've been unable to get this program to work in a way which is compatible with other Unix-oriented image processing tools such as netpbm. This should really support reading from stdin and writing to stdout. To support common usage, all messages should go to stderr, not stdout.
If you are open to the possibility of proper stdin/stdout/stderr support, I will create a PR.
Thank you for your suggestion! I'm not very familiar with netpbm and Unix image processing tools. I'd really appreciate your help. If you're willing to submit a PR, that would be fantastic!
I started working on this. I'll work my way up to a PR, maybe in a day or so, but to start, I forked and commited a couple changes. They are pretty straightforward, I think, one to force prints to stderr, one to expand the tested Python versions. I keep 3.10-3.14 (main) sandboxes locally and have a 3.9 Tox was able to find, but no longer have 3.7 or 3.8 on-disk.
Future commits are a bit less obvious, but since PIL.Image.Image accepts open file objects as well as strings representing paths, it actually wasn't too hard to edit, assuming I deleted the code which relies on file extensions to determine input and output file types.
It is reasonable to limit testing to Python 3.1x, as maintaining support for older versions is not always feasible.
The file extension check demonstrates the functionality of this package by verifying if the provided file is a HEIC image.
Like this:
if self.image_file_path.suffix.lower() != '.heic':
raise ValueError("The provided file is not a HEIC image.")
This feature may become less significant over time, as the package primarily functions as a format converter. Moreover, its utility will extend beyond HEIC files in the future.
Passed on my old Dell, with 3.10 and 3.12. FYI, the 3.13 version on my Mac is compiled with GIL disabled. I get the requisite warnings about grabbing the GIL for PIL (which hasn't announced support yet).
The file extension check demonstrates the functionality of this package by verifying if the provided file is a HEIC image.
Maybe I should make that check conditional on the user supplying an input file? I'll tweak the code for this.
That PIL is used for the conversion does kind of ~~loosing~~ loosen the HEIC-to-PNG constraint though. Your call.
We need to regulate user input. Thank you for making the necessary adjustments.
In my view, "HEIC-to-PNG" serves merely as the title of this tool. Although its primary focus is on HEIC files, extending support to additional formats is a wise decision, especially considering that PIL already offers such functionality. It would be inefficient to overlook this convenience.
I just pushed another small change, making sure stdin and stdout are opened in binary mode. I can now successfully execute pipelines like this:
heic2png < tests/calder-flamingo.heic| pngtopnm | pnmquant 10 | cjpeg > calder-heic-quant.jpg
I’ve added and updated the new std feature in version 1.2.0. You can check it out here: https://github.com/NatLee/HEIC2PNG/releases/tag/v1.2.0
The PR has been merged, so this issue will now be closed.
Thank you for your collaboration. :)