interfaces for Image

[vpenades]

Prerequisites

• I have written a descriptive issue title
• I have verified that I am running the latest version of ImageSharp
• I have verified if the problem exist in both DEBUG and RELEASE mode
• I have searched open and closed issues to ensure it has not already been reported

Description

In same cases, we can have a collection of images with varying pixel types, and with the current API implementation it's difficult to have a collection of varying pixel types, the only way to do it now is to cast down to Object collections.

I propose these interfaces:

public interface IImage
{
    Type PixelType { get; }

    int Width { get; }
    int Height { get; }

    ImageMetaData MetaData { get; }
}

this would allow to do Linq queries over image collections like:

var imageCollection = new List<IImage>();
...
var metadataCollection = imageCollection
                       .Where(img=>Width > 100)
                       .Where(img => img.PixelType == typeof(rgba32) || img.PixelType == (argb32))
                       .Select(img => img.MetaData);

Also, an interface like this:

public interface IImage<TPixel> : IImage
{
    TPixel this[int x, int y] {get;set;}
}

Would be helpful, in case we want to abstract the concept of "image"
Useful cases I can think about:

• TiledImage : IImage ; image composed of multiple, smaller images
• X,Y coordinate wrapping for Feature proposal: handling tileable images #427
• Conditional per pixel access.

[antonfirsov]

@vpenades I agree that we should introduce a base interface.
However, exposing anything over Width, Height and MetaData brings non-trivial API design questions. For example PixelType should be a PixelTypeInfo instead of System.Type (see #292).

Regarding the indexer in your proposed IImage<TPixel> interface:
It will perform very poorly, because of the per-pixel virtual calls. I'd rather wait for System.Memory becoming official before exposing new pixel-manipulation API-s.

@JimBobSquarePants @tocsoft thoughts? Should we add IImage in 1.0?
I'm voting yes :)

[JimBobSquarePants]

Tut tut, what happened to Gitter 😄

Interesting proposal, something I've never considered as I try to avoid having many images on the go at the same time. Linq queries like that could be terribly expensive.

I'm up for it though if kept simple.

[vpenades]

@JimBobSquarePants with ImageSharp you're going to experience developers stretching the library to its limits.

In some cases it's going to be developers handling extremely large images.
In some others, they'll want to handle thousands of very small images.

Image collections have it's own uses: for example, finding a specific image on a collection, or looking for repeated images, etc.

One of the use cases I want to implement is to build an Atlas texture:

1. Start with a collection of small images.
2. Remove repeated images.
3. Sort the collection by pixel size, from larger to smaller.
4. keep adding the images in the collection to the Atlas image, by finding an empty region
5. when trying to add an image to the Atlas there's no more space, grow the Atlas image x2

That's a common technique to fit textures of 3d models in a single texture, to build texture fonts, or even sprite sheets.

[tocsoft]

I agree IImage sounds fine to me 👍 Also yes I agree that we should probably not expose the per pixel access directly on an interface.

[JimBobSquarePants]

Fixed with #292