Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for reading and writing grayscale PFM images #7696

Merged
merged 4 commits into from
Jan 8, 2024

Conversation

nulano
Copy link
Contributor

@nulano nulano commented Jan 6, 2024

Based on documentation:

hopper.pfm created by converting hopper("F").save("im.tiff") using https://convertio.co/tiff-pfm/.
hopper_be.pfm created using struct.pack.

Color PFM images are not supported due to #1888.

@radarhere
Copy link
Member

radarhere commented Jan 7, 2024

Interestingly, there is disagreement in the documentation about row order - one says top to bottom, the other says bottom to top.

https://linux.die.net/man/5/pfm

The raster is a sequence of pixels, packed one after another, with no delimiters of any kind. They are in standard Western reading order: left to right and top to bottom within the image.

https://www.pauldebevec.com/Research/HDR/PFM/

After the final carriage return the file proceeds with a series of three 4-byte IEEE 754 single precision floating point numbers for each pixel, specified in left to right, bottom to top order.

Could you explain why you went with the https://www.pauldebevec.com/Research/HDR/PFM/ version?

@nulano
Copy link
Contributor Author

nulano commented Jan 7, 2024

Huh, I thought https://linux.die.net/man/5/pfm was identical to https://netpbm.sourceforge.net/doc/pfm.html, which says

The raster is a sequence of pixels, packed one after another, with no delimiters of any kind. They are grouped by row, with the pixels in each row ordered left to right and the rows ordered bottom to top.

From https://sourceforge.net/p/netpbm/code/1682/tree//userguide/pfm.html?diff=51243f8e2718460a4a53b63a:1681, it looks like this was changed in 2012, with "bottom to top" being the newer version. I suspect the doc file was wrong until then, since looking at the 10.22 release of netpbm from 2004, the HISTORY file shows that this is the version that added PFM support and the source code for the PFM utilities shows bottom to top order being used.

Similarly, Wikipedia says:

After the header the file proceeds with floating point numbers for each pixel, specified in left-to-right, bottom-to-top order. Some programs suggest PF4 as an additional extension for the RGBA format.

I've also tested Gimp, ImageMagick's convert, and libjxl's cjxl, and they all agree on bottom-to-top order.

Copy link
Member

@hugovk hugovk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please could you also add this to the release notes?

Tests/test_file_ppm.py Outdated Show resolved Hide resolved
docs/handbook/image-file-formats.rst Outdated Show resolved Hide resolved
src/PIL/PpmImagePlugin.py Outdated Show resolved Hide resolved
nulano and others added 3 commits January 8, 2024 17:17
Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>
@nulano
Copy link
Contributor Author

nulano commented Jan 8, 2024

Please could you also add this to the release notes?

Done

@hugovk hugovk merged commit b1f549f into python-pillow:main Jan 8, 2024
56 of 57 checks passed
@hugovk
Copy link
Member

hugovk commented Jan 8, 2024

Thanks!

@nulano nulano deleted the pfm branch January 20, 2024 21:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants