Add Realtype builders

[Rylern]

Add new functions createRealBuilder() to create instances of ImgBuilder with the RealType type. Basically, a RGB image server is converted to a 4-channels UnsignedByteType image (instead of being converted to a single-channel ARGBType image with the existing createBuilder() functions).

This required to add a new ByteBufferedImageAccess to get byte pixels from a RGB BufferedImage.

The justification for this PR is that RealType is quite easy to work with, unlike ARGBType.

If this PR makes sense, shouldn't we delete the existing createBuilder() functions? Would they still be used for anything?

This PR is a draft until we agree on its content, because tests have to be added.

[petebankhead]

I've just made some quick comments for looking at the code (haven't tried running it).

I'm not certain this PR on its own makes things easier, since in the case where you can provide the type argument the you can already be sure where you have a RealType - and in the case where you can't, you're still getting an ImgBuilder<?, ?>.

I'm not certain, but I still have a suspicion that including the type T with ImgBuilder<T, ?> (rather than delaying its appearance to when an image is actually built) might be making it harder to get a friendly API. I think a caller would want an ImgBuilder<? extends RealType, ?> but I don't see any way for that to be specified... unless perhaps you subclass ImgBuilder.

[petebankhead]

I'm not sure how much this method helps the called when returning ImgBuilder<?, ?>, since they still seem stuck with the fact all they know for sure is ImgBuilder<T extends NativeType<T> & NumericType<T>, A extends SizableDataAccess>.

On the other hand, if they can provide the type to createBuilder then they would already know if they have a RealType or an ARGBType.

[Rylern]

The signature is now:

public static ImgBuilder<? extends RealType<?>, ?> createRealBuilder(ImageServer<BufferedImage> server)

Is that better?

Similarly, the signature of the other unsafe function has become:

public static ImgBuilder<? extends NumericType<?>, ?> createBuilder(ImageServer<BufferedImage> server)

[petebankhead]

If this PR makes sense, shouldn't we delete the existing createBuilder() functions? Would they still be used for anything?

If you mean only return a RealType (and never ARGBType) then I think the other functions are worth keeping:

• I think Java's rendering pipeline likes the packed int representation (so it might help us optimise things when creating a viewer)
• Currently, we have quite a bit of QuPath code that handles packed int images separately (e.g. ColorTransformer.

This isn't conclusive, because we might be better off moving away from any assumptions of a packed int representation (see e.g., qupath/qupath#1807) - but I'd be nervous about the API not providing us with any way to get an ARGBType image until we're very confident it isn't ever useful.

[Rylern]

I think a caller would want an ImgBuilder<? extends RealType, ?>

This is now what the unsafe createRealBuilder() function returns.

[alanocallaghan]

I would assume with a high level of confidence that the packed int representation allows for a tonne of optimization that isn't possible otherwise, so I'd be inclined to keep it.

The rest looks good to me insofar as I have a sufficient grasp of imglib2 and Java generics to be able to comment on it at all (not very far as it turns out).