Use PNG EXIF data to mirror json argument data

[parlance-zz]

This better attaches the generation parameters to the actual output image file.

Any code that reads the separated JSON files should be updated to instead pull data from this field, if it is present.

This data should be set in the encoded PNG bytes sent to the GRPC server for ad-hoc protocol extensions.

[parlance-zz]

cv2 imwrite / imencode do not appear to support EXIF data, need a workaround

[keturn]

Support for image metadata is not nearly as widespread as I expected!

The best option I've found for EXIF so far is:

• many file formats supported by PIL take an exif argument to their save method. But it takes the raw EXIF data and doesn't offer a great interface for working with it, so
• piexif to serialize and deserialize that data.

piexif is in the process of transitioning to a new maintainer, and it looks like they could use some assistance/encouragement in getting things up and running: https://github.com/JEFuller/Piexif/projects/1

[parlance-zz]

@keturn - thanks for the tip!

I really want to avoid using PIL to do any of the image encoding, serialization, or disk io because in my testing the performance of nearly every function in PIL is extremely bad. It's bad enough that I would hold off until I can find another way to have cv2 write EXIF metadata...

[keturn]

That bad? I would have assumed that PIL.Image.save ends up being a fairly thin wrapper between the byte array supplied by numpy to a platform-native image encoding library.

[parlance-zz]

That bad? I would have assumed that PIL.Image.save ends up being a fairly thin wrapper between the byte array supplied by numpy to a platform-native image encoding library.

It's the encoding for formats like PNG that really kill the performance. I'm sure if you were saving something like bmp or other uncompressed it might not be as bad. Bear in mind that I have users saving files that are upwards of 16384x16384 in some cases...