Generated Image Issues with Modified Pixels_Per_Grid Value

[gabrieljtaylor]

Summary:

When generating the map image from the DD2VTT file in which the pixels_per_grid value has been changed, the resulting image does not honor the pixels_per_grid changed value. The result is also different for PNG output and Webp output, with each format displaying different issues.

Expected behavior:

• The output image's dimensions would be equal to the number of grid squares multiplied by the current pixels_per_grid value and the image's contents would display the whole map contained in the DD2VTT file without cropping.
  • E.g., a 30x20 DD2VTT file with an original pixels_per_grid value of 200, changed to 100, would generate an image with dimensions of 3000x2000 and would contain the full image.

Actual behavior:

• When converting to Webp, the output image has the correct dimensions relative to the pixels_per_grid value and the number of grid squares in the image, but only shows a cropped subset of the image with the image contents themselves remaining at the origial DD2VTT file's pixels_per_grid resolution.
  • E.g., a 30x20 DD2VTT file with an original pixels_per_grid value of 200, changed to 100, will generate an image with dimensions of 3000x2000 but will only contain the upper-left quarter of the original image.
• When saving as PNG, the output image is not cropped, but does not honor the pixels_per_grid size changes, with the output file's dimensions reflecting the original pixels_per_grid value and number of grid squares in the image.
  • E.g., a 30x20 DD2VTT file with an original pixels_per_grid value of 200, changed to 100, will generate an image with dimensions of 6000x4000 but contain the full image.
• In either scenario, the scene dimensions in FoundryVTT are correct (honoring the changed pixels_per_grid value and grid size), and both walls and lights are positioned correctly in the scene. The only issue is with the generated image.

Steps to Reproduce:

1. Generate a DD2VTT file with a large pixels_per_grid value (such as 200 or 256)
2. Modify the DD2VTT JSON to reduce the pixels_per_grid value to a more reasonable value (such as 100)
3. Use the Universal Battlemap Importer to import the scene into Foundry twice, once with the "Convert to Webp" option selected and once with it deselected.
4. Compare the details of the generated Webp and PNG image files on the server, both their dimensions and the image itself

Version Information:

• Foundry version 9 build 249
• Universal Battlemap Importer module version 2.2.1
• The DD2VTT files were generated by Dungeondraft by a separate artist and I do not have access to the original Dungeondraft files, so I cannot say with certainty which version of Dungeondraft was used to generate the DD2VTT files

What I've Done So Far:

• Made no changes to the DD2VTT files other than changing the pixels_per_grid values
• Tested with ~20 different DD2Vtt files, both the original versions and versions with the pixels_per_grid values edited
• Tested different options in the Universal Battlemap Import interface to try and pin down the details of the issue
• Read through the importer's source code to see if there was an obvious explanation for these issues (I didn't see any, but I don't know Javascript very well, so that's not really saying much)

I plan to fork the repo and play around with the image generation code to see if I can figure out the fix, but also, as mentioned above, I don't know Javascript very well, so I am not certain I will have success or efficiency. I'm filing this issue both for awareness and also in hope someone with more Javascript knowledge than me might realize an easy fix and knock it out.

[gabrieljtaylor]

I've managed to figure out a fix for both issues when combining multiple images together - by passing the desired height and width to the image2Canvas function, the generated image is the correct size, with the correct contents and proportions, both when converting to webp and when not converting. I'll submit a pull request with my changes later (once all of my changes are ready for testing), but the specific code changes are these:

Line 258 changes to:

            await DDImporter.image2Canvas(mycanvas, f, image_type, size.x, size.y)

The image2Canvas function changes to:

  static image2Canvas(canvas, file, extension, imagewidth, imageheight){
    return new Promise( function(resolve){
      var image = new Image();
      image.decoding = 'sync';
      image.addEventListener('load', function() {
          image.decode().then(() => {
            canvas.drawImage(image, file.pos_in_image.x, file.pos_in_image.y, imagewidth, imageheight);
            resolve()
          }).catch(e => {
            console.log("decode failed because of DOMException, lets try directly");
            console.log(e);
            canvas.drawImage(image, file.pos_in_image.x, file.pos_in_image.y, imagewidth, imageheight);
            resolve()
          });
      });
      image.src = "data:image/"+extension+";base64,"+file.image
    });
  }

Regarding single-file import, I don't have a solution yet. If I'm interpreting the code correctly, it seems that single-file import always uses the DecodeImage function, and I'm still learning how that works but it doesn't appear to use the canvas element and so doesn't have a means for resizing the image currently. I might be able to add a processing of the decoded image via canvas to perform a resize in the existing code, or I might try redirecting the single-file import through the image2Canvas method to see if that works and if any functionality is lost. More testing to come!