3D applications often needs to have images directly accessible, that is - to be able to look up a pixels value instantly. common cases are:

• Rendering a texture on a 3D model (applies to any render engine).
• Load the image into OpenGL memory (where the image is sent 'complete' to the graphics-card).

Since a 3D application its a less controlled environment (then a game-engine or 2D-paint-tool for example) - an image may be used for a modifier displacement map, a background in the viewport or be painted onto - all at once. This means we have some constraints which make it harder to optimize for any single use-case.

Even so, there are strategies for better handling texture memory.

• Free images from memory which aren't used often.
• Load lower resolution versions of the image into memory (mipmaps).
• Load partial regions of the image into memory.
• Support in-memory compression (often used for OpenGL textures).
• Support for lower bit-depth of channel options (monochrome, greyscale, limited color palette, index-color).

Blender specifics

What Blender does now

• Images are freed from OpenGL memory if they aren't used
  see: User Preferences -> System -> Texture Time-Out
• Persistent images (Cycles only), disable so images are freed between renders.

How Blender could be improved

• Avoid loading large images
  This would likely mean caching mipmaps.
• Avoid loading the entire image
  This was implemented for 'Sintel' in the render branch, but was never included in a release.
  see: http://wiki.blender.org/index.php/Dev:2.5/Source/Render/RenderBranch/ImageTileCache
• Better memory management, free images from memory (use a time-out similar to what we already have for OpenGL).
• Support OpenGL texture compression.
• Support loading textures into OpenGL memory, and freeing from system memory.
• Implement the same 2D tile-based systems used by image image editors, (but only use it for 2D-painting).

Comparisons with other fields

Games

Games have the advantage that textures can be pre-processed, compressed on-disk to be sent directly to the graphics-card in formats you wouldn't necessarily be able to open for editing.

They typically don't have to operate under the assumption that any texture may be painted or edited at any time.

See: https://www.opengl.org/wiki/S3_Texture_Compression

Image Editors/Painting Tools

Don't have to load the texture into graphics-memory to display on 3D models, so they can use their own in-memory representation of images.

They also have the advantage that each image view has a single zoom-level, (unlike a texture mapped to a 3D-mesh, which may need to access multiple mip-maps at once). So they can - for example, streamline managing multiple tile-sets at different zoom levels.

See notes on krita's tile manager: http://dimula73.blogspot.com.au/2014/07/notes-from-calligra-sprint-part-2.html

Note, the on-disk size of an image isn't all that meaningful. if a 6k texture only takes ~200kb - Its likely not very detailed, a single color image or highly compressed (lossy).

You can ZIP a .txt file with your name written a million times into a few kb, but try editing this as an email :)