Accessing Mipmap pixels

[sha...@infograph.com]

Is there a way to get access to, and manipulate, the pixel values in the mipmap level images.  This is in the case of CPU rendering. GPU would have the mipmaps on the card's memory.  The pixel type is alpha 8, if that matters.

I am still working on the same problem.  Trying to make the alpha values increase, at render time, based on zoom level.  A color matrix couldn't do it. A home-grown shader couldn't do it either.  Now I am thinking of doing what I was doing with my own renderer.  Which is: change the mipmap representations of the image. Scaling up the alpha values the deeper into the mipmap stack they are.

If you are wondering why I am trying to do this, the rest of this message describes that:

Among other things, my application renders blueprints.  High resolution, black-and-white (1 bit) images loaded from various Group 4 compressed file formats.  That either came from scanners, or were rendered by CAD applications.  These 1 bit images now live in Skia Alpha 8 bit images.  They use more memory, but that is ok.  The Skia CPU renderer doesn't seem to care, as long as it can malloc enough memory.

The lines on these drawings are very thin.  Often only 1 pixel wide.  So, when you zoom out to show most or all of the drawing, those lines become very faint.  Which is logical, since their contribution to any given pixel is very small.  Before Skia, I handled this by writing my own software raster renderer.  I made the mipmaps preserve the 1's at the expense of the 0's.  So lines would remain visible at any zoom level.  This is great for viewing blueprints.  But artwork looks like garbage.  Which is fine for our use cases.

[Brian Salomon]

Would it work for your use case if there were an SkImage factory function that took the whole MIP chain? Do you ever scale the images up? What is the desired effect if so?

Brian

--
You received this message because you are subscribed to the Google Groups "skia-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to skia-discuss...@googlegroups.com.
To post to this group, send email to skia-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/skia-discuss.
For more options, visit https://groups.google.com/d/optout.

[sha...@infograph.com]

Yes, the user can zoom in and cause the source pixels to scale up to 1 or more destination (screen) pixels.  Nothing special needs to happen in that scenario. This technique only applies to scaling source pixels down smaller than destination pixels.  Trying to preserve them.

Your idea would work, but I would worry about taking too much control of the process away from Skia. Like it's lazy (on demand) generation logic.

Would it be easier if there were a callback?  Where, whenever Skia is done generating the pixels for a mipmap level, it does a post step where it checks if the member variable callback pointer is not null and if not, calls it?  The SkImage class could offer a registerMipMapGeneratedCallback() method that would pass along the pointer to the pixel data object (I forget his name).  Callback class could be something like:

class SkMipMapLevelGenerationCallback
{
public:
   virtual void levelGenerated(void *pixelData, SkColorType colorType, int rowBytes, int width, int height) = 0;
};