api.getPicture重大bug为何视而不见？

wengxiuhao

根据文档使用api.getPicture获取图片，并设置targetWidth进行压缩，可是压缩功能完全不正常。

1. api.getPicture({
   
2.     sourceType: 'library',
   
3.     mediaValue: 'pic',
   
4.     destinationType: 'url',
   
5.     allowEdit: false,
   
6.     quality: 80,
   
7.     <font color="#ff0000">targetWidth: 1080</font>,
   
8.     saveToPhotoAlbum: false
   
9.       }, function(ret, err) {
   
10.     if (ret) {
    
11.         callback(ret.data);
    
12.     }
    
13.       });

复制代码

原图尺寸为3968x2976，设置targetWidth为1080时，压缩后的尺寸是992x744，大小为原图的1/4；设置targetWidth为720时，压缩后的尺寸是496x372，大小为原图的1/8；
由此推测，这个压缩只能1/2, 1/4, 1/8 这样压缩？
此问题在论坛中有很多人反应了很多次了，你们技术团队为什么视而不见？
这么基础的一个功能都能做成这样，开发者如何有信心用你们的平台？

辉哥_0808

你想要怎么样的压缩？

Mr.ZhouHeng

把你建议弄全   描述好自己需要的是什么样的压缩，不然别人不懂你想实现的东西

wengxiuhao

那请问 api.getPicture 是想实现什么样的压缩？ targetWidth 这样的参数难道不是来指定 压缩后的宽度的？ 1/2 1/4 1/8这样的固定压缩比例文档里面有描述吗？正常人用起来都会觉得这个压缩功能莫名其妙吧？

按照普通人的逻辑，给定一个targetWidth，对图片进行压缩

if (原图宽度 > targetWidth) {
    压缩图片({宽: targetWidth，高: 自适应})
}

Mr.ZhouHeng

targetWidth：

类型：数字
默认值：原图宽度
描述：（可选项）压缩后的图片宽度，图片会按比例适配此宽度

wengxiuhao

Mr.ZhouHeng 发表于 2019-4-1 16:21
targetWidth：

类型：数字

原图尺寸为3968x2976，设置targetWidth为1080时，压缩后的尺寸是992x744，大小为原图的1/4；设置targetWidth为720时，压缩后的尺寸是496x372，大小为原图的1/8；这就是“图片会按比例适配此宽度”的真正含义吗？

wengxiuhao

Mr.ZhouHeng 发表于 2019-4-1 16:21
targetWidth：

类型：数字

这个问题在论坛里面搜索过，我也不是第一个觉得有问题的人。
https://community.apicloud.com/bbs/thread-31452-1-251.html
https://community.apicloud.com/bbs/thread-706-1-1619.html

https://community.apicloud.com/bbs/thread-2370-1-2832.html


这些帖子反应的都是同一个问题

wengxiuhao

我仔细看了一下 你们的官方版主“常山赵子云”对这个功能原理做了解释

在这个帖子中https://community.apicloud.com/bbs/thread-8139-1-1.html

蛋定，回复请注意用词。非常感谢您对APICloud的是支持和使用，这对我们是莫大的促进。我们也一直在不断收集开发者的建议同时增强产品和品质。

我的回复是向你说明，getPicture的一个大致压缩机制，它是一个粗略压缩，之所以参数名叫做targetWidth/targetHeight，而不是width或者height，意味着传入的宽高它仅仅是作为一个参考，而不是一个定值。底层会通过参考这个宽高对原图进行缩略，这是Android系统层面对图片处理的机制，getPicture仅仅是将该机制做了一层桥接。

基本算法：根据传入的targetWidth/targetHeight算出压缩结果允许的最大像素，然后参考这个最大像素值，得出一个缩略所需的倍率，这个一定是2的次幂数，所以压缩后的最终结果，图片的宽高几乎不会与传入的相匹配。

同时该处理机制也是通用的一个处理机制，市面上的app基本都是这么处理的。也就是说可以getPicture用于满足app的基本图片压缩需求。

如果需要更精细的压缩，可以在获取图片后使用imageFilter模块的压缩方法进行压缩。

看来他对自己设计的这个反常的压缩功能很满意啊？？？这种只能按照2的次幂数进行压缩的功能 配上 文档里这么粗略的描述， 一个第三方开发者要浪费多少时间去测试这个功能？？

我建议1. 修改此功能；2. 修改文档，告知此功能的局限性，并告知能进行准确压缩模块

Mr.ZhouHeng

wengxiuhao 发表于 2019-4-1 16:46
我仔细看了一下 你们的官方版主“常山赵子云”对这个功能原理做了解释

在这个帖子中https://community.api ...

我反馈一下