We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
  • I've been using pThumb on MODX Cloud server like this:

    <img src="[[+image:phpthumbof=`w=700&h=465&zc=1`]]" class="img-responsive" />


    And this works fine here: http://bootstrap.itristanmediagroup.modxcloud.com/. If you look at the 4 call to actions at the bottom of this page and reduce the browser it switches from 4 columns to 1 and the images scale accordingly.

    But on this server (http://gg.s.itristan.com/) the images are not being scaled with the same code. ImageMagick and GD are installed.

    Are there are libraries needed?
    • Are you sure that's a problem with pthumb? I thought that sort of responsive behavior depended on the CSS for the image widths.
        Studying MODX in the desert - http://sottwell.com
        Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
        Join the Slack Community - http://modx.org
      • Yes, I'm sure. It's all the exact same code. pThumb generates the size of the image and then Bootstrap handles the responsiveness.
        • A couple of possible issues involving ImageMagick are mentioned here http://stackoverflow.com/questions/1877564/phpthumb-cannot-find-imagemagick-imagick
            Studying MODX in the desert - http://sottwell.com
            Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
            Join the Slack Community - http://modx.org
          • It's writing cache files ok on both sites, which means that things are basically working, at least as far as pThumb can tell. It'd be returning the input image names if it were running into a problem either generating the thumbnails or writing them to the cache.

            What is the precise problem? If it's that on the 2nd server the 4 images towards the bottom of the page aren't being made 700x465 like on the first site but rather 269x176, then what are the dimensions of the input images? And are you using phpThumb or Resizer?
            One possibility is that the input images are too small to start with. By default small images won't be resampled larger, though depending on the value of the phpthumb_far setting (System Settings > core > phpThumb) phpThumb might scale them up without any extra parameters whereas Resizer won't unless you specify aoe=1 (Allow Output Enlarging).

            Although personally I'd avoid scaling images up. It'll make the files larger without adding any real resolution (i.e. the image won't get any sharper). Better to have the browser scale the image, if it comes to that. If you used width: 100% instead of max-width: 100% for .img-responsive then this would happen, though small images scaled up will still look crappy.

            The only strange thing is, it looks like the slider images above are getting scaled up to a lot bigger than their original size. What's the difference between those and the bottom images?
              Extras :: pThumbResizerimageSlimsetPlaceholders
            • The problem is basically one server behaves differently then the other. We are not concerned to much with scaling up because these are demo images. When the sites are actually live, appropriately sized images will be used (and indeed, they will most likely be uploaded in sizes larger then specified by the phpthumb settings, as clients often do. Yes, I realize that upscaling in general is a bad idea. Cropping, scaling, and compressing images automatically for clients is generally a good idea, in an attempt to avoid serving up 3MB monstrosities.

              We are use pThumb and phpThumb, not Resizer.

              Will investigate not scaling up by default as one server seems to be doing just that while the other isn't, though the one that isn't is a Vapor image of the one that is, with different content.

              Don't really want to hack anything.

              We will try again with to spec images for everything, including the gallery. The not to bad upscaling on the site hosted at the MODX Cloud is an anomaly I suppose. [ed. note: rx2 last edited this post 10 years, 3 months ago.]
              • Quote from: rx2 at Jan 30, 2014, 01:58 AM
                Will investigate not scaling up by default as one server seems to be doing just that while the other isn't, though the one that isn't is a Vapor image of the one that is, with different content.

                Besides the content, I can see at least one setting is different between the two sites: you have pThumb Cache set to No on the first site and Yes on the second. This shouldn't have any effect on the dimensions of the images, but it does mean the settings on the two sites aren't identical; maybe there are more differences?

                I'd check:

                1. Input image dimensions. If you have nice high-res input images on the first site, but undersized temp images on the 2nd, this could easily be the cause of what you're seeing (i.e. the first site is scaling down, the 2nd site isn't scaling up — two different things).
                2. The value of phpthumb_far (System Settings > core > phpThumb)
                3. The lower-level software which is actually doing the resize. The MODX Cloud site should be using ImageMagick, the other site could be using GD. There are a few possible differences in phpThumb's behavior depending on which one it's using. Turn on debug for pThumb, clear the thumbnails from the cache (to force generation of new ones), and check the MODX error log to see.
                  Extras :: pThumbResizerimageSlimsetPlaceholders
                • There are also server issues, the link I posted above mentions differences in ImageMagick versions as to how it reports itself (older versions without a -, newer versions with - depending on which version of phpThumb your MODX installation is using this may or may not be a problem), and whether or not the server is configured to allow exec(), since ImageMagick uses it.
                    Studying MODX in the desert - http://sottwell.com
                    Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
                    Join the Slack Community - http://modx.org
                  • Quote from: jgrant at Jan 30, 2014, 02:35 AM
                    Quote from: rx2 at Jan 30, 2014, 01:58 AM
                    Will investigate not scaling up by default as one server seems to be doing just that while the other isn't, though the one that isn't is a Vapor image of the one that is, with different content.

                    Besides the content, I can see at least one setting is different between the two sites: you have pThumb Cache set to No on the first site and Yes on the second. This shouldn't have any effect on the dimensions of the images, but it does mean the settings on the two sites aren't identical; maybe there are more differences?

                    I'd check:

                    1. Input image dimensions. If you have nice high-res input images on the first site, but undersized temp images on the 2nd, this could easily be the cause of what you're seeing (i.e. the first site is scaling down, the 2nd site isn't scaling up — two different things).
                    2. The value of phpthumb_far (System Settings > core > phpThumb)
                    3. The lower-level software which is actually doing the resize. The MODX Cloud site should be using ImageMagick, the other site could be using GD. There are a few possible differences in phpThumb's behavior depending on which one it's using. Turn on debug for pThumb, clear the thumbnails from the cache (to force generation of new ones), and check the MODX error log to see.

                    The Cache settings were just me playing. I will make sure they are both identical.

                    Exact same images are used so there is no difference in resolution/dimensions for the source images.

                    The value of far is C in both.

                    Lower level, as Susan also mentions, is, I believe, the key (ImageMagick is on both as well as GD). I never thought there was a problem with pThumb, just wanted to understand the differences in the servers that result in the different behaviour of the same code. But the solution of different versions of ImageMagick reporting differently involves changing some code so we'll probably go with production images that are at or above the needed resolutions. Besides, both servers are using the same version of ImageMagick.

                    MODX Cloud
                    Module Version (ImageMagick): 3.1.2
                    ImageMagick 6.5.4-7 2012-04-10 Q16 OpenMP http://www.imagemagick.org
                    GD Version: bundled (2.1.0 compatible)

                    Other Server
                    Module Version (ImageMagick): 3.1.2
                    ImageMagick 6.5.4-7 2012-05-07 Q16 OpenMP http://www.imagemagick.org
                    GD Version: bundled (2.0.34 compatible)

                    So there is a difference in GD versions.


                    Quote from: sottwell
                    There are also server issues, the link I posted above mentions differences in ImageMagick versions as to how it reports itself (older versions without a -, newer versions with - depending on which version of phpThumb your MODX installation is using this may or may not be a problem), and whether or not the server is configured to allow exec(), since ImageMagick uses it.

                    I will check if it is enabled.
                      • 40846
                      • 13 Posts
                      Hi,
                      I had a similar problem in my site.
                      in my call of phpthumbof, I was specifying:
                      &w=100
                      &h=100
                      not far or zc.
                      In my local server, it kept aspect ratio using those values as max-width and max-height.
                      When I decided to move the site to a server in the net, I copied all the files in my machine and the database to the new server and, after a few moments it was running on its new location. But the behavior was slightly different, it was ignoring the aspect ratio...
                      I don't know why the difference but itś no big deal.
                      Anyway, it isn't specific to phpthumbof or pthumb as it happens also in the modx m anager when showing the template variables for a resource.
                      In the local server
                      In the new server