Moving PixelFormats and PixelOperations to a separate package

[ptasev]

Is there any chance the pixel formats part of ImageSharp could be moved to a separate library? I'd like to be able to re-use the pixel formats, but create my own simpler/thinner specialized version of an image abstraction on top providing a more limited set of functionality.

Having it separately will avoid confusion with developers mistakenly using ImageSharp's Image vs my own.

[antonfirsov]

It's very good to see people being interested in the core functionalities of our engine, and the idea makes a lot of sense from an advanced user's perspective. On the other hand this is an extremely expensive feature in terms of maintenance costs, that would only benefit a small set of users.

The cheapest thing I can think of is to create a build target that takes a reduced number of sources and produces a minimal "ImageSharp.Core" package. I'm open to explore such an idea as a community contribution if you are interested and committed to execute it, but hardly see an option that wouldn't place a huge maintenance burden on the team in long term, since we keep evolving and optimizing these bits rapidly.

Any ideas to overcome these challenges?

[ptasev]

I'm not sure if this helps, but for the sake of making this really easy, and only exposing the pixel formats separately for now we have a project structure like this:

• ImageSharp.Core.Shared -> only has the core parts that PixelFormats needs (for now)
• ImageSharp.PixelFormats.Shared -> has just the pixel formats code
• ImageSharp.PixelFormats -> Compiles the shared pixel formats code into a dll
• ImageSharp -> The full library unaltered and without dependencies on separate dlls

I'm not super well versed in shared projects, but from my limited understanding this will allow ImageSharp to work as-is and compile everything into a single dll without dependencies on a separate PixelFormats dll.

Does this overcome any of the challenges?

[tocsoft]

I have to be quite frank, this is very unlikely to ever happen. There are going to be a few reasons but it mostly boils down to we have no incentive to do this.

What exactly is heavy about the Image abstract that you feel you need to bypass? an image isn't too much more that a wrapper around a pixel buffer (which we provide direct/fast access to without the need for pinning).

[antonfirsov]

@ptasev out of curiosity:

• What is your project/product?
• Why is it important for you to maintain such a structure and why isn't good enough to pull in the whole ImageSharp NuGet package, and just ignore the unused bits?
• Is deployment binary size critical for you?

[ptasev]

The project deals with biomedical images. The deployment binary size is not important.

To be honest, in retrospect, I'm not sure if I made the right decision by not using ImageSharp directly. We had an existing code-base that wasn't flexible when it came to using different pixel types and I tried to integrate some of what you had learned with this incredible library. I attribute my decision to time constrains, and ability to use image infrastructure we already had in-place.

One driving factor is metadata support. We use the tiff file format, and read/write custom metadata across multiple frames of the image. Since ImageSharp doesn't yet have tiff support, I didn't have much confidence that I could learn how to create custom tiff encoders/decoders and integrate it all properly with reading/writing metadata to meet our needs. That seemed like a lot of work and, given the time constraints I had, it was much easier to use our existing tiff encoding/decoding infrastructure, and integrate that with a simple image wrapper over the pixel types. Now, since the ImageSharp library provides image encoders and image abstractions, it could get confusing to developers, new to the code, which APIs to use and not to use (our own vs ImageSharp's).

Also, due to having some algorithms that relied on getting the entire pixel span of the image I was scared off by TryGetSinglePixelSpan. At the time I didn't understand the implications of this function. I recently read something about it being configurable so maybe this isn't a real issue after all. Either way, this was nowhere near as important as the first point.

At this point if I am to consider fully integrating ImageSharp into our code-base I'd have to do it all in my free time. One of these weekends I may sit down and try going the route of creating the custom tiff image encoders/decoders as a wrapper around our existing ones.

[antonfirsov]

Now, since the ImageSharp library provides image encoders and image abstractions, it could get confusing to developers, new to the code, which APIs to use and not to use (our own vs ImageSharp's).

That's a concern I can understand. I would try to address it in a coding guideline (if possible).

Hopefully we'll get out-of-box tiff support done soon. Even without that, I think it would be good for you to switch to standard packages to keep up with updates more easily and get the latest PixelOperations<T> perf improvements. Wish your company understood the concept of tech debt more, so you don't have to refactor in your free time :(