Images - Loading,saving and editing images

Python Help
1

For those who think ‘just install Pillow’:

  1. Pillow has a lot of dependencies if you are on Linux,and is very big no matter the platform
  2. An image,is a basic data type,like a ZIP or a JSON,if other basic data structures can be implemented,so can images.
  3. Most developers do need images at some point.
  4. Do you really need a venv just to open a image?

Errors:

ValueError - exists in normal Python,used for if you say…make a JPEG with rgba,or if you access the -1st row

UnsupportedFormatError - format isnt a bitmap,a JPEG or a PNG

images.Image

Create a new Image object,always starts with all black

an Image is a 2D iterable,and a pixel is a tuple with integers

resolution → tuple with 2 entries,format → (rgb,rgba,greyscale)

images.open(filename,format(JPEG,PNG,bitmap,auto,default:'auto')) → open a image as a Image object

Image.change_format(format) → (rgb,rgba,greyscale),changes the format of the Image

256 color PNGs are converted to RGBA

Image.save(path+filename,format(JPEG,PNG,bitmap,auto,default='auto')) → saves to the location.

Image.load_tk() → load an Image into Tkinter

Image.rotate(amount) → rotate in 90 degree increments

Image.flip((direction=('h','v',default:'h')) → Flips the image

Image.crop(x1,x2,y1,y2)(if it goes off the image,a warning is done and the off image parts are black) → Crops the image

Image.resize(x,y) → resize from top left(if it goes off the image,the off image parts are black,but no warning)

Image.upscale(x → int,y → int) → upscale image using nearest neighbor scaling,ValueError if x or y <= 0

Image.downscale(x,y) → downscale by removing pixels,ValueError if x or y > width and height of actual image,or negative

Image.downscale_relative(x,y) → same as Image.downscale but relative instead of absolute,ValueError if x or y > 1.0,or negative

davidism (David Lord) 2

Moving to the general Help section as this is not a realistic proposal to discuss for inclusion in Python.

3

I think dealing with images in general is very complicated as many file formats are not simply a matrix of pixels (and loading them like so into memory might be expensive). Not simply a Image.loads, Image.dumps solution.

what about SVGs? What about RAW file formats, or different compression options for JPG?

To that end, I also think of the use cases for this being either: image processing (in which there are already several optimized packages), web apps (where there are other mechanisms, ie, embedding the picture), or GUIs (where you’d most likely be using a framework or something similar)

4
  1. images is meant to be simple,Pillow still takes care of high end image things,this like how math exists despite NumPy being used for serious mathematical projects
  2. Uses of images:AI(generative AI, and reinforcement learning when given a low resolution image as a input),GUIs,game dev(to load sprites/textures),image processing,automation,data visualization,document processing,systems programming(a OS usually has a image viewer)
  3. Saying that images isnt a image module for not including SVG is like saying json is not a data parser for not including YAML
5

Not realistic? Then how do the other data modules like compression/zipfile/tarfile and json exist

6

We have intentionally excluded image processing from the stdlib. The existing color module(s) would likely not be added today and were once seriously considered for elimination.

Compression modules are used to develop and distribute CPython and other implementations and by others for infrastructure work. Image processing is not.

7

What I meant is this would not be a trivial task as in: where do you draw the line between basic and high end? Simply parsing several image formats might be very complex.

And then, if the image module only supported a handful of scenarios, it would be confusing to people (e.g., if I can load a PNG image, surely I can load a JPEG; if I can load a JPEG, probably I can also load a higher resolution image).

I don’t agree fully as JSON and YAML are file formats but here we are talking of images as a concept, which can have many different file formats. It would be weird if it only supported a subset of those.

As for the uses, I think for most of them you’d already be using certain packages that can handle images best for their usecases (e.g., matplotlib, tkinter, tensorflow, etc).

My main thing would be: why/where to draw the line between “basic image operations” and “complex image operations”, and why not already use the one image package for both?

8

Pillow handles over 10 image formats,including ones most people never encounter

images only does 3 formats,and only a few basic functions

9

But Python is ‘batteries included’…

10

Counterargument: Most developers need pip at some point.

11

Counter-counterargument:Python supports binary data,compression formats,database formats,audio formats,base64 and JSON,but not images

Like,should Python delete the json module because you need 3rd party libraries for the rest of the web stack?

12

Python also doesn’t come with high performance numeric data processing, protobufs, HTML interpolation/templating, Markdown, PostgreSQL, Oracle, or any of the other myriad things available on PyPI. “Python has this but not that” is not a very strong argument for additions to the standard library; it is, in fact, a strong argument for teaching people how to safely and reliably use PyPI to get more modules.

13

But then again,Python has low performance numeric data processing(built in/math/cmath/statistics),sqlite3,HTTP servers,and all these things you mentioned are less important than the image.

14

I think json is not a fair comparison.

JSON files are simply text with very simple grammar, so parsing them isn’t a very complex task (that’s one of the main reasons they are used all over the place instead of say XML). And having a way of converting from/to dictionaries (a native python data format) is very useful. But on the other side, it wouldn’t make sense to implement the rest of the stack.

Images are much more complex and are not a “native” way of interfacing with other tools/apis.

I also think the case with images is different as in to visualize them, you’re probably already using another package (ie, you are not visualizing them in your terminal)

15

Less important to you. More important to others. That’s why we have options. Each of us gets to pick the exact set of libraries that are useful, and make that into our Python build.

You’re welcome to keep screaming into the void, but if you want a practical and workable solution to your problem, mastering PyPI is far more effective than begging for different packages to be added to the standardl ibrary.

16

What other package? Tkinter exists.

Also should zipfile be deleted since 3rd party compression libraries exist on PyPI?

17

But the image while not more important for everyone,is used by way more people than say…PostgreSQL

18

Yes, precisely TkDocs - PhotoImage

I understand the motivation behind this, but don’t think SC will support the idea. Additionally I think this would require a PEP

19

Tkinter doesnt support JPEGs. images will.

20

If it does, the first step would be to find a core dev who’d sponsor the PEP. So before we get anywhere near that stage, there needs to be at least one core dev who believes that this is worth doing.

(Similarly if it’s just a patch and an issue tracker entry - still need a core dev to say “yeah let’s do this”.)