PixelType in Raster about scrimage HOT 6 CLOSED

If you always use ints then if you want to store a grayscale image you're
wasting space, as that could be stored in a byte array, would be 33% of the
size?

On 24 July 2014 00:55, gwenzek [email protected] wrote:

I was wondering about the utility to have PixelType in Raster.
I hit a lot of problem to create Array of PixelType cause they don't have
a ClassTag.

My reflection is that ultimately the data on the RAM is going to be an
integer,
so while we can let the Raster choose how it stores colors (RGB, ARGB,
grey level, ...), we may force it to use Int as intermediary data type.

It's not so elegant but I don't think the raster is the best place for
elegance, and it would ensure us that java arrays will be used in the
background.

—
Reply to this email directly or view it on GitHub
#46.

from scrimage.

I thought that we maybe could do the unpacking of int to bytes ourselves.
But I think a better workaround is to add a createArray method in Raster that will delegates the creation of the Array[PixelType] to the subclasses and hence avoid manipulating ClassTags.

from scrimage.

The second option sounds good.

On 24 July 2014 15:50, gwenzek [email protected] wrote:

I thought that we maybe could do the unpacking of int to bytes ourselves.
But I think a better workaround is to add a createArray method in Raster
that will delegates the creation of the Array[PixelType] to the subclasses
and hence avoid manipulating ClassTags.

—
Reply to this email directly or view it on GitHub
#46 (comment).

from scrimage.

I like the new ColorModel traits. I think perhaps the naming could be tweaked. We have an ARGBColorModel, which uses ints, but you could make one that used bytes. Perhaps we should rename this to ARGBIntColorModel, so we can add an ARGBByteColorModel, or perhaps create a further abstraction between ColorModels and the data types, so we just need ByteModel and IntModel and then mixin with ARGBColors or whatever.

from scrimage.

Actually I thought about adding another ARGB Color model.
The idea behind the color model is to avoid passing a colorModel object to each Raster like in java.awt, and use a trait dependency.

The operation I added to the ColorModel comes from what I needed somewhere else.
For instance, the toARGB is needed to write the Image and Raster method "pixel".

In the scaling method as you scale component by component, I added this getComp method in raster. It returns an array of byte corresponding to one of the ARGB component. It's a bit long cause every int of the raster has to be splitted in 4, maybe I should add a faster model which already has splitted the 4 components in 4 bytes.

If you other ideas of useful methods...

Also should we only support color ranging from 0 to 255 ? The PNG specification supports color with 16 bits par channel.

If yes that will imply to add another type to color model, the "ChannelType", to have a specific result type for the method getComp (now it always returns Byte)

By the way what do you think of "getChannel" ? I think it's clearer than "getComp".

from scrimage.

Ok I rewrote the ColorModel and Raster interfaces ( on https://github.com/gwenzek/scrimage/compare/rasterExp )

Indeed while optimizing my code in Scaling I found that it was hard to write code that could manipulate both Int and Array[Byte] seamlessly. It causes overhead and the performance gap we saw between the java version and scala version of the Scaling algorithm.

Now all Raster use an Array[ChannelType] as model.

A pixel channel is represented by one or more (channelSize) consecutive values of this array. Usually channel are valued between 0 and 255, so the ChannelType is a Byte, and thechannelSize is one. If we need to manipulate image with more than 255 levels by channel, we can use a higher channelSize or Int asChannelType.

The colorModel has now only 7 methods which are clearer on name and usage: readChannel, writeChannel, readARGB, writeARGB, readColor, writeColor, and newDataModel that creates a correct array for the given size of Raster. These methods take Array[ChannelType] and an offset as input.

The raster has the matching methods with a simplified signature to read/write pixel with its coordinate.

With this new interface it's really easy to access channel of pixel individually and to set them (no more pack, unpack ...).
This give us good performance for the scaling:

Testing Mortennobel Bicubic (x50)
Time: 25013 ms
Testing Mortennobel Bicubic in scala  (x50)
Time: 35219 ms
Writing one by one pixels in a 10000 x 10000 java BufferedImage
Time: 10183 ms
Writing one by one pixels in a 10000 x 10000 scrimage Raster
Time: 2211 ms

I'll try to make it faster (maybe with compile option to inline some methods).

(BTW the bias in the scaling result for the java scaling was due to the use of lazy val at some point)

So if you aren't so attached to the old IntARGBRaster, I'll suggest we move to this version. (Note it's still possible to write a IntARGBRaster with this new interface).

Also I'm not done with the factory methods.

from scrimage.