Jump to content

Enlarge image size


Recommended Posts

  • 3 weeks later...

uploaded images are marshalled by the function checkImage() within images.inc.php
function checkImage($file, $maxFileSize)
and the callee supplies max file size as an argument.

I believe the limits are hardcoded (are not settable via the BackOffice UI)
with the one exception --
BO } Preferences } Products } setting labeled "product images uploaded by customers".
This value gets stored to the database as:
configuation.PS_PRODUCT_PICTURE_MAX_SIZE
(Who intends to permit customer upload of product images? Not me!)

To adjust the cap for product images that employees upload as product images:
admin/tabs/AdminProducts.php
protected $maxImageSize = 2000000;
protected $maxFileSize = 10000000;
but, I'm compelled to state my opinion here -- if you're uploading fullsize images larger than 380Kb or so... something's wrong, as in, you must be missing a step in your workflow & are wanting to upload 12Mp digicam 'HighQuality' photos straight from the camera card (or something)

To change the limit for images uploaded for display within CMS pages, edit this:
modules/editorial/editorial.php
protected $maxImageSize = 307200;

Similarly, for watermark image:
modules/watermark/watermark.php
private $maxImageSize = 100000;

admin/tabs/AdminPreferences.php
contains additional hardcoded limits:
-=-
shop logo image
if ($error = checkImage($_FILES['PS_LOGO'], 300000))
-=-
shop logo image to be embedded in html email
if ($error = checkImage($_FILES['PS_LOGO_MAIL'], 300000))
-=-
logo image displayed on (PDF?) invoices
if ($error = checkImage($_FILES['PS_LOGO_INVOICE'], 300000))


Strange, but... each employee can customize his BackOffice by supplying a custom icon image for each tab... and the filesize of each icon image can be up to 2Mb!
classes/AdminTab.php
protected $maxImageSize = 2000000;
if ($error = checkImage($_FILES[$name], $this->maxImageSize))

while you're tweaking the image handling, I would recommend to edit:
images.inc.php
imagejpeg($newImage, _PS_TMP_IMG_DIR_.$cacheImage, 86);
and bump the hardcoded 'quality' paramater up to 89 or so

=============================================

FWIW, I arrived at this discussion thread while researching alternative image handling components (e.g. "jquery image resizer"). IMO, the image handlilng in prestashop SUCKS compared to other apps. At the VERY least, the BackOffice UI should expose individual settings enabling shop owner to adjust the quality/compression parameter for EACH 'image_type' (small, medium, large, thickbox, category, etc)
-=-
Do the devs expect prestashop will typically be installed to a VPS or dedicated server? I'd bet most installs are hosted on shared servers... and most webhosts are hella more restrictive on disk space than on bandwidth. Who benefits from prestashop creating 4+ resized versions of each product image?!? I could see the merit in having one, or perhaps two, in addition to the fullsize image... but css constraints could certainly be utilized to present any odd, or in-between sizes. ?Regenerate thumbnails? Hahaha, yeah right. Even if the script is set to handle batches of images vs all images (to stay within the constraints of PHP max_execution_time) webhost will NOT be amused at the resulting server load.

Link to comment
Share on other sites

not that you asked, but...

For, images uploaded via the CMS module
( tinyMCE toolbar icon } ajaxfilemanager )

this hardcoded value apparently governs the compression/quality setting:
admin/ajaxfilemanager/inc/class.image.php
var $_imgQuality = 90;

Link to comment
Share on other sites

Actually I can resize my pics in photoshop but I would like to know if there was any way to be able to upload pics bigger than 300 kb.
Part of my dissatisfaction with prestashop's image handling is due to the fact that we painstakingly post-process out product images prior to upload. I absolutely do not want the app to "mess with" the original file uploaded to the server, but it does so. Example:

==========================
original 1260 x 980 1,063KB

images.inc.php
imagejpeg($newImage, PS_TMP_IMG_DIR.$cacheImage, 89);

result after upload:

12-55-watermark.jpg ~~ 1260x980 ~~ 992Kb
12-55-thickbox.jpg ~~ 600x600 ~~ 113Kb
12-55-small.jpg ~~ 45x45 ~~ 2Kb
12-55-medium.jpg ~~ 80x80 ~~ 4Kb
12-55-large.jpg ~~ 300x300 ~~ 34Kb
12-55-home.jpg ~~ 129x129 ~~ 8Kb
12-55.jpg ~~ 12260x980 ~~ 457Kb

7 files ~~ 1,610Kb
==========================

What's wrong with this scenario?

1) The 'original' image is stored to the same (readable) directory as all other product images. If a shop owner wants to protect the 'originals' (in a given shop, maybe the original photos ARE the product) he must hack the core code or bend over and buy a paid third party 'module'. If you hack the code so that the 'originals' are chmod-ed, you can't link to them as virtual product digital downloads.

2) If a shop owner _DOES_ want to make the 'originals' available for viewing, there's no provision in the app to accomodate this (unless I've missed it) ~~ largest size presented to the prospective customer is via the light box (the 600px -sized copy). Again, the shop owner is faced with the prospect of hacking the core code or bending over and buying a paid third party 'module'.

3) Watermarking: 992Kb file is created, but is _NEVER_ served (unless you hack the code or buy a paid mod)... and if shop owner elects to protect the smaller sized images with watermark, this (otherwise unused and inaccessible) fullsize watermarked image is scaled down to create the smaller versions of the product image shrinking/blurring the watermark, instead of re-applying it at its intended size. Ah, there's a paid module to handle sensible watermark application... imagine that! Frankly, I am dismayed by the pattern I'm continually seeing, across the various features of the app -- the advertised features in the core are half-baked (my pet peeve so far is the shop search) as though to the intent is to 'create a market' for developers of paid modules.

4) Watermarking: the uninstall() for the module does not provide for an option to delete whatever xx-yy-watermark.jpg files have been created. How many shop owners have tried it (the module) then disabled and / or uninstalled it after seeing the crappy results in the scaled down images? Yeah, well... each of those shop installations are now storing, and eternally will be storing, MANY megabytes of these non-deleted, useless imagefiles (probably gigabytes, if a shop has 1000+ products).

At least 9 or 10 items in my list of ps image management grumbles, but I'll just stop ranting here.
This is already way beyond the scope of a 'feature request'. It's more like "what they been smokin?"
Link to comment
Share on other sites

I may be missing a point here, but in Back Office->Preferences-> Image you can set the resolution of the different images within your store (obviously you size these to fit with your theme) - so you can easily set the thickbox settings to be 1260x980 and the image will display like that in the thickbox. That would mean that the only "difference" that could be introduced would be in the jpg compression quality. This is only going to work of course if all your "full size" images are 1260x980.

The next issue would be in the maximum limits for file upload. I tend to agree with smiffy that in almost all cases you would never want your product images to be larger than the limits as they are set by default (you should also note that even increasing these within the core may not help, as your web host may place it's own limits). I think it's reasonable that if you're looking at selling items which are somewhat unusual (like full-quality images themselves) then you may need to customise Prestashop beyond what is configurable in the Back Office.

It would be nice if under that same admin screen you could set the various image quality settings though, as standard; I can't see any reason for not allowing it. I'm not a great fan of hard-coding limits into applications, as there's always someone who will feel they need to change it :D

Paul

Link to comment
Share on other sites

×
×
  • Create New...