<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>照片 &#8211; 老范讲故事｜AI、大模型与商业世界的故事</title>
	<atom:link href="https://lukefan.com/tag/%e7%85%a7%e7%89%87/feed/" rel="self" type="application/rss+xml" />
	<link>https://lukefan.com</link>
	<description>这里是老范讲故事的主站，持续更新 AIGC、大模型、互联网平台、商业冲突与资本市场观察，帮你看清热点背后的底层逻辑。</description>
	<lastBuildDate>Sat, 16 Jul 2011 10:25:07 +0000</lastBuildDate>
	<language>zh-Hans</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=6.9.4</generator>

<image>
	<url>https://lukefan.com/wp-content/uploads/2026/03/cropped-jimeng-2026-02-28-5245-用图一的人物形象，替换图二中的人物，使用图二的风格。文字替换：老范讲故事，Yo-32x32.jpeg</url>
	<title>照片 &#8211; 老范讲故事｜AI、大模型与商业世界的故事</title>
	<link>https://lukefan.com</link>
	<width>32</width>
	<height>32</height>
</image> 
	<item>
		<title>图片存储和分享开源系统的设想</title>
		<link>https://lukefan.com/2011/07/16/%e5%9b%be%e7%89%87%e5%ad%98%e5%82%a8%e5%92%8c%e5%88%86%e4%ba%ab%e5%bc%80%e6%ba%90%e7%b3%bb%e7%bb%9f%e7%9a%84%e8%ae%be%e6%83%b3/</link>
		
		<dc:creator><![CDATA[Luke Fan]]></dc:creator>
		<pubDate>Sat, 16 Jul 2011 10:25:07 +0000</pubDate>
				<category><![CDATA[梦想园]]></category>
		<category><![CDATA[照片]]></category>
		<guid isPermaLink="false">http://lukefan.com/?p=367</guid>

					<description><![CDATA[好像好久没有更新博客了，以前在上海的时候，还能够坚持每周更新一次。现在会到了北京，周末的时间能够和家人在一起， ... <a title="图片存储和分享开源系统的设想" class="read-more" href="https://lukefan.com/2011/07/16/%e5%9b%be%e7%89%87%e5%ad%98%e5%82%a8%e5%92%8c%e5%88%86%e4%ba%ab%e5%bc%80%e6%ba%90%e7%b3%bb%e7%bb%9f%e7%9a%84%e8%ae%be%e6%83%b3/" aria-label="阅读 图片存储和分享开源系统的设想">阅读更多</a>]]></description>
										<content:encoded><![CDATA[<p>好像好久没有更新博客了，以前在上海的时候，还能够坚持每周更新一次。现在会到了北京，周末的时间能够和家人在一起，反而没有时间更新博客了。后面还是尽量保持更新吧。虽然我的博客看的人不多，就算是给自己留下的一些回忆吧。</p>
<p>这篇博客，是很早之前写的，前面几篇博客也提到过，但是由于一些比较麻烦的问题，一直没有贴，最近好像麻烦的问题都处理干净了，那么就贴出来吧，这个周末如果有时间的话，没准儿还能再写一点儿。</p>
<h1>为什么需要这种开源系统</h1>
<p>在写这篇博客的时候，我并不知道是否已经存在了这样的一套系统，或类似的系统。可能有，也可能没有。我想，有的可能性应该更大一些吧。</p>
<p>这种开源系统，是为了解决不同的人，不同的机构之间进行图片应用开发过程中进行分工的。如果每一个想要提供图片底层服务的企业、团队或者个人，都去编制一套自己的标准，并设立一套自己的API和接口。那么，那些想要开发上层图片应用的个人或机构，就必须做出选择，到底是使用哪一家的。一旦他们做出了选择，则很难再进行改变。一次只能使用1家的服务，很难为统、同一个上层服务，选择多家供应商提供的底层服务。</p>
<p>如果有一套开源的系统，一套相对简单，但功能基本完整的图片底层服务接口。有很多厂商以此为基础，提供服务。那么是不是可以部分解决这种问题呢？有这种可能，但也不能肯定。毕竟很多大的厂商，喜欢搞封闭的一套。</p>
<p>所以这里只能说是一种设想和可能。并不是对此类系统进行可行性的分析。</p>
<h1>基本的架构</h1>
<p>这种系统，通常是分为底层架构、功能实现和扩展接口三个部分的。这里并不是做软件架构，所以就不那么详细的来分拆了。只是把一些软件需要具备的基本功能，和留给扩展的接口简单的介绍一下。</p>
<p>我并不想自己去开发一套类似的东西，至少目前还不想。所以说是功能介绍，好像并不太准确。作为一篇准备放在梦想园板块中的博客，大家就当我是在介绍一个梦想中已经实现了的软件吧。</p>
<h2>结合OpenID的认证系统</h2>
<p>照片系统中，有一个功能是必须具备的。那就是用户认证系统。如果是像传统网站那样自己搞一套用户注册体系，那么肯定是会有问题的。因为这套系统的设想是分布在不同的网站或服务器上，然后让用户自由选择，将照片放到不同的服务器上。一个用户可能同时会使用多个照片服务器。那么就要求照片服务器所使用的用户登录和认证体系必须是统一的。按照现在的流行趋势来看，使用OpenID认证系统看来是一个不错的选择。</p>
<p>现在，提供OpenID认证体系的公司越来越多了，甚至国内还有一些小型的网站，利用开源系统，提供OpenID认证。国内比较常用的一些认证体系，也逐步开始支持OpenID了。</p>
<p>图片系统如果能够使用OpenID，那么就有可能实现跨服务器的认证和权限分配。可以在不同的服务器上，使用同一个OpenID进行登录和认证，只有这样才有可能实现跨服务器的图片存储。</p>
<h2>统一的图片调阅权限审核</h2>
<p>图片除了写入时的认证之外，还有一个非常重要的问题，就是图片的调阅认证，什么样的人，可以调阅什么样的图片，这是避免陈冠希悲剧再度重演的必要保障。由于图片是存放在不同服务器上的，那么最好能够直接将调阅权限和每一张图片绑定，每一张图片单独的判断，来人是否有权调阅。</p>
<p>应该使用统一的短链接服务，来进行所有图片的解析。这样所有图片的连接地址，就统一了。每一个需要调阅图片的访问，都使用统一的短链接进行调阅。在短链接转换之后，到特定的图床服务器上去验证调阅的权限。调阅者最好和图片拥有者使用统一的OpenID系统来进行认证，这样的话，关系的处理，就可以放到图床体系的外面去了。</p>
<h2>基本的图片加工系统</h2>
<p>图片进入图床服务器之后，根据不同的需要，可以进行一些简单的图像加工和变换。这个系统，应该是建立在图床服务器里面的，图床服务器应该提供一些基本的功能，并留出开放的接口，可以接入其他标准的图片加工工具。</p>
<p>通常会用到的图片加工类型有：格式转换、精度和分辨率转换、剪裁、水印、简单的色彩调整，以及图片的拼接等。这些功能基本上使用现有的imagemagick应该都是可以实现的。至于一些特殊的图像转换，比如2D转3D，添加版权水印等，都可以留出接口，让需要的人自己去添加。</p>
<p>图片是属于图片所有者的，那么图片的各种变形，理论上来说也应该是属于图片所有者的。如果图片所有者能够提供这些图片的常用变形版本，那么大部分图片调阅者都会选择直接调阅的。所以图床系统缓存原始图片的各种常用变形对于图片的传播和保存，都是有好处的。系统可以在图片的某些特殊格式或变形被调阅的时候，自动生成符合要求的图片，然后进行缓存，如果同样的格式再次被调用，那么就直接使用缓存的结果。</p>
<p>可以在图片的短链接后面，添加上对于格式的要求，来形成新的图片链接。比如：http://***.**/aCq3D/w800BW 就可以代表前面那幅图片宽度为800的黑白二值版本。</p>
<p>这样，每一个图片有一个唯一的url链接，同一张图片的不同变形，也有唯一的url链接，而且这个链接和原图的链接是有明确关联的，任何人或系统，可以在得到原图url或某一种特定变形的url之后，计算出这个图片其他各种变形的url来。图床服务器可以不用为每一个特定的变形进行运算，得到某种特定的变形url访问之后，首先要判断的还是权限的问题，要判断访问者是否有权限使用这种特定的变形。比如说，通常不是每个人都有权限调阅原始图片的。 一些相近的图片变形，是可以互相替换的。比如，有人刚调用了一次宽度为800的图片，图床服务器进行了运算，并缓存了这个分辨率的图片，紧接着又有人来调用宽度为790的图片，那么就不用运算了，直接将800的给出去就好了。</p>
<h2>统一的图片短链接服务</h2>
<p>提供图片短链接，应该是和普通短链接不同的。普通的短链接是使用完整的连接，进行hash之后，得到的一个几十甚至是上百进制的数值。所生成的数值，只与原来的URL有关。</p>
<p>图片的短链接，应该是与图片本身相关的，也就是说，可以直接对图片进行指纹提取，然后再对图片解压缩后的原始二进制数据，进行hash，然后使用这个hash值对图片网址进行存储。这样的话，就可以实现相同的图片，使用相同的短链接，多个存放了相同图片的URL，其相对应的短链接是一致的。然后使用负载均衡来自动派发请求。即使图片的存储的格式有些许差异，其对应的短链接，也是一样的。</p>
<p>由于上文中说到的各种图片变形格式的唯一短链接，所以这个系统还有一点有别于其他短链接系统，这个短链接系统需要在那一窜几十上百进制的字符串之后，留出一段明文的，可以进行解析的图片格式说明语言。每一个图床服务器上的URL，过来注册和转换短链接的时候，应该标明自己支持哪些格式标识，这样短链接服务器在转换短链接的时候，就可以根据用户请求的特定格式，来分配服务器。</p>
<p>这个短链接系统，应该是和图床系统相分割独立的，但又是相辅相成的，这里就把它作为一个图床的辅助系统，写在这里吧。</p>
<h2>图片的组织和存储系统</h2>
<p>图片本身，是有一定的关系的。由于现在基于图片的搜索还比较困难，目前只有google的picasa里面使用到了头像识别来进行图片的标示和定位。所以通常是使用一些文字来对图片进行标注、分类和描述，也有些系统可以使用时间和地理位置来定位图片。</p>
<p>对图片进行标示和分类、文字描述，其目的就在于希望能够更方便、更准确的搜索和定位图片。如果要做一套开源的，可以多服务器联合工作的图床系统的话，那么就要求图形的组织、标示、标注和分类、文字描述等系统，是独立于所有图床服务器之外的，是可以跨服务器工作的。那么，这里的设想就是，图床服务器是独立工作的，只负责处理图像的存储和调阅以及相关过程中的权限设定和审查、验证，图床服务器不互相引用其他同类服务器。所有图片的组织和分类信息，由其他系统来完成这里不讨论。</p>
<p>图片使用的审计和统计系统</p>
<p>图片的上传、修改和调阅，是需要一个日志系统的。那么这个日志系统，可以附带各种审计和统计的功能。甚至可以一次为接口，开发一些计费功能。开源软件上就不需要计费系统了，但是可以把接口保留下来，以备日后使用。</p>
<h1>功能的设想和拓展</h1>
<p>一个系统的生命力，部分取决于其可扩展性。为了保持一定的扩展性，开源图床应该具备一些必要的接口，来进行某些扩展。</p>
<p>前面提到的图片转换接口，可以在基本图片加工和转换功能之外，添加特定的图片转换功能。</p>
<p>图片存储和使用的统计，并最终留出计费接口。</p>
<p>开源的图床系统，只需要考虑单机工作就好了，但是如果有的公司系统以此为基础，建立大型系统，那么也应该留出自组网和多服务器协同工作的接口。</p>
<p>至于分享到微博等social网站、接受反馈并记录，进行分类和标注标识等等，应该是在其他系统里面完成的，和本系统无关。那些系统可以依靠开放的API接口来使用本系统中的图片资源，可以使用同样的认证体系。</p>
<h1>调整、部署以及推广</h1>
<p>本文纯属YY，那么就让我继续Y完吧。如果真的有了这么一套系统，那么应该如何推广呢？首先要去吸引那些个人站长，他们可以在自己租用的空间上部署，并存放一些自己的照片，也可以存放一些朋友的照片。然后，可以让一些个人或小团队，在此基础上，建立一些小的，基于图片的新的应用。如果这些能够成功的话，最后可能会有企业对其进行修改，添加上计费的模块，并部署更大型的，但与之相兼容的系统。</p>
<p>隔了好久都没有更新博客了，事情有些多。我想这不应该成为理由。回到了北京，周六日需要陪伴家人，没时间写博客了，这是其中的一个原因，这篇东西，写了好几周，我自己也不是很满意，但最终还是觉得应该丢出来，算是对自己思想的一种记录吧。以后尽量保持每周写博客，但是也很难保证，只能说尽量吧。</p>
]]></content:encoded>
					
		
		
			</item>
		<item>
		<title>连环画和微博的结合——续</title>
		<link>https://lukefan.com/2011/04/15/%e8%bf%9e%e7%8e%af%e7%94%bb%e5%92%8c%e5%be%ae%e5%8d%9a%e7%9a%84%e7%bb%93%e5%90%88%e7%bb%ad/</link>
		
		<dc:creator><![CDATA[Luke Fan]]></dc:creator>
		<pubDate>Fri, 15 Apr 2011 10:45:07 +0000</pubDate>
				<category><![CDATA[梦想园]]></category>
		<category><![CDATA[微博]]></category>
		<category><![CDATA[推]]></category>
		<category><![CDATA[数码摄影]]></category>
		<category><![CDATA[照片]]></category>
		<category><![CDATA[社区]]></category>
		<category><![CDATA[移动互联网]]></category>
		<guid isPermaLink="false">http://lukefan.com/?p=345</guid>

					<description><![CDATA[上一篇连环画和微博相结合发出去之后，和一位同事聊了聊。觉得还有些地方没有说得很清楚。那就是这种应用应该如何起步 ... <a title="连环画和微博的结合——续" class="read-more" href="https://lukefan.com/2011/04/15/%e8%bf%9e%e7%8e%af%e7%94%bb%e5%92%8c%e5%be%ae%e5%8d%9a%e7%9a%84%e7%bb%93%e5%90%88%e7%bb%ad/" aria-label="阅读 连环画和微博的结合——续">阅读更多</a>]]></description>
										<content:encoded><![CDATA[<p>上一篇连环画和微博相结合发出去之后，和一位同事聊了聊。觉得还有些地方没有说得很清楚。那就是这种应用应该如何起步，如何运营。</p>
<p>最近注册了点点网，看到了轻博客。很多人都觉得，微博的140字限制，是由于受到手机短信的限制。总觉的在微博和博客之间总还应该有一些中间地带。buzz和搜狐微博都是不限制字数的，但是这两个东西发展得都不是很好（纯属个人感觉）。原因很多，不知道取消了字数限制算不算是其中之一。</p>
<p>这里不讨论轻博客，还是说那种结合很多图片的微博。</p>
<p>如果有人想要做这种东西的话，一定要和现有的微博结合好，千万不能脱离现有的那些成功微博系统。</p>
<p>一开始可以以微博客户端和插件的形式存在。也就是说在普通的微博中，隐藏一个特定的短链接，对于新浪微博来说这些短链接还会再被<a href="http://t.cn">http://t.cn</a> 重新包装一次，不过这并不重要。当使用特定的客户端或网址来进行解析的时候，可以直接将这个短链接解析成一个图片的序列。</p>
<p>发送内容的时候，用户选择了多幅图片，上传之后可以自动生成一个竖排的缩略图，并根据用户的设定，将缩略图投递到各个绑定的微博账号上去，再在后面填上一个短链接。这里所说的功能和那些微博通之类的微博账号同步服务不同的是，要将完整的内容存放在自己的网站上，已备用户查阅。当有人点击那个短链接的时候，直接返回连环画微博网站，可以看到相对完整的文字描述和图片序列。对于回复和转发的消息，也可以在其中嵌入这种短链接，如果使用特定的客户端软件或网址来查看，那么回复和转发的信息上也就可以放置图片序列了。</p>
<p>这里就需要对同一个短链接的两种不同的解析方式，如果是各种微博官方的网站，或不支持这种连环画解析的客户端，则直接显示短链接。点击之后，返回连环画微博相应的条目。如果是直接使用的连环画微博的网址，或支持连环画功能的客户端，则直接解析为图片序列。</p>
<p>如果这一步能够做好，应该能够吸引到一些人来使用此工具发送带有图片序列的内容。很多用户会点击微博上的短链接，跳跃到连环画微博上来查看详细内容。其他人如果想要看到带有图片序列的回复和转发信息，或在回复、转发中添加图片序列，那么也会开始使用这种客户端。这样就可以达到网站和客户端推广的目的。</p>
<p>网站上要存放那些微博的信息，其中图片可以放到图床上去，只要保存文字信息，以及信息之间的关系就好了。关于图床的设想，我写了另外一篇博客，我会在后面放出来的。只存放文字信息，以及文字信息之间的回复、转发关系。至少在初始阶段，压力应该还不是很大，如果存这些东西都会有压力的话，只有两种可能：第一、程序写得太烂；第二、捧着钱找上门来的投资人，已经等在门外了。</p>
<p>除了收发这些内容之外，随着时间和用户的增长，这个网站会积攒下越来越多的数据。然后，就可以依靠数据挖掘和聚合功能，将图片序列，以及相关的文字描述，按照相关的时间、事件、地点等各种各样的分类方式聚合起来，推荐给那些想要看微博杂志的人。</p>
<p>网站上只存放内容，并不要求用户重新建立关系。关系还是保持在传统的微博体系中，甚至有人可以通过看聚合之后的内容，再去原来的微博系统中关注发帖人或相关人。这有利于原有微博体系中关系的传播和建立，对于那些想要提升自己影响力的人们来说，应该也是有吸引力的。</p>
<p>由于网站并不保存任何关系，所以其信息聚合之后形成的杂志，完全是让大家搜索和订阅的，和微博上的follow网络，没有直接的关系。</p>
<p>当系统建立起来，并拥有足够多的内容订阅者之后，就可以考虑让用户再在此基础上添加点评或digg之类的功能。这里所说的订阅者，指的不是那些通过连环画微博系统发送微博和阅读微博的人，而是那些直接进入连环画微博系统，搜索和订阅特定分类的连环画信息的人。这些点评和digg的功能，还是可以在那些专为传统微博开发的客户端上体现，让人们可以对微博进行一定的点评、分类和digg。即使人们不去做转发、回复和收藏，也可以做这些事情。在做转发和回复的时候，用户可以自己选择，是否将这些信息写入转发或回复的内容中。当这些信息积累到一定程度的时候，就可以根据这些信息推出更多维度的图集和网络杂志。为订阅者们提供更多的选择和筛选的途径。</p>
<p>信息本身是具有价值的，当信息聚集起来之后，这些价值会随之上升。信息的挖掘本身也是有价值的，搜索的结果、排序的结果、过滤的结果，这些东西本身都是有价值的，比那些无序的数据要更有价值。以后肯定会出现很多人，使用各种专业工具，来进行全职的信息挖掘。他们依靠搜索、过滤、排序，以及统计分析，从历史数据中找到有价值的内容，然后重新包装发布出去。</p>
<p>微博和SNS，所关注的是人与人之间的关系，这里所说的系统，主要关注的是信息之间的关系，以及通过这些关系组合起来的信息，在不同的颗粒度、不同的维度上所产生的价值。</p>
<p>对于连环画和微博的结合，这篇博文，是对前面一篇的继续，希望能够将实施的过程稍微的设想一下。当然，如果真的有人想要去实施这种东西的话，中间肯定还会遇到很多其他的问题。我并没有真的去实施过此类项目，所以这些内容绝对应该是属于梦想园的。如果有人想要对细节进行探讨，欢迎。如果有人指责其中有什么问题，也欢迎。但请先去看看<a href="http://lukefan.com/?p=148">梦想园的开篇</a>，了解一下梦想园存在的目的。</p>
]]></content:encoded>
					
		
		
			</item>
		<item>
		<title>连环画与微博的结合</title>
		<link>https://lukefan.com/2011/04/10/%e8%bf%9e%e7%8e%af%e7%94%bb%e4%b8%8e%e5%be%ae%e5%8d%9a%e7%9a%84%e7%bb%93%e5%90%88/</link>
		
		<dc:creator><![CDATA[Luke Fan]]></dc:creator>
		<pubDate>Sun, 10 Apr 2011 09:50:31 +0000</pubDate>
				<category><![CDATA[梦想园]]></category>
		<category><![CDATA[微博]]></category>
		<category><![CDATA[推]]></category>
		<category><![CDATA[数码摄影]]></category>
		<category><![CDATA[照片]]></category>
		<category><![CDATA[社区]]></category>
		<category><![CDATA[移动互联网]]></category>
		<guid isPermaLink="false">http://lukefan.com/?p=340</guid>

					<description><![CDATA[一种结合连环画和微博的系统的设想。]]></description>
										<content:encoded><![CDATA[<div>
<div>现在，微博无疑是非常火爆的，有图片的微博，更是吸引大家的眼球。网站上，各种画报或幻灯类的应用也非常普遍。这说明用户非常喜欢分享和订阅图片、照片，或图片类的信息。现在的手机，大多具备照相的功能，ipad等平板电脑可以连接数码相机，现在ipad2也可以拍照了，那些能够进行照片拼接和变形的应用，也非常的受欢迎。</div>
<div>遗憾的是，和twitter不同的是，国内的微博，习惯于自己存储照片，这样做的好处在于方便进行统一的监督和管理，但是缺陷也有很多，比如必须占用很大的空间和带宽，不便于图片所有者的统一管理等。而且，现在的微博，只有原帖上可以加图片，加上去之后，就不可以再修改了。如果需要，只能将整条微博删掉。回复和转发贴上，都是不允许附带图片的。最讨厌的是，每条原帖，只允许携带一张图片，这就导致了，如果想要发送多张图片，就必须使用拼图软件，进行拼接。只有原帖才能携带图片，是国内微博的创造，twitter上是没有这种限制的。不知道当时做这种设计的时候，那些产品经理是如何考虑的？</div>
<div>常见的图片展示和分享方式，除了像微博那样，一次一张之外，还可以像幻灯片那样展示，以及像连环画那样，顺序的叠加所有的图片。我很喜欢连环画式的图片阅读方式，因为这样可以非常简单的顺序看到所有的图片，不需要来回的翻页。其实，这种连环画式的图片分享方式，是最传统的一种图片分享方式了。bbs论坛上面，就是这么做的。wordpress等博客系统上也是这么做的。</div>
<div>我这几天参加QCon的时候，发送了很多带有照片的微博，其过程是非常痛苦的。我先用尼康D80拍摄高分辨率的照片，然后使用IPAD上的配件，将SD卡里面的照片导入到IPAD。然后竟然发现新浪微博的IPAD官方应用有个bug，如果我直接添加一张千万像素的照片的一条微博里面去，点击发送的时候，这个应用会直接退出。最后只能下载了一个Photo Mess，对图片进行缩放和拼接。然后再将处理好的图片插入到微博中，才能发出去。</div>
<div><img decoding="async" src="http://ww3.sinaimg.cn/bmiddle/657649c9jw1dg38nmo257j.jpg" alt="" /><br />
<img decoding="async" src="http://ww1.sinaimg.cn/bmiddle/657649c9jw1dg21nxuve0j.jpg" alt="" /></div>
<div>如果能够直接搞一种类似于微博的系统，专门让大家贴图片，其客户端可以直接选择多幅图片，并调整顺序。自动对太大的图片进行缩放，然后对选中的图片进行统一的色彩或色调的调整。再上传到一个专门进行图片存储的图床，最后将提交一批短链接给这个连环画微博应用。这个应用将生成唯一的一个图片序列编号，对应这些短链接，以及次序。当微博被订阅的时候，可以自动的按顺序调出这些图片，然后按照顺序和统一的宽度，显示这项图片。</div>
<div>发帖程序，可以先发送文字的部分，这个时候其他用户就可以看到这条微博了，随着照片的上传，那些订阅者面前的微博，将自动的显现这些内容。也就是说文字和多幅图片的传输和显示，是异步的。并不一定要完全传输完了之后，其他用户才能看到。而是其他用户可以直接看到当前已经传输完成的部分。其他部分，可以在传输完成之后，自动的显示出来。</div>
<div>该条微博的原创者，可以在微博发出后添加或删除其中的一些图片，也可以调整顺序，如果他拥有足够的权限，直接从图床上删除了一张照片，那么所有引用这张照片的地方，都将直接被屏蔽掉。所有微博的回复和转发，都可以再附加图片。</div>
<div>这种系统，如果有大量的用户访问，每条微博都需要调用多张图片。那么对于图床系统的压力会非常大的，如果要实现此类连环画和微博结合的产品，那么在前端就必须采用一些滞后渲染类的技术。如果像传统的bbs或博客那样，直接去调用多幅图片的话，服务器可能根本就无法支撑。</div>
<div>如果我们能够拥有这样这一种系统，当用户遇到一些突发事件，或有趣事情的时候，就可以连续的拍摄多张照片。然后选择这些照片，调整顺序和色调后，按照恰当的分辨率上传到微博系统上去。图片进入图床，文字内容进入微博系统。其他用户，可能从不同的角度，也拍摄下了同一事件的其他照片，那么他就可以在回复或转发该微博的时候，将他的图片也放进来。当用户阅读此微博的时候，就可以看到转发和评论的上下文，以及相关此事件的所有图片。这样的阅读体验应该是非常棒的，而且非常方便进行图片信息的聚合，也方便搜索。</div>
<div>希望能够有人做一个类似的系统，或现有的国内微博提供商，能够提供类似的服务。如果有人准备自己做类似的系统的话，可以考虑将多幅图片进行等宽拼接，然后将缩略图转发到国内外的知名微博上，然后再用链接将那些想要了解详细信息的订阅者，吸引回自己的服务器上。</div>
<div>最近事情比较多，前面写了一篇关于开源图床的博客，写起来也很痛苦。那篇博客已经写完了，但是还有一些问题，所以并没有发上来。这里所讲到的图床系统，就是基于那篇博客中的描述的，当然，放在flickr上也是没有问题的。那篇写开源图床的博文，也许会在今后一两周里面发上来吧。当然，也有可能会在那篇博客贴上来之前，再写一些其他的东西。</div>
</div>
]]></content:encoded>
					
		
		
			</item>
		<item>
		<title>分层次的图片服务</title>
		<link>https://lukefan.com/2011/02/11/%e5%88%86%e5%b1%82%e6%ac%a1%e7%9a%84%e5%9b%be%e7%89%87%e6%9c%8d%e5%8a%a1/</link>
		
		<dc:creator><![CDATA[Luke Fan]]></dc:creator>
		<pubDate>Fri, 11 Feb 2011 11:16:00 +0000</pubDate>
				<category><![CDATA[梦想园]]></category>
		<category><![CDATA[照片]]></category>
		<guid isPermaLink="false">http://lukefan.com/?p=338</guid>

					<description><![CDATA[春节休假归来，又向flickr上上传了一大堆照片。我在flickr上的那些自己人也都在努力的上传新照片。我想， ... <a title="分层次的图片服务" class="read-more" href="https://lukefan.com/2011/02/11/%e5%88%86%e5%b1%82%e6%ac%a1%e7%9a%84%e5%9b%be%e7%89%87%e6%9c%8d%e5%8a%a1/" aria-label="阅读 分层次的图片服务">阅读更多</a>]]></description>
										<content:encoded><![CDATA[<p>春节休假归来，又向flickr上上传了一大堆照片。我在flickr上的那些自己人也都在努力的上传新照片。我想，每次重大的节日之后，flickr都需要增加一些新的存储设备吧。特别是中国的黄金周制度更是极大的增加了flickr的存储压力。</p>
<p><a title="Flickr 上 Luke Fan 的 DSC_0355" href="http://www.flickr.com/photos/lukefan/5427808937/" target="_blank" rel="noopener"><img fetchpriority="high" decoding="async" style="display: block; float: none; margin-left: auto; margin-right: auto" alt="DSC_0355" src="http://farm6.static.flickr.com/5020/5427808937_f76674c4e9_z.jpg" width="428" height="640" /></a></p>
<p>flickr本身一直存在着很多的争议，他们的盈利情况一直不是很好，但是作为一个照片站来说，能够超越他的又确实不多。就像上一篇<a href="http://lukefan.com/?p=322">《图片的故事》</a>中所说的那样，flickr这样的公司，运营压力是很大的，他们需要准备海量的存储设备和巨大的带宽，来应对图片的存储和调阅。他们在选择各种和Social相关的策略时都需要特别谨慎，因为他们所有的策略，都是建立在高昂的成本基础上的。</p>
<p>在图片行业，像flickr这样从头做到脚、融会贯通，可能并不是一个好的办法。现在，很多想要进入这个行业却又被flickr这个响当当的例子放在那里，吓得裹足不前的主要分为两种类型：有想法的小团队；有钱、有服务器、有带宽，却在策划上异常谨慎的大型企业。</p>
<p><a href="http://lukefan.com/wp-content/uploads/2011/02/11.jpg"><img decoding="async" style="border-bottom: 0px; border-left: 0px; display: block; float: none; margin-left: auto; border-top: 0px; margin-right: auto; border-right: 0px" title="11" border="0" alt="11" src="http://lukefan.com/wp-content/uploads/2011/02/11_thumb.jpg" width="433" height="290" /></a> </p>
<p>如果能够让这两类人，分别做好自己的事情。那么我们就有可能能够看到大批的图片相关应用涌现出来。</p>
<p>首先说说那些大企业。</p>
<p><a href="http://lukefan.com/wp-content/uploads/2011/02/13.jpg"><img decoding="async" style="border-bottom: 0px; border-left: 0px; display: block; float: none; margin-left: auto; border-top: 0px; margin-right: auto; border-right: 0px" title="13" border="0" alt="13" src="http://lukefan.com/wp-content/uploads/2011/02/13_thumb.jpg" width="438" height="582" /></a> </p>
<p>他们需要提供的就是存储和带宽，将其包装成商品，自己做一个简单的针对个人用户的demo，然后以API的形式开放给那些小型团队。按照各种资源具体使用的数量向小团队收费。可以考虑有一个基准的免费基线，超过一定使用量，或期限之后，才开始计费。可以将费用用广告展现或点击资源来置换。他们只要保证图片数据的安全性、可用性；对于存储在他们那里的图片数据进行简单的处理（不同精度、色彩的变形等），各种初步的数据统计和分析工具，到常用的图片分享网站的API封装（新浪、twitter、facebook、搜狐等）。然后按照账号体系让特定的人可以通过API上传图片，然后再让相应的人可以访问到相应的图片，保证全国的访问速度。最后按照实际产生的存储容量和带宽来收取费用。</p>
<p>这其实就是一种基于图片服务的云，只是没有必要像flickr和picasa那样将服务做得那么完善，主要也不是面向最终用户的，而是面向那些开发者和小团队的。</p>
<p>对于运营这样的项目来说，首先需要对成本进行精算，详细的核算存储和带宽的成本，然后划分成不同的套餐，吸引那些开发者或中小型团队将他们的应用建立在这些服务上。</p>
<p>再说说那些可以进行无尽的尝试的小团队吧。</p>
<p><a href="http://lukefan.com/wp-content/uploads/2011/02/14.jpg"><img loading="lazy" decoding="async" style="border-bottom: 0px; border-left: 0px; display: block; float: none; margin-left: auto; border-top: 0px; margin-right: auto; border-right: 0px" title="14" border="0" alt="14" src="http://lukefan.com/wp-content/uploads/2011/02/14_thumb.jpg" width="430" height="646" /></a> </p>
<p>如果不需要考虑前期的底层设施搭建，可以在用户数量还比较低的时候，尽可能的少承担相关的成本。他们要做的就是发挥无穷无尽的想象力，去充分的试错。用户数量提升之后，当广告收入已经无法抵偿存储和带宽成本的时候，也就差不多可以去写投资报告，四处去拉投资了。</p>
<p>如果能够统一一套标准，所有提供图片服务的大企业和使用这些服务的小团队都遵循。那么这个市场就有可能更快的成熟起来。</p>
<p>社会分工不断的完善，是社会生产力不断提升的标志。让我们一起来期盼不同的团队和企业，在不同的层次上共同努力，为我们提供更加经济实惠，更加丰富多彩的图片服务吧。</p>
<p><a href="http://lukefan.com/wp-content/uploads/2011/02/12.jpg"><img loading="lazy" decoding="async" style="border-bottom: 0px; border-left: 0px; display: block; float: none; margin-left: auto; border-top: 0px; margin-right: auto; border-right: 0px" title="12" border="0" alt="12" src="http://lukefan.com/wp-content/uploads/2011/02/12_thumb.jpg" width="422" height="318" /></a></p>
]]></content:encoded>
					
		
		
			</item>
		<item>
		<title>G7的照相效果一般</title>
		<link>https://lukefan.com/2010/06/15/g7%e7%9a%84%e7%85%a7%e7%9b%b8%e6%95%88%e6%9e%9c%e4%b8%80%e8%88%ac/</link>
		
		<dc:creator><![CDATA[Luke Fan]]></dc:creator>
		<pubDate>Tue, 15 Jun 2010 09:38:46 +0000</pubDate>
				<category><![CDATA[随笔]]></category>
		<category><![CDATA[照片]]></category>
		<guid isPermaLink="false">http://lukefan.com/?p=126</guid>

					<description><![CDATA[今天加班，在路上试了试新手机的照相功能。感觉很一般。 不知道是不是我没有调好？总之，照片总是灰蒙蒙的。 照片是 ... <a title="G7的照相效果一般" class="read-more" href="https://lukefan.com/2010/06/15/g7%e7%9a%84%e7%85%a7%e7%9b%b8%e6%95%88%e6%9e%9c%e4%b8%80%e8%88%ac/" aria-label="阅读 G7的照相效果一般">阅读更多</a>]]></description>
										<content:encoded><![CDATA[<p>今天加班，在路上试了试新手机的照相功能。感觉很一般。<br />
不知道是不是我没有调好？总之，照片总是灰蒙蒙的。</p>
<p>照片是张江地区的有轨电车。<br />
<a title="IMAG0004.jpg" href="http://www.flickr.com/photos/40300073@N02/4702026930/" target="_blank" rel="noopener"><br />
  <img decoding="async" src="http://static.flickr.com/4008/4702026930_c7eb8c8b99_d.jpg" border="0"/><br />
</a></p>
<p>这篇东西，是从Android手机上的WordPress插件里发上来的，不过默认的图片好像在对顶上，有些不爽啊。再拖过来调整一下。虽然照相的水平一般（可能是本人不会用），不过博客管理还是不错的。</p>
<p>照相的水平虽然不高，效果也不是很好。不过发博客的过程确实方便了很多。以后可以经常发一些照片博客上来了，往新浪发送照片微博也是蛮方便的，有了android手机，我的微博发帖数量急剧上升。</p>
]]></content:encoded>
					
		
		
			</item>
	</channel>
</rss>
