IMDb 如何实时调整图像大小和裁剪?

发布于 2024-11-17 00:40:32 字数 1027 浏览 1 评论 0原文

我一直在研究 CDN 和图像缩略图生成,IMDb 的图像处理方式给我留下了深刻的印象。以下是缩略图版本的示例:

http://ia.media-imdb.com/images/M/MV5BMTc0MzU5ODQ5OF5BMl5BanBnXkFtZTYwODIwODk1._V1._SY98_CR1,0,67,98_.jpg

这是一个调整后的版本,可以调整大小和裁剪:

<一href="http://ia.media-imdb.com/images/M/MV5BMTc0MzU5ODQ5OF5BMl5BanBnXkFtZTYwODIwODk1._V1._SY400_CR10,40,213,314_.jpg" rel="nofollow">http://ia.media-imdb.com/images/M/MV5BMTc0MzU5ODQ5OF5BMl5BanBnXkFtZTYwODIwODk1._V1._SY400_CR10,40,213,314_.jpg

看起来非常简单,所有内容都来自 '.V1._。 ..' on 用于确定如何操作 图像。这一切都以令人印象深刻的速度完成,我决定找到一个模仿此功能的现有解决方案。

我能够找到大量关于图像调整大小的解决方案,并且我确实找到了 Google App Engine 上关于用 Java 转换图像的页面。但是,我不认为 Amazon 的 IMDb 正在使用 Google 来提供其图像,并且由于我的所有图像都位于 Amazon 的 S3 上,所以我认为我无法使用该解决方案。

经过四个小时的网上搜索,我决定向这里的聪明人请教。

进一步的背景:我正在 Amazon 的 Elastic Beanstalk 上构建一个 Web 应用程序,并且正在考虑使用一个单独的服务器(可能是另一个 Beanstalk)来处理图像......类似于 IMDb 正在做的事情。

预先感谢您的见解。

I've been researching CDNs and image thumbnail generation and I was impressed with how IMDb does its image manipulation. Here's an example of a thumbnail version:

http://ia.media-imdb.com/images/M/MV5BMTc0MzU5ODQ5OF5BMl5BanBnXkFtZTYwODIwODk1._V1._SY98_CR1,0,67,98_.jpg

And here's a tweaked version that plays with size and cropping:

http://ia.media-imdb.com/images/M/MV5BMTc0MzU5ODQ5OF5BMl5BanBnXkFtZTYwODIwODk1._V1._SY400_CR10,40,213,314_.jpg

It seems pretty straight forward where everything from '.V1._...' on is used to determine how to manipulate the image. This is all done impressibly fast and I decided to find an existing solution that mimics this functionality.

I was able to find plenty of solutions in image re-sizing and I did find the Google App Engine's page on Transforming Images in Java. However, I don't think Amazon's IMDb is using Google to serve its images and since all my images are on Amazon's S3, I don't think I can use that solution.

After four hours of online searching, I decided to ask the intelligent crowd here.

Further context: I am building a web application on Amazon's Elastic Beanstalk and I'm thinking of having a separate server (perhaps another Beanstalk) to handle the images...similar to what IMDb is doing.

Thanks in advance for your insight.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

烟凡古楼 2024-11-24 00:40:33

我无法谈论 IMDB 的具体实现,但我过去曾在 Amazon EC2 和 S3 上实现过类似的解决方案。以下是我的实现的概述:

  1. 所有主(全尺寸)图像存储在 S3 上,但不可公开访问。

  2. 所有图像 src url 都指向 EC2 Web 服务器。

  3. 图像的较小(缩略图)版本也存储在 S3 上,并具有标识其大小和宽高比的命名约定:

    • “myimage1_s200.jpg”是“myimage1.jpg”的方形版本,已调整为 200x200 方形。
    • “myimage1_h100.jpg”已调整为最大高度 100(宽度可变,符合原始宽高比)。
  4. 服务器收到特定图像大小的请求时:它会检查该大小是否已存在,如果存在,则将现有图像返回给请求者。

  5. 当 EC2 服务器收到对不存在的图像大小的请求时:它会检索同一图像的下一个更大尺寸版本的副本并调整其大小,并将新图像返回给请求者,并且还保存副本到 S3 以供将来使用。

性能说明:

  1. 如果您知道它们存在,将图像 src 直接指向 S3 上之前调整大小的图像会快很多!

  2. 在负载下调整图像的下一个较大版本的大小与始终返回原始版本相比要快得多!

I can't speak to IMDB's specific implementation, but I have implemented a similar solution on Amazon EC2 and S3 in the past. Here is an overview of my implementation:

  1. All master (full-sized) images stored on S3, but NOT publicly accessible.

  2. All image src urls point to an EC2 web server.

  3. Smaller (thumbnail) versions of images also stored on S3 with a naming convention that identifies their size AND aspect ration:

    • "myimage1_s200.jpg" is a square version of "myimage1.jpg" that has been resized as a 200x200 square.
    • "myimage1_h100.jpg" has been resized to a maximum height of 100 (with a variable width that conforms to the original aspect ratio).
  4. When the EC2 server receives a request for a specific image size: it checks to see if that size already exists, and if so it returns the existing image to the requester.

  5. When the EC2 server receives a request for an image size that DOES NOT exist: it retrieves a copy of the next larger size version of the same image and resizes it and returns the new image to the requester, AND ALSO saves a copy to S3 for future use.

Performance Notes:

  1. Pointing image src's directly to previously resized images on S3 is a lot faster if you know they exist!

  2. Resizing the next larger version of the image vs always going back to the original is a LOT faster under load!

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文