Feature request: adding quality='keep' to Image.save() with JPEG2000

[sl2c]

Hi!

In my project, I am actively using the feature of PIL whereby calling Image.open('image.jpg') opens the JPEG file in a 'lazy' mode, which allows me to access image data on demand while leaving a chance to save essentially the original compressed image.jpg by calling Image.save('image.jpg', quality='keep'). It comes handy in situations where one part of my code sends an Image.Image object to another part of the code, without needing to duplicate the original file object just in case a need to save the original arises.

So, my question is: could you add this quality='keep' functionality to Image.save() for saving to JPEG2000 as well?

[radarhere]

I wouldn't go so far as to say that you can "save essentially the original compressed image.jpg". It depends on what you mean by "essentially", but I don't think there is any guarantee that it will be the same as the original. See https://www.quora.com/Can-you-edit-and-re-save-a-JPEG-file-without-losing-quality

Here is how "keep" is documented - https://pillow.readthedocs.io/en/stable/handbook/image-file-formats.html#jpeg-saving

quality
The image quality, on a scale from 0 (worst) to 95 (best), or the string keep. The default is 75. Values above 95 should be avoided; 100 disables portions of the JPEG compression algorithm, and results in large files with hardly any gain in image quality. The value keep is only valid for JPEG files and will retain the original image quality level, subsampling, and qtables.

Is your goal to be able to save a JPEG2000 image without "losing quality" aka "modifying the pixels"? I think Pillow should already do that, provided that you haven't set irreversible=True.

[sl2c]

Operation without "modifying pixels" is exactly what I am looking for. Could you provide an example code for the Image.open().save() sequence such that the pixels of the resulting and the original file are identical in the case of them both being JPEG2000 files?

UPD. I guess I need a bit more than that: I also want the sizes of the two files to be reasonably close to each other. I could, of course, save with very large quality parameters, but that would bloat the file size.

[radarhere]

Could you provide an example code for the Image.open().save() sequence such that the pixels of the resulting and the original file are identical in the case of them both being JPEG2000 files?

Taking one of our test images, https://github.com/python-pillow/Pillow/blob/main/Tests/images/rgb_trns_ycbc.j2k,

from PIL import Image
im = Image.open("rgb_trns_ycbc.j2k")
im.save("out.j2k")

reloaded = Image.open("out.j2k")
assert reloaded.tobytes() == im.tobytes()

runs without a problem, demonstrating that the pixels are the same in the saved version. If I add irreversible=True, then the assertion fails.

I expect that simple example isn't news to you though, so if you have an image that doesn't save exactly the same using my code, feel free to upload it here.

I also want the sizes of the two files to be reasonably close to each other. I could, of course, save with very large quality parameters, but that would bloat the file size.

In the case of the test image I mentioned, it actually becomes 6 bytes smaller after saving with Pillow. Again, if you have an image where it does not, that could be interesting, but no guarantees - it is naturally hard to achieve both small file size and high quality at the same time.

[sl2c]

debug.jp2.zip

when doing Image.open('debug.jp2').save('debug-out.jp2') the output file is > 16 times larger.

I might be wrong here, but I have always assumed that with JPEG files, at least, the original encoded data from the file is somehow kept around after Image.open() and so as soon as quality='keep' is used during save() it is that original encoded data that is actually written out. In other words, one may change the metadata of the file between open() and save() and still write the original encoded DCT harmonics out. And that's why the new size with JPEG is very close to the old one. And so I thought that it is just a matter of keeping that original encoded pixel data around with JPEG2000 as well in order to achieve the same effect. So, am I missing something?

UPD. This actually suggests a way to make my original question a bit more concrete: suppose, I want to write code that loads a JPEG2000 file, changes EXIF metadata only and writes the file with updated metadata out. Obviously, I want to keep all pixel-related data as intact as possible when doing so. Is this doable with PIL?

[Yay295]

If you only want to change EXIF data you should probably just use https://exiftool.org/.

[radarhere]

I have always assumed that with JPEG files, at least, the original encoded data from the file is somehow kept around after Image.open() and so as soon as quality='keep' is used during save() it is that original encoded data that is actually written out. In other words, one may change the metadata of the file between open() and save() and still write the original encoded DCT harmonics out. And that's why the new size with JPEG is very close to the old one. And so I thought that it is just a matter of keeping that original encoded pixel data around with JPEG2000 as well in order to achieve the same effect. So, am I missing something?

The quality level, subsamping and qtables (quantization tables) are kept, but the pixel data is re-encoded. You can modify a JPEG image, and still save using the "keep" option.

from PIL import Image
im = Image.open("hopper.jpg")
for y in range(im.height):
    for x in range(im.width):
        im.putpixel((x, y), (255, 0, 0))
im.save("out.jpg", quality="keep")

I want to write code that loads a JPEG2000 file, changes EXIF metadata only and writes the file with updated metadata out. Obviously, I want to keep all pixel-related data as intact as possible when doing so. Is this doable with PIL?

My impulse was to put together a way to read the file contents, and modify the EXIF data without opening the file as an image and saving. However,

1. Checking with exiftool, I don't see any EXIF data in your image, which is not what I expected. Do you think there is EXIF data in the file?
2. Pillow currently doesn't support writing EXIF data to JPEG2000 images... so I'm confused why that wasn't a problem that you listed?

[sl2c]

0. hypothetically: if I wanted to add, e.g., author's info to an image's exif then the fact that the image has no exif yet seems like a bad excuse to give up.

1. the "exif problem" was no more than just my attempt to try to make my point simpler to understand; I guess, I failed at that; the description of my actual issue is in my first post in this thread: is there a way to recreate an original encoded image from an Image object? Or, on the contrary, the Image object has no original encoded bytes stream as it basically decodes and discards it. My current realization is that the answer is 'no'. At any rate, this part of the docs seems a bit confusing:

Image.tobytes(encoder_name='raw', *args)
Return image as a bytes object.
Warning
This method returns the raw image data from the internal storage. For compressed image data (e.g. PNG, JPEG) use save(), with a BytesIO parameter for in-memory data.

It should explicate that the "compressed image data" is not the original encoded image data and will be created anew (even with 'keep').

2. the file I attached, obviously, had nothing to do with the "exif problem" and was a counter-example of your claim that open().save() produces JPEG2000 files of equal or smaller sizes.

[radarhere]

hypothetically: if I wanted to add, e.g., author's info to an image's exif then the fact that the image has no exif yet seems like a bad excuse to give up.

I thought you were talking about that image, and since you wanted to "change" something, I just wanted to make sure that you weren't thinking of something else when you said 'EXIF'.

your claim that open().save() produces JPEG2000 files of equal or smaller sizes.

It was not my intention to claim this. I was only talking about the specific image I was using.

It should explicate that the "compressed image data" is not the original encoded image data

I understand the documentation doesn't dissuade you the idea that you can resave images with the same file data, but I also don't personally think it's common to think that? Feel free to create a pull request with updated documentation if you'd like to find out the opinions of others.

Did you still want to explore why Pillow takes your uploaded image and decodes and encodes it with a larger result?