BSDS集团 您即便上传后也是这个效果 因为头像最后本身就是100×100显示
不如直接用之后的

彗星の如く現れた星の原石

アイドルvtuberほしまちすいせい☄~

すいちゃんは——今日もかわいい!

No life must forced to stop

积分: 18

BSDS集团
@n0099 对此早已有所预言:会webp压缩
图片目前大小为106Kb
所以还是得上传原文件到定向图床 亦或是压缩包还原形式
以及您的图片应该也不是最原始的图
一般来说数位板绘制的原图产出至少都是几M

彗星の如く現れた星の原石

アイドルvtuberほしまちすいせい☄~

すいちゃんは——今日もかわいい!

No life must forced to stop

积分: 18

    Wien 他只要上传到本坛了就行了
    我可以去拿到转webp之前他上传的图片文件

    Wien 以及您的图片应该也不是最原始的图
    一般来说数位板绘制的原图产出至少都是几M

    现在问题的核心是获得

    n0099 您无法上传的图片原图

    这样我才有可能复现问题,而不是获得画师的原图

    积分: 15

    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头像表面上是圆形 实际上还是方形吧 如果直接拉到近似于最大 那等于没裁
      那像素点这么多肯定不满足啊

      彗星の如く現れた星の原石

      アイドルvtuberほしまちすいせい☄~

      すいちゃんは——今日もかわいい!

      No life must forced to stop

      积分: 18

        Wien qq头像表面上是圆形 实际上还是方形吧

        大多数圆形头像都是在显示的地方做裁剪,而不是服务端实际存储的头像图片是圆形(至于圆之外的图片边界框之内的像素是纯白还是纯黑还是png的alpha通道255(全透明)是实现细节)

        Wien 那像素点这么多肯定不满足啊

        满足什么?

        • Wien 回复了此帖
        积分: 15

          Wien 您说的很对,但事实是这个由js实现的裁剪选区窗口输出的图片是高度原始的png,然后再把裁剪了的png传给flarum服务端

          而当对于这张jpg,选区拖到最外面后其产生的png大小是2409795字节
          正好超过了flarum服务端硬编码的的2048kib的文件字节限制:
          https://github.com/flarum/framework/blob/201d7430feaaace581a07b15fd1161179da441ff/framework/core/src/User/AvatarValidator.php#L100

            进一步的事实核查:

            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,这也解释了此前

            为什么能够指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

              n0099 满足小于2m字节上限

              彗星の如く現れた星の原石

              アイドルvtuberほしまちすいせい☄~

              すいちゃんは——今日もかわいい!

              No life must forced to stop

              积分: 18

              n0099 真•对症下药

              彗星の如く現れた星の原石

              アイドルvtuberほしまちすいせい☄~

              すいちゃんは——今日もかわいい!

              No life must forced to stop

              积分: 18

              n0099
              所以像素点字节数量的上限亦是2 048 000 字节
              一张图片256彩色 会出现的情况
              原色纯白重复像素点上传这种倒是不存在这种问题

              彗星の如く現れた星の原石

              アイドルvtuberほしまちすいせい☄~

              すいちゃんは——今日もかわいい!

              No life must forced to stop

              积分: 18

                n0099 所以是少了一个压缩流程(裁剪后仍大于2m字节的图像进行压缩) 最终压缩只包含小于2m字节的图像然后产出为100×100图像

                彗星の如く現れた星の原石

                アイドルvtuberほしまちすいせい☄~

                すいちゃんは——今日もかわいい!

                No life must forced to stop

                积分: 18

                  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 位是比这更大的最小可寻址单元,因此使用它可以处理原始数据。

                    • Wien 回复了此帖
                    积分: 15

                      n0099

                      1个图片文件有多少字节跟他有多少像素点(也就是分辨率的长乘宽)毫无关系

                      以位图举例 32•32的图
                      用GLubytebitmapname[128]存储
                      128bytes = 128*8bits = 32 * 32 bit

                      不是位图 是彩图
                      GLubytebitmapname[1024]存储
                      设定128个字节来存储位图数据 1024bytes = 32 * 32 bytes

                      还真是32•32

                      彗星の如く現れた星の原石

                      アイドルvtuberほしまちすいせい☄~

                      すいちゃんは——今日もかわいい!

                      No life must forced to stop

                      积分: 18

                        n0099 所以这也是超高清图片8K影视文集体积显著增大的原因:
                        相同尺寸不变 但每个像素点携带的内容更多了

                        彗星の如く現れた星の原石

                        アイドルvtuberほしまちすいせい☄~

                        すいちゃんは——今日もかわいい!

                        No life must forced to stop

                        积分: 18

                          Wien GLubytebitmapname

                          您在复制粘贴什么?

                          既然您知道这是opengl环境下的,那也就能意识到在计算机图形学语境中可以直接这样划等号,因为他们懒得利用png jpg webp avif等落后或先进的算法去压缩显存中的那些像素(也没必要),而是直接把他们从显存塞进渲染管线和流处理器中
                          事实是偷懒的游戏开发者甚至连硬盘上的游戏资源文件中的原始素材图片文件都懒得压缩直接bmp tiff了

                          • Wien 回复了此帖
                          积分: 15