Announcement

Collapse
No announcement yet.

Image attachment uploads

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Wayne Luke
    replied
    The resizing routines in vBulletin are not as complex as those found in Photoshop or Lightroom. Adobe has hundreds of developers working on and optimizing its products. They can also take advantage of multiple cores on a CPU to resize a single image. vBulletin has three developers. vBulletin is also limited by the resources allocated to PHP, which is often a small fraction of a core in a CPU. We also have to resize images without impacting performance for other users on the site.

    Resizing is an ancillary feature of attaching files and only exists to improve quality of life for the users. It isn't there for exact resizing. If you want the exactness of a graphics editing suite, then you will need to resize the image before uploading.
    Last edited by Wayne Luke; Mon 18 Nov '19, 12:39pm.

    Leave a comment:


  • imager
    replied
    Originally posted by Wayne Luke View Post
    How many bytes do you allow? There are three dimensions... X=1600, Y=1600.... Bytes=???

    All three have to be met.

    A 1600 X 1600 image at 24 bit color depth would have a maximum file size of approximately 7.6 megabytes. The JPEG compression algorithm will reduce this but I don't have the exact math on that. If you're trying to fit this image in less than 1 megabyte, it probably won't work.
    OK, I think I solved the problem, though only by trial and error. I am still confused about what the size (bytes) limit means. I had thought it was a target size resulting from compression. That's how image processing software like Photoshop or Lightroom works - when exporting an image to JPG format you can say something like, file size no more than 400K. The resulting image will be 400K or less.

    I took a test camera JPG image with low compression, 3888x3888 pixels dimension and 16.5MB size. To get this to compress to the full 1600x1600 Full-size limit I have configured attachments to be I had to increase the Max file size to 3MB. However the actual file size of the image once uploaded and resized was only 1MB. I previously tried 2MB but the resulting Full-size image was still smaller than the 1600x1600 limit.

    JPGs are compressed to start with, so they will be significantly larger when uncompressed. An uncompressed 1600x1600 image, as you say, will be 1600x1600x24 bytes = 7.6MB. So it's not that.

    Anyway, it works now and I'm making good progress in refining the settings in vB5 - I just wish it was easier!



    Click image for larger version  Name:	Capture.PNG Views:	0 Size:	321.3 KB ID:	4427172
    Last edited by imager; Sat 16 Nov '19, 1:05am.

    Leave a comment:


  • Wayne Luke
    replied
    How many bytes do you allow? There are three dimensions... X=1600, Y=1600.... Bytes=???

    All three have to be met.

    A 1600 X 1600 image at 24 bit color depth would have a maximum file size of approximately 7.6 megabytes. The JPEG compression algorithm will reduce this but I don't have the exact math on that. If you're trying to fit this image in less than 1 megabyte, it probably won't work.
    Last edited by Wayne Luke; Fri 15 Nov '19, 11:50am.

    Leave a comment:


  • imager
    replied
    So if the permissible maximum dimensions are 1600 wide or high, the longest size of an image that is originally larger when uploaded should be 1600?

    At the moment it goes significantly smaller.

    But if I upload, say, a 1600x1200 image, it's fine. Something seems to be amiss with the down-sizing where necessary.

    I'm using ImageMagick.

    Leave a comment:


  • Wayne Luke
    replied
    Images will be resized to fit all three parameters. X dimension, Y dimension, and File Size. If the system requires smaller dimensions to met the file size, the result will have smaller dimensions. All resized images will be written as JPEG files if they can't meet all three parameters.

    Leave a comment:


  • imager
    replied
    Originally posted by Wayne Luke View Post
    It is recommended to store binary data in the file system and not the database. Storing large amounts of binary data in your database will negatively impact performance.

    1. They are resized to the maximum limit specified under Attachments -> Attachment Storage Types. In both scenarios.
    2. Attachments should be unique to the user. Filenames aren't really relevant to detecting duplicates. In the file system they are stored by /u/sr/e/r/i/d/fileid.attach
    3. vBulletin doesn't retain EXIF information in either scenario. This is a security risk and can compromise your server.
    I have now successfully moved attachments from the database to the file system though it didn't work at first. It turned out that the default of 300 files per batch was far too high and it only worked to the end in batches of no more than 50.

    However, I do have another problem - I have set the maximum photo attachment size to be 1600 pixels in any axis. This works fine if the uploaded image is equal to or smaller than the limit. I was hoping that if the image was larger it would be resized to the 1600 pixel limit, but they are resized to around 700 pixels, which is too small for my needs.

    Is there a configuration in vBulletin for down-sizing attachments?
    Last edited by imager; Fri 15 Nov '19, 11:35am.

    Leave a comment:


  • imager
    replied
    Just to say, thank you for providing an option now for preserving camera exif metadata in photo image uploads with v.5.5.5 - much appreciated! Photographers using our forums will very much appreciate this.

    Leave a comment:


  • Wayne Luke
    replied
    If an image is resized, the original is never actually saved.

    There are no standards for what is allowed in EXIF data. Each camera, phone, and software package has their own idea on what is best to store here. In addition to this, nefarious actors can insert Javascript, PHP, and other code into the EXIF data to spread malware and compromise servers as well as the hardware of end users.

    Leave a comment:


  • imager
    replied
    Thank you Wayne Luke - just to clarify if an image is resized, is the original discarded? And can you explain why EXIF information is a security risk?

    Leave a comment:


  • Wayne Luke
    replied
    It is recommended to store binary data in the file system and not the database. Storing large amounts of binary data in your database will negatively impact performance.

    1. They are resized to the maximum limit specified under Attachments -> Attachment Storage Types. In both scenarios.
    2. Attachments should be unique to the user. Filenames aren't really relevant to detecting duplicates. In the file system they are stored by /u/sr/e/r/i/d/fileid.attach
    3. vBulletin doesn't retain EXIF information in either scenario. This is a security risk and can compromise your server.

    Leave a comment:


  • imager
    started a topic Image attachment uploads

    Image attachment uploads

    I read in a separate thread that in some circumstances it was advisable to store attachment originals in the server files system rather than the database. Currently they are store in the database with my forum and I am considering using the option to export from the database. I have a few questions:

    1. Are the versions in the database the same size as uploaded or if they exceed the set size limits and resized are the resized versions stored or, indeed, are both stored?

    2. How are images named - is there a potential for name duplication in the file system store?

    3. Not directly related but is there any way to retain exif (camera settings) metadata in photos that have been uploaded?

    Thanks

Related Topics

Collapse

Working...
X