I'm developing a 2d tile - grid based rpg and was wondering what the best approach would be for storing/loading the game graphics.
Right now I'm storing each graphic (item, object, etc) in nested folders based on graphic type and loading them individually, storing then in lists.
There are currently no real lag or memory problems with this method but I feel there must be a better approach and haven't found much online about this. One other approach I know is to store all images in large files to load then in the game splice the large image file in to individual images to be stored in lists.

Does anybody have any recommendations on how I can optimize my image storage/loading? ?

Does anybody have any recommendations on how I can optimize my image storage/loading? ?

Yes, don't.

There are always a zillion things to do, trying to optimize without need typically adds more problems than they solve.

Optimizing when you have a problem with it has another huge benefit. It gives you direction. You can analyze why the current solution takes too long, and reason about ways to avoid that from happening. Also, when you implemented the optimization, you can see the benefit really fast. Optimizing without need does not have that steering. It was fast enough, and it's still fast enough afterwards. In theory you might "optimize" in the wrong direction, running into trouble sooner rather than later.

Fair point, I appreciate your perspective.
I generally use the method "build now, optimize when necessary".
In this project it kind of bothers that all my assets are just "there". I was admittedly considering just storing the image rgba data in a sqqlite 3 database and loading it that way to make the package look leaner, but was curious about what other methods developers use before I make those kinds of changes.

I usually have sprites and metadata in a lightweight file. Last time I did that I used a yaml file:

axes:
  64x56: [{x: 0, y: 56}, {x: 48, y: 28}]

overlays:
  blue_area    : {filename: blue_area.png,    width: 64, height: 56, x: 0, y: 0}
  red_area     : {filename: red_area.png,     width: 64, height: 56, x: 0, y: 0}
  unreachable  : {filename: unreachable.png,  width: 64, height: 56, x: 0, y: 0}
  current_tile : {filename: white_select.png, width: 64, height: 56, x: 0, y: 0}
  target_tile  : {filename: red_select.png,   width: 64, height: 56, x: 0, y: 0}
  black        : {filename: black.png,        width: 64, height: 56, x: 0, y: 0}

This allows me to modify or move graphics as I see fit. I am still very early in development, figuring out how to do things.

In this project it kind of bothers that all my assets are just "there". I was admittedly considering just storing the image rgba data in a sqqlite 3 database and loading it that way to make the package look leaner

My guess is a data base is going to be slower rather than faster in loading sprites :)

Apparently, you feel something is wrong, perhaps it is time to at least identify what you consider wrong here, as speed isn't it, apparently.

Is it the deep nesting, is it the the large amount of files?

Your current method also has its advantages, namely simplicity. I have to carry positions in the sheet as part of their data around, I have to handle share some images between sprites. It's a cost I have to pay for being more flexible. I do that, since eg my ground sprites of one type are all together at one sheet.

I feel it's the amount of files that is wrong and there will likely be dramatically more as content is added.
For now I'm using text files to store item/object filenames, stats, description so I can quickly add more assets in to the game on the fly and server/client/map editor all get updated assets at the same time during development (all currently in the same project directory). When I make the game publicly I'll use a sqqlite database file rather than text files.

I feel using 1 large image file for each asset type containing every graphic for items, objects, sprites will look less bloated and only slightly increase the initial loading speed.. but I still feel there must be a better way to store images.
I agree a database storing image files would probably be unnecessarily slow heh.

I feel it's the amount of files that is wrong

Put the files into a Zip archive. Voila! From hundreds of files down to one.

Use the standard library tools to load those files from the archive - https://docs.python.org/3/library/zipfile.html