Re: html5是否可以考虑加入“缩略图”的解决方案

看了一下对问题的描述，个人觉得对于“缩略图”的需求，至少有2个问题需要考虑：

1. 如何生成“缩略的图片”：
    A. 由客户端生成，则网络上传输的开销完全不变，现有流利器均可以根据<img>元素的width/height属性来缩放图片
    B. 由服务器生成，则需要服务器相应的实现，但如果服务器有了实现，那么<img
src="/images/large.png?size=40x40" />是否也同样可以让服务器生成“缩略的图片”呢？
2. 何时显示“非缩略的图片”，这个根据具体的需求场景有不同，例如google image
search在mouseenter时显示一个“半缩略图片”，在click后打开新页面显示一个“非缩略图片”，标准是否要对此类行为作一个统一？如果行为没有统一，均需要javascript编写，例如访问img.requestFullSizeImage()来形成“非缩略图片”，则考虑以下代码是否也可以实现：
HTMLImageElement.prototype.requestFullSizeImage = function() {
    this.src = removeQueryFragment(this.src, 'size'); //
移除querystring中的size参数
}

2012/2/16 CHEN Xing <cxcxcxcx@gmail.com>

> 2012/2/15 暴雨不在明天 <bybzmt@gmail.com>
>
>>
>> 好像我们说的不是一个东西。。。我的意思是定义一种新的图片传输封装方式，恩有点类似于视频里的流媒体那种，用户快进到哪一段就从服务器上加载哪一段，并且可以缓存。
>> 以现在的情况来说的话可能实现成一个loader的接口会比较合适（可以平滑过度）
>> <img loader="xxxx"... 由loader解决加载和渲染实现
>>
>
> 首先数据（图片）得支持才行，但现在的图片格式不都支持这个，图片也不都支持这个。以JPEG这种常见的格式为例，Progressive
> JPEG应该也是在频域上逐渐增加细节，缩小了的图片在部分展示时一般仍然是不清晰的。而interlaced GIF，大概是每八行一存，不能真正逐级载入。
>
> 如果为了实现这个功能去定义新的图片格式并重新编码图片，代价太高了。
>
>
> 从可行性的角度讲，这种格式其实应该是非常难实现的。图片展示的大小一般是几个固定的尺寸，由网页设计者选定，但是跟原图的尺寸没有必然的联系。可以预想任何一种技术都难以从部分数据恰好恢复出指定尺寸的图片……
>
>
> CHEN, Xing / 陈醒
>
>
>>
>>
>> 在 2012年2月16日 下午2:13，Hawkeyes Wind <hawkeyes0.cn@gmail.com>写道：
>>
>>  首先，并不是所有jpg格式的图片都能隔行加载，其次浏览器应该做的是根据网页作者定义的width、height、max-width、
>>> max-height、min-width、min-height的样式来显示图片的大小，就算是个大图也能用样式缩得很小。
>>>
>>> 根据jpeg的算法，从一张缩略图和原图之间的二进制比较结果来看，并没有相同的数据存在。
>>>
>>> 另一方面来说，如果由浏览器根据图片大小强制终止文件传输，可能的结果是服务器的内存在一定时间内无法被释放，从而增加服务器端压力。
>>>
>>> 缩略图的意义在于减少传输量，但这并不是浏览器的职责。
>>>
>>> 于 2012/2/16 13:24, 暴雨不在明天 写道:
>>>
>>> 我说的是部分加载功能，类似于jpg的隔行加载功能。
>>> 如果缩略图只有原图1/4大那只要4像素取１像素就可以了，这样就只传输了1/4的数据（这部分由服务器完成）
>>>
>>> 在 2012年2月16日 下午1:00，Hawkeyes Wind <hawkeyes0.cn@gmail.com>写 道：
>>>
>>>> 如果由浏览器来处理缩略图 的话，用户依旧需要下载完整的大尺寸图片。这种情况 下用户需要等待的时间会大大增加。
>>>>
>>>>
>>>> 所以还是由服务器端处理缩略图是比较合理的。服务器可以只存大图，再根据页面 的不同临时生成缩略图传递给用户会比较好。
>>>>
>>>> 于 2012/2/16 11:51, -暴雨不在明天 写道:
>>>>
>>>>  缩略图是现在web上非常非常常用的一个功能。
>>>>>
>>>>> 应用场景：
>>>>>    1. 当页面需要显示很多图片时,通常我们只显示这些图片的
>>>>> 缩略图从而加快页面的显示。而大图通常需要点击后才能显示。
>>>>>
>>>>>    2. 相册的应用中，一般会会先显示缩略图然后用户点击查看
>>>>> 感兴趣的图片，当用户对某些图片特别感兴趣可能还原查看或
>>>>> 下载原始尺寸的图片（通常会非常大）。
>>>>>
>>>>> 但是这种应用并不完美:
>>>>>    1. 我们需要在服务器端为同一张图片保存不同尺寸的缩图，这
>>>>> 很些图片的创建/管理是一件很麻烦的事情。另外对服务器空间也
>>>>> 影响（虽然对现在硬盘来说影响相对小）。
>>>>>
>>>>>    2. 在客户端我们需要为同一张图片的不同尺寸的图片建立不同的
>>>>> 链接，而且当我们需要查看更大尺寸的图片时，前面载入的缩略图
>>>>> 数据并不能起到作用，这会浪费相当的流量。而且我们在相册的应用
>>>>> 中，大图和原图可能相差不多大或者根本就是一样的，这个时候的浪
>>>>> 费是相当大的。
>>>>>
>>>>> 如果我们能在浏览器上建立对缩略图的支持我就可以避免这种情况。
>>>>> 例如：
>>>>> 我们有一张1920*1200的图片.
>>>>> html：<img src="img_01" style="width:480px;height:300px" />
>>>>> 这里浏览器可以:
>>>>> request: img_01
>>>>> size:480,300
>>>>> 服务器可以直接从图片中取出相应的数据反回过来
>>>>> (4个像素中取１个像素就可以）
>>>>> 这个时候如果用户需要查看大图就会：
>>>>> request:img_01
>>>>> cache:480,300
>>>>> size:1280,800
>>>>> 服务器可以去掉己缓冲的480,300部分而反数据
>>>>>
>>>>> 这样我们的缩略图就是可以大大简化了（对程序员来说）
>>>>> 而且可以实现无级缩放，并有效降低网络负载。
>>>>> 还可以让用户在web上对图片进行放大缩小操作，就像我们查看
>>>>> 本地图片一样，这时用户体验会有很大提升。
>>>>>
>>>>> ps:话说这只是我早上起床灵光一闪并没有仔细考虑，大家不要见笑。
>>>>>
>>>>
>>>>   --
>>>> Regards
>>>>
>>>> Hawkeyes Wind
>>>>
>>>>
>>>>
>>>
>>> --
>>> Regards
>>>
>>> Hawkeyes Wind
>>>
>>>
>>
>


-- 
张立理 GrayZhang
博客：http://www.otakustay.com
微博：http://www.weibo.com/otakustay
邮箱：otakustay@gmail.com