急，为什么我的头像上传不了

Wien 图片目前大小为106Kb

事实核查：他上传的原图也只有

$ file 1667113773-811898-1666748230997.jpg
1667113773-811898-1666748230997.jpg: JPEG image data, JFIF standard 1.01, resolution (DPI), density 96x96, segment length 16, comment: "CREATOR: gd-jpeg v1.0 (using IJG JPEG v80), quality = 90", baseline, precision 8, 1696x1718, components 3

n0099 事实是这样
上传如果是直接最大裁剪 那自然不行

然后变小一点就行了
所以还是原图像素点数量的问题，超过了函数的上限

以及这只是 个人对于裁剪的问题 想要保留完整性 所以刻意将圆形裁剪显示拉到最大
QQ tieba 微信当然随便这么玩 因为服务器自动压缩为纵横的一两百原比例像素
就像qq头像表面上是圆形 实际上还是方形吧 如果直接拉到近似于最大 那等于没裁
那像素点这么多肯定不满足啊

进一步的事实核查：

n0099 由js实现的裁剪选区窗口

具体是指的扩展 https://github.com/FriendsOfFlarum/profile-image-crop

追溯上传网络请求的callstack我们可以找到

在这里可以看见上传网络请求的multipart/form-data的第一个文件的二进制内容来自blob变量，而blob变量又来自L90的canvas.toBlob()的返回值，根据其文档 https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasElement/toBlob 可知由于这里没有额外参数指定使用jpg或webp压缩并提供压缩quality值导致其会直接返回没有压缩的png，这也解释了此前

n0099

为什么能够指png为jpg

事实是这问题在扩展用户之中早有预言：
https://discuss.flarum.org/d/18286/28
https://github.com/FriendsOfFlarum/profile-image-crop/issues/15
并早已有人修复了这个问题并在3个月前其pr被merge
https://github.com/FriendsOfFlarum/profile-image-crop/pull/17
但不幸地

由浏览器扩展 https://github.com/refined-github/refined-github 向我提醒的

The merge commit doesn’t appear in any tags

意味着截止2022年11月，这个pr所造成的更改仍未反映在任何github tags及对应的packagist包版本之中
目前这个扩展的最新版本是去年11月发布的1.0.1，其对应的github tags和commit是 https://github.com/FriendsOfFlarum/profile-image-crop/commits/master#:~:text=Remove%20Bazaar%20reference

对于此问题我已致电该扩展repo的有关人士催促其进行一个包流程的发布： https://github.com/FriendsOfFlarum/profile-image-crop/pull/17#issuecomment-1296220944

Wien 所以像素点字节数量的上限亦是2 048 000 字节

1个图片文件有多少字节跟他有多少像素点（也就是分辨率的长乘宽）毫无关系
irol此前于zulip对此早有预言：建议一张1G大的图片只表达了一个像素

Wien 一张图片256彩色

什么经典gif的限制一张gif中的调色板只能有256色（也就是8bit color depth）带来的刻板印象； https://en.wikipedia.org/wiki/Palette_(computing)
令人想起了截止2022年都还在给gif图片采用像素抖动模拟比8bit更多的色彩像素（同时在显示器领域也有8bit抖10bit，那个10bit本质上是30bit color depth https://en.wikipedia.org/wiki/Color_depth#Deep_color_(30-bit)）
https://en.wikipedia.org/wiki/Dither#Digital_photography_and_image_processing
比gif新的那些图片格式都早已提升至24bit color depth： https://en.wikipedia.org/wiki/Color_depth

Wien 原色纯白重复像素点上传

因为即便是无损的png他本身也有deflate压缩（zip格式也是defalte算法） https://en.wikipedia.org/wiki/Portable_Network_Graphics#Compression
所以如果一张png是纯色那即便他的分辨率很大最终的png文件也没有以bmp表达的纯色大（假设您的这张bmp没有optin任何压缩 https://en.wikipedia.org/wiki/BMP_file_format#Compression）

Wien 少了一个压缩流程（裁剪后仍大于2m字节的图像进行压缩）

所以那个pr https://github.com/FriendsOfFlarum/profile-image-crop/pull/17 的做法就是直接在裁剪选区图片后再把裁剪结果压到500x500px分辨率，这样可以降低触发后端的2048kib限制的概率

Wien 最终压缩只包含小于2m字节的图像然后产出为100×100图像

您说的这个最终压缩发生于flarum服务端对经由头像上传网络请求携带的图片文件进行处理

n0099 比gif新的那些图片格式都早已提升至24bit color depth：

更多的事实核查：
根据 www.reddit.com/r/photography/comments/5rk4gi/are_there_any_10bit_image_formats_and_if_not_will 中 u/SickSalamander的说法

以PNG本身为例
https://en.wikipedia.org/wiki/Portable_Network_Graphics#Critical_chunks 指出

bit depth (1 byte, values 1, 2, 4, 8, or 16)

https://en.wikipedia.org/wiki/Portable_Network_Graphics#File_size_factors 指出

Color depth can range from 1 to 64 bits per pixel.

bpp的定义见 https://www.intopix.com/blogs/post/How-to-define-the-compression-rate-according-to-bpp-or-bps#BPP
而众所周知png比起jpg允许存在alpha通道实现透明度（就像更老的gif那样，但gif只有8bit）
使用数字论证64/4=16，可得用于rgb通道的bpp是48bit

https://en.wikipedia.org/wiki/Color_depth#48-bit 对此早有总结：

每个颜色通道使用 16 位会产生 48 位，281,474,976,710,656 种颜色。如果添加相同大小的 Alpha 通道，则每个像素有 64 位。
Adobe Photoshop等图像编辑软件很早就开始使用每通道 16 位，以减少对中间结果的量化（即，如果一个运算除以 4，然后再乘以 4，它将丢失 8 位的底部 2 位）数据，但如果使用 16 位，则不会丢失任何 8 位数据）。此外，数码相机能够在其原始数据中每通道产生 10 或 12 位；由于 16 位是比这更大的最小可寻址单元，因此使用它可以处理原始数据。