Comparing Buffers: "Image data size does not match width/height"

[Flicksie]

related to #76

This code used to work just as expected in v4.0.1, when I last used pixelmatch, in v5.x.x it doesnt work anymore:

  const frameCanvas = await Canvas.getImage(URL_A);        // IMAGE 1 (256x256)
  const oppositeCanvas = await Canvas.getImage(URL_B);     // IMAGE 2 (256x256)
  const toBeComparedCanvas = await Picto.getCanvas(URL_C); // TOP PART CAN MATCH EITHER (256x256)

  let tbcImage = Canvas.createCanvas(200, 30);
  let ctx_tbc = tbcImage.getContext("2d");
  ctx_tbc.drawImage(toBeComparedCanvas, 0, 0); // DRAWS RELEVANT PART TO 200x30 CANVAS

  let oppositeImage = Canvas.createCanvas(200, 30);
  let ctx_opp = oppositeImage.getContext("2d"); 
  ctx_opp.drawImage(oppositeCanvas, 0, 0); // DRAWS RELEVANT PART TO 200x30 CANVAS

  let rawFrame = Canvas.createCanvas(200, 30);
  let ctx_raw = rawFrame.getContext("2d");
  ctx_raw.drawImage(frameCanvas, 0, 0); // DRAWS RELEVANT PART TO 200x30 CANVAS

  const result = pixelmatch(
    await tbcImage.toBuffer(),  // THIS IS 200x30 - LENGTH 7228 if Red or 6927 if Green
    await rawFrame.toBuffer(),  // THIS IS ALSO 200x30 - LENGTH 7228 if Red or 6927 if Green
    null,
    200,
    30,
    { includeAA: false, threshold: 0.1 }
  );

  return result;

This is used to compared a image overlay over the image from URL_C, both B and A are different frames that C can have. Everything worked normally back then but now it just throws errors.

Is there something we are missing that changed from v4 to v5? the docs didnt mention any changes regarding the way we're using it and the only thing i found while reading the code were some comparations that weren't there before. So we just rolled back to v4. But we'd like to know if this is an actual bug or something amiss in our end.

thanks in advance.

also I have the same questioning about the logic behind "width height 4" from #76, that doesn't seem to make much sense at least for me.

[mourner]

Sorry for a late response — it's difficult to say for sure since there's no self-contained reproducible test case I could debug, but this bit:

200x30 - LENGTH 7228 if Red or 6927 if Green

Gives an impression that instead of raw image data, pixelmatch receives a buffer in some compressed image format, because raw image data is always width * height * 4 (all pixels as RGBA), and not dependent on colors.