zimg
zimg copied to clipboard
buaazp
zimg TODO list
zimg在设计开发阶段需求基本是我一个毫无实战经验的人凭空想出来的，用起来肯定各种不顺手，所以开一个issue，如果你期望在使用zimg的任何环节增加功能，请在此处回复，我将酌情加入。
沙发自己坐了。
@欧飞程勇 提了两个需求： 1.空请求返回一个欢迎界面。（Done） 2.upload成功后返回xml或json风格的结果，而不是http格式。（Done）
1.zimg 支持lua脚本，配置和压图处理（Done） 2.支持ssdb存储，具备在线备份能力（Done） 3.上传逻辑优化（Done） 4.服务器系统信息通过lua文件获取，在HTTP包头中返回（Done）
@viky 提出的需求：
- 访问权限控制。（Done）
- 不含参数的请求返回被压缩过的图片节省流量，原始图片使用p=0参数来获取。（Done）
- 删除图片功能。（Done）
@Smallthing 理论上说如果两张图片算出来的md5相同，后上传的会覆盖掉先上传的图片。 但是两张图片md5相同的概率太小了（1 / 2^64），普遍认为md5碰撞是不可能发生的，所以大可不必担心。 最后，增加文件名的困难在于需要增加一个存储文件名到图片数据的映射关系，这会大大降低查询速度，所以不会加入。图片原始大小可以通过拉原始图片获取。
@buaazp 1.求编译打包后的文件比如rpm,deb文件，直接安装，因为我编译了好多次都没成功 2.提供更加现代的安装测试方式，比如 将zimg安装到docker中，这样就会有更多的人尝试使用
@adouggy 把你的图片上传到 http://demo.buaa.us/ 看一下还有没有这种问题，如果有的话麻烦把这张图片的MD5留言给我。
如果没问题的话，就等等新版本发布即可，新版本使用了新的图片处理引擎。
@buaazp 好的，谢谢。比如这张图：ef9a6b4fcb21839e8ed92a7348471ff0，如果不加p=0就变成一张同样的颜色了。 但是有些png背景就变成了白色。但有些背景会变成黑色。
@buaazp 先前有人提出过：Can zimg bind on a IP? 我觉得这个也有必要，比如能够绑定内网或者环回地址，这样只能够从nginx反向代理过去，对外不开端口会增加安全性。比如mysql的bind-address，或者tomcat、redis之类都有类似的功能。
@adouggy
你说的都可以在3.0版本里解决：
png图片问题：这个貌似是png转jpeg的时候无法避免的问题，所以可以设置默认输出图片格式为原始格式，这样就只会返回png bind IP功能：有
@buaazp 太好了，3.0的milestone什么时候？ 另外有没有专门讲解配置的文档？我可以系统的学习一下如何使用。 png转jpeg丢失掉透明度没有办法，如果zimg3.0能够提供指定透明部分颜色的选项就太好了。因为使用原图对于网络、客户端都开销太大了。
谢谢作者耐心细致的解答
@buaazp 还要打扰，传递图片会去除exif，这样图片的旋转信息就会丢失。 p=0可以获取原图和原始信息。 有没有可能让压缩过的图片也保留部分exif信息？因为旋转等某些参数在应用环境下还是很有用的。 多谢 :)
Hi all, zimg v3 has been released. All these requirements below have done.
- @zz : Can zimg bind on a IP? (Done)
- @momoplan : 支持更多的img处理模式，比如可以缩放时不是补边而是裁边的方式。(Done)
- @zz : 是不是应该有 remote image cache 等功能？(Done)
- @qiutiaoming : 求编译打包后的文件比如rpm,deb文件 (Done)
- @adouggy : 有没有可能让压缩过的图片也保留部分exif信息？(Done)
Furthermore, zimg v3 has many other wonderful features in image processing. Goto zimg.buaa.us for more information.
Would like to have user verification for authorized end users only by value verification, cookie, sending to another existing central server, if match, return true and allow upload, once successfully uploaded, return send the value of
1,5f189d8ec57f5a5a0d3dcba47fa797e2,29615
boolean (1 or 0, success or failure), filename, size
saving bandwidth on trip to server.
Configuration of file
central_server = zimg.domainname.com
I can contribute by writing the connecting api (on the central server) for verification of cookie in php if you can produce the above connector to the api.
I have read the source code. You write very nicely. Rather elegantly.
I have no idea how to read cookies with your program. If you can code a module on this part I can help you code php or perl API connector. Appreciate it.
I have one question to ask, the ssdb connector... can it be easily written to use hashset instead of SET as inside the c source code? just not sure how to use hset instead of the below.
Can i change this line to redisReply r = (redisReply)redisCommand(c, "SET %s %b", cache_key, buff, len);
redisReply r = (redisReply)redisCommand(c, "HSET %s %s %b", cache_key1, cache_key2, buff, len); ??? Can you provide the two modifications for hset and hget for this zimg?
That's all I need to know. Thanks a lot!
int save_img_ssdb(redisContext* c, const char *cache_key, const char *buff, const size_t len) { if(c == NULL) return -1;
redisReply *r = (redisReply*)redisCommand(c, "SET %s %b", cache_key, buff, len);
if( NULL == r)
{
LOG_PRINT(LOG_DEBUG, "Execut ssdb command failure");
return -1;
}
if( !(r->type == REDIS_REPLY_STATUS && strcasecmp(r->str,"OK")==0))
{
LOG_PRINT(LOG_DEBUG, "Failed to execute save [%s] to ssdb.", cache_key);
freeReplyObject(r);
return -1;
}
freeReplyObject(r);
LOG_PRINT(LOG_DEBUG, "Succeed to save [%s] to ssdb. length = [%d].", cache_key, len);
return 1;
}
oh two more things...
- image reduction (resize smaller) on browser side before sending
- maximum file size in (kb) or dimension of file send resize on server side.
That's all
An interesting feature would be to monitor average RTT between the client and server; create a lower resolution version of any new requests, and cache them for later!
@buaazp interestingly enough; I'm refactoring a bit on zimg right now. It's something to do, and hopefully be a good sport about testing new libevent & evhtp features.
@ellzey And I did some modifications in evhtp:
I use this pthread_key in zscale.c. I think I should tell you this.
Not quite sure this is the right place for these things to go. But that can be figured out.
I would check out the current develop branch here: https://github.com/ellzey/libevhtp/tree/develop the evthr stuff has been super simplified and lots of people have been contributing cool stuff.
Only problem is, I'm trying to work on https://github.com/ellzey/libevhtp/tree/libevhtp2 and all of these additions and fixes are a pain to keep in sync with a completely different architecture that evhtp2 is.
大部分需求场景，例如： 原图尺寸：900x600 容器大小：300x300 需要展示全图，并进行按容器缩放。 Example 1: Get the image with width=300, and equal proportion. 1.1、处理后：300x200 [ok] 但是如果原图尺寸：600x900 1.2、处理后：300x450 [error] Example 2: Get the image in 300_300 and the redundant part will discard. 处理后：300x300，但是图片被裁剪 [error] Example 3: Get the center part of image in certain resolution 处理后： 图片被裁剪 [error] Example 4: Get the resized image with percent 处理后： 图片被裁剪 [error] Example 5: Get 300_300 image but the image will be stretched 处理后： 图片显示全图，但是被拉伸 [error] Example 6: Get the certain part of the image 处理后： 图片被裁剪 [error]
而想要的是
需要判断图片的宽和高，以最大宽度或高度为最大值，进行等比缩放图片（不裁剪）
请求参数：max_width=300，max_height=300
请求url：http://demo.buaa.us/5f189d8ec57f5a5a0d3dcba47fa797e2?w=300&h=300&p=xxx
若图片尺寸：900 x 600，缩放后：300 x 200
若图片尺寸： 600 x 900，缩放后：200 x 300
望优先采纳，BTW，zimg很强大，期待越来越好(^__^)
@fanrong33
Now zimg supported max_size(via using p=4) method to meet your requirements.
Just pull the newest codes and rebuild them to test.
Hi there, I am writing a django storage for zimg, and to achieve a complete implementation, we need to be able to extract below information from a zimg hosted file:
- created_time, the datetime when the image is uploaded to a zimg host
- accessed_time, the datetime when the zimg hosted image is accessed (this could be trivial and not very necessary, entirely up to you and of course the zimg philosophy)
Please do consider this request
Actually, I do suggest to have standard resource philosphy based restful API in place for zimg.
All the image operations should be only available at below endpoints:
http://zimg.host/images/, HTTP method POST <-> Upload http://zimg.host/images/, HTTP method GET <-> List hosted images (perhaps pagination is needed here) http://zimg.host/images/, HTTP method HEAD <-> Return statistical information like total file counts, total file size, etc. http://zimg.host/images/, HTTP method OPTIONS <-> Return a json to tell the client what the allowed verbs are (GET, POST, HEAD)
http://zimg.host/images/[md5], HTTP method GET <-> Download http://zimg.host/images/[md5], HTTP method DELETE <-> Delete http://zimg.host/images/[md5], HTTP method HEAD <-> Retrieve information http://zimg.host/images/[md5], HTTP method OPTIONS <-> Return a json to tell the client what the allowed verbs are (GET, HEAD, DELETE)
And, for all above operations, make sure the appropriate HTTP status code is returned with the response. (404 for resource not found, 401 for admin operation denied due to insufficient permission, ...)
@walnutist +1
200 is not the best status code for "File type is not supported! Upload Failed!"
Should I open a separate issue?
@niko
A full RESTful api will come with v4.0, so you needn't to open a new issue.
nothing, I just saw a paper saying that On Mon, Oct 19, 2015 at 8:52 PM 招牌疯子 [email protected] wrote:
@ellzey https://github.com/ellzey Bad news! 😱what's happening?
— Reply to this email directly or view it on GitHub https://github.com/buaazp/zimg/issues/5#issuecomment-149424487.
权限控制可以用的，但是如何配置多个ip呢 upload_rule = 'allow 192.168.59.*/24' 这样配置不生效 upload_rule = 'allow 192.168.59.11/24 192.168.59.12/24 ' 这样也不行
还请大神给提示下
