search

Ignotus-mago / PixelAudio

PixelAudio maps arrays of audio samples onto arrays of pixel values.
Other
0 stars 0 forks source link

Affine Transform Errors #6

Open Ignotus-mago opened 4 days ago

Ignotus-mago commented 4 days ago

BitmapTransform methods and ImageTransform methods test code (not in the library yet) are misbehaving.

  1. There were problems with non-square images.
  2. Partially resolved issues with a rectangular image, still doesn't work with diagonal transforms FLIPX90 and FLIX90CCW.
  3. There may be inconsistencies whose origin is not clear to me yet, where the PGraphics that is used for off-screen drawing changes upon switching between BitmapTransform and ImageTransform methods.

BitmapTransform: On non-square images, FLIPX, FLIPY, ROT180 all function. ROT90 and ROT90CCW do not, neither do FLIPX90 or FLIPX90CCW. -- But they all work on square images. ImageTransform: On non-square images, FLIPX90 and FLIPX90CCW do not work.
-- And they don't work on square images, either.

Ignotus-mago commented 4 days ago

There was a very elusive bug. After running ImageTransform methods, BitmapTransform methods appeared to work, but not if they were the first methods called.

What was happening? I commented out adjustToImage(img) at the top of each ImageTransform method. As a result, from all the ImageTransform methods, I returned the whole display image as the new image. So, I'm not really working on the rectangular image I loaded from disk any longer, but on a PGraphics sized to the display. BitmapTransform methods then handle the display-sized image without problems. The display does not have to be a square.

Solution: It looks like the BitmapTransform errors on non-square images can be solved with lines right after the img.updatePixels() call, as follows:

        PImage newImage = createImage(img.height, img.width, ARGB);
        newImage.pixels = img.pixels;
        img = newImage;

The problem arose when the pixels array in effect swapped width and height. However, the width and height of the enclosing PImage was not changed. The new lines create a new PImage with width and height of the old image swapped, and then set the old image to point to it. There may be more efficient ways to do this, but it seems to solve the problem.

There should perhaps be some adjustments in the library, too, though at the expense of loosing some generality: data values would have to be RGB.

In any case, the BitmapTransform methods do what I originally wanted: transform the PImage itself, rather than the PGraphics into which it is drawn. The problem is solved for BitmapTransform. For the PixelAudio and PixelScanner context, the ImageTransform methods are workable because we are always using square bitmaps. However, this needs to be noted in updated code and comments.

I am leaving this issue open until I find a better resolution for ImageTransform methods.