• Starting names with underscores in Python has a special meaning, so no point in using _image and _drawable instead of image and drawable
  
• forground is spelled foreground
  
• speaking of foreground, it would be more proper IMHO to make a copy to use it as the image background
  
• the  drawable that you get as an argument could be a group, a layer mask, or a channel, you should probably bail out with a message for the last two. The group would be doable (the copy() makes a complete duplicate of the group, and you can flatten one of the two groups to blur the result).
  
• you can get the width and height of the image using the attributes of the image object: image.width, image.height, which is more readable than calling the PDB.
  
• In Python v2, an operation between int and float produces a float, so you can drop several uses of float() by using float constants: float(canvas_height) / 9 is also canvas_height/9.
  
• your if/elif has no else... which happens when the image is already 16/9 (*).
  
• lots of  common code between the two if/elif blocks. Some of it could be taken out. Personally, I would just set the new canvas/width or height. Then outside of the conditions the code would take care of offsets and such. Yes, the computations would yield  0 for one of the values...
  
• And when you do the above, you can remove the if/elif, because you can write: canvas_width = max(width_16_9,canvas_width) and same for height. And your code miraculously behaves if the image is already 16/9.
  
• I don't see the purpose of computing bg_scale, since anyway the background will be sized to the new  canvas dimensions that you already have.
  
• your blur radius could be dependent on the image size: a 90 blur isn't the same on a 200x200 image and a 2000x2000 image.
  
• you should bracket all your code except initial checks between image.undo_group_start()/image.undo_group_end() so that the whole effect of the script can be undone with a single Ctrl-Z.
  

• lots of  common code between the two if/elif blocks. Some of it could be taken out. Personally, I would just set the new canvas/width or height. Then outside of the conditions the code would take care of offsets and such. Yes, the computations would yield  0 for one of the values...
  

• I don't see the purpose of computing bg_scale, since anyway the background will be sized to the new  canvas dimensions that you already have.
  

(12-28-2024, 10:49 PM)origamifreak2 Wrote: Thanks Ofnuts  .

I've implemented most of your suggestions. The only ones I didn't are listed below with reasons why

• lots of  common code between the two if/elif blocks. Some of it could be taken out. Personally, I would just set the new canvas/width or height. Then outside of the conditions the code would take care of offsets and such. Yes, the computations would yield  0 for one of the values...
  

The code is very similar, but the values inside the if/elif blocks need to be calculated based on the canvas_width or canvas_height respectively.

• I don't see the purpose of computing bg_scale, since anyway the background will be sized to the new  canvas dimensions that you already have.
  

The background will actually overflow the new canvas size (see attached image). If I just resized the image to the new canvas size, it wouldn't have the same aspect ratio and would be squished horizontally or vertically

Let me know if there's anything else that can be improved.

(12-31-2024, 09:40 PM)origamifreak2 Wrote: I have a question. The gimp_drawable_type() function on line 9 is returning 0 for jpegs, 1 for pngs, and 1 for layer groups. How would I tell the difference between a single layer in a png file and a layer group? I'm probably missing something very simple here.

Code:

   # make sure drawable is a layer
   drawable_type = pdb.gimp_drawable_type(drawable)
   if drawable_type != 0 and drawable_type != 1:
       pdb.gimp_message(drawable_type)
       pdb.gimp_message("Please select a layer")
       return