When requesting pixel data for a 1200x1200 area, getPixels() is returning pixel data from a different location in the document than what is expected. (Other width and height combinations could be affected as well.)
The bug could lie in the pyramid level logic where the bounds are calculated on one pyramid level but the pixel data is returned from another pyramid level. I’m not sure.
Current Work-Around:
I have noticed that Increasing the requested source bounds to 1201x1201 pixels does return the expected result and could serve as a temporary work-around until the issue is resolved.
How To Replicate:
I have created an example plugin that demonstrates the issue:
The “Get Pixels (1200x1200)” button requests a 1200x1200 area of pixels from the center of the active document.
The “Get Pixels (1201x1201)” button requests a 1201x1201 area of pixels from the center of the active document.
Both buttons will show a blue rectangular path on the source document where the pixels are expected to be retrieved.
Note how the 1200x1200 preview is incorrect. It is returning pixel data that is further up and left on the active document.
Note how the 1201x1201 preview is correct. It is returning the expected pixel data from the center of the active document.
So it seems to me the problem is with the relation between the sourceBounds and the targetSize arguments in the call to getPixels. Playing with your code, if I remove the targetSize or change it to something other than 300x300 or 600x600, I get the correct results. I would assume a rounding error somewhere in the getPixels method is causing the issue. Like you found, simply adding 1 pixel to the size seems to fix the bug. I also tested 100x100, 200x200, 400x400, etc. and they all work fine. I also found that increasing the sample size to 1300x1300 removed the bug when targetSize is 600x600. Im’ not sure your end use but if it is to display the image data in the panel, the good news is that the panel seems to scale the inserted image to fix the panel view no matter the size (100x100 and 1200x1200 targetSize show the same thing except for some aliasing).
@jduncan Thank you for testing and confirming the bug. Use case for me was creating a 600x600 preview window with controls for zooming and panning around the source document. I first noticed the bug when zooming and the source became double the target (1200x1200 source and 600x600 target). It only seemed to happen on that 2x ratio. I will test other 2x ratios and see if it happens there as well.
Example use case with preview window and panning and zooming controls:
@Erin_Finnegan Are you able to help ensure the UXP development team is made aware of this issue with the Imaging API? It would be greatly appreciated. If there is someone else I should reach out to, please let me know.
