Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Python Fu - Math operations failing
#1
Hi all,

I'm setting up a script, and part of it is to scale the image to a max size of 256 for one type of texture and a max size of 128 for a different type of texture. That aspect isn't working, so I isolated it into a separate script, and it's still not working. I've managed to figured out where the issue is happening, but not why. Here's the isolated code:

Code:
#!/usr/bin/env python
# -*- coding: utf-8 -*-
from gimpfu import*
   
def resizeMax(image, layer, texType):
   # Determine the max size based on the texture type:
   if texType == 0:
       # primary texture
       maxSize = 256
   else:
       # secondary texture
       maxSize = 128
   # Get the current dimensions of the image
   currentWidth = image.width
   currentHeight = image.height
   # Check which is bigger
   if currentWidth >= currentHeight:
       # Wide image or square
       scaleFactor = maxSize / currentWidth
       pdb.gimp_message("DEBUG: Scale Factor is")
       pdb.gimp_message(scaleFactor)
   else:
       # Tall image
       scaleFactor = maxSize / currentHeight
       pdb.gimp_message("DEBUG: Scale Factor is")
       pdb.gimp_message(scaleFactor)
   # Get the new sizes
   newWidth = scaleFactor * currentWidth
   newHeight = scaleFactor * currentHeight
   # scale the image accordingly
   pdb.gimp_image_scale(image, newWidth, newHeight)
   # Resize the layer to the image size
   pdb.gimp_layer_resize_to_image_size(layer)
   # Display the changes
   pdb.gimp_displays_flush()

def resizeMaxMain(image, layer):
   resizeMax(image, layer, 0)
   
register(
   "python_fu_test_resize_max",
   "",
   "",
   "BaconWizard17",
   "BaconWizard17",
   "January 2023",
   "Resize to Max Size",
   "*",
   [
       (PF_IMAGE, "image", "Input image", None),
       (PF_DRAWABLE, 'drawable', 'Layer, mask or channel', None)
   ],
   [],
   resizeMaxMain,
   menu='<Image>/Test'
)

main()

The issue is the line where the scaleFactor is being determined. For whatever reason, scaleFactor = int(maxSize) / int(currentWidth) is giving a value of 0, even though maxSize is nonzero (defined as 256) and currentWidth is also nonzero (512 in the image I was testing). I used pdb.gimp_message() to verify the values right before the operation, and they're what I expect. Maybe I'm doing the division wrong? I also tried converting maxSize and currentWidth to integers (with int()), but that didn't change anything either. Any thoughts would be appreciated.
Modder/Skinner at MarvelMods.com using GIMP to create, edit, and export textures and previews more efficiently.

My GIMP scripts hosted on GitHub
Reply
#2
scaleFactor = int(maxSize) / int(currentWidth) is returning zero because you're doing integer arithmetic. You need to make one or both into float values to get a fractional scaleFactor

Code:
> > > int(512) / int(258)
1
> > > int(512) / float(258)
1.9844961240310077
Reply
#3
(01-31-2023, 09:56 AM)Kevin Wrote: scaleFactor = int(maxSize) / int(currentWidth) is returning zero because you're doing integer arithmetic. You need to make one or both into float values to get a fractional scaleFactor

Code:
> > > int(512) / int(258)
1
> > > int(512) / float(258)
1.9844961240310077

The int() was something that I added later as an attempt to fix the issue, in case the original values were being output as strings. When I first posted my message, I had int() around those values, but later edited it out because the original code just said scaleFactor = maxSize / currentWidth

I did test with one of the values defined as a float() instead, and it worked. So are the values produced by image.width/image.height strings? Is that why it was originally failing?

Edit: I realized that I can check the documentation for this question, and that that operation produces an integer.
Modder/Skinner at MarvelMods.com using GIMP to create, edit, and export textures and previews more efficiently.

My GIMP scripts hosted on GitHub
Reply
#4
(02-01-2023, 12:19 AM)BaconWizard17 Wrote: I did test with one of the values defined as a float() instead, and it worked. So are the values produced by image.width/image.height strings? Is that why it was originally failing?

Edit: I realized that I can check the documentation for this question, and that that operation produces an integer.

In Gimp most coordinates values are integers (because they point at a specific pixel). The notable exception is paths where everything is a float. Be also aware that the values you receive as input parameters from things like PF_SLIDER are always floats, and may have to be cast to ints before use.
Reply
#5
(02-01-2023, 02:48 PM)Ofnuts Wrote:
(02-01-2023, 12:19 AM)BaconWizard17 Wrote: I did test with one of the values defined as a float() instead, and it worked. So are the values produced by image.width/image.height strings? Is that why it was originally failing?

Edit: I realized that I can check the documentation for this question, and that that operation produces an integer.

In Gimp most coordinates values are integers (because they point at a specific pixel). The notable exception is paths where everything is a float. Be also aware that the values you receive as input parameters from things like PF_SLIDER are always floats, and may have to be cast to ints before use.

Thanks for the tip! You all have been really helpful with me trying to figure out my issues.
Modder/Skinner at MarvelMods.com using GIMP to create, edit, and export textures and previews more efficiently.

My GIMP scripts hosted on GitHub
Reply


Forum Jump: