n0099 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 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 n0099 1个图片文件有多少字节跟他有多少像素点（也就是分辨率的长乘宽）毫无关系 以位图举例 32•32的图 用GLubytebitmapname[128]存储 128bytes = 128*8bits = 32 * 32 bit 不是位图 是彩图 GLubytebitmapname[1024]存储 设定128个字节来存储位图数据 1024bytes = 32 * 32 bytes 还真是32•32
n0099 Wien GLubytebitmapname 您在复制粘贴什么？ 既然您知道这是opengl环境下的，那也就能意识到在计算机图形学语境中可以直接这样划等号，因为他们懒得利用png jpg webp avif等落后或先进的算法去压缩显存中的那些像素（也没必要），而是直接把他们从显存塞进渲染管线和流处理器中 事实是偷懒的游戏开发者甚至连硬盘上的游戏资源文件中的原始素材图片文件都懒得压缩直接bmp tiff了
n0099 Wien 相同尺寸不变 但每个像素点携带的内容更多了 您指的应该是hdr视频和图片，然而现在大多数hdr都是10bit（30bit bpp）的，因为现在的显示器也才做到8bit抖动10bit或者原生10bit的color depth显示能力 从理论上讲30bit bpp最多比24bit bpp大25%，这还不考虑任何先进有损压缩视频编码算法带来的减损
n0099 Wien 增长水平纵向像素数量来达到分辨率提升 这是句重言，因为分辨率的定义就是长x宽，而像素数量就是长*宽的数值结果 说白了分辨率定义了图片矩形的边，而像素数量是矩形的面积 Wien 像素点里多带点 多带丶色彩？那就是更高的color depth，也就是商家们宣传的hdr（目前还只是提高到10bit每通道 30bitbpp）
n0099 Wien 4096x2160这个长宽比256:135（而不是图中的17:9）的DCI标准的分辨率很少用，因为几乎所有4k显示器都是3840x2160，而其长宽比维持了传统的16:9 https://en.wikipedia.org/wiki/4K_resolution#4096_%C3%97_2160 建议回顾经典老图之 https://en.wikipedia.org/wiki/List_of_common_resolutions#/media/File:Vector_Video_Standards.svg
n0099 n0099 10bit每通道 30bitbpp 建议来看8bit每通道 24bit bpp色图 https://commons.wikimedia.org/wiki/File:16777216colors.png
Wien n0099 为了追求分辨率提升 将外在机体变长变宽 电视电脑手机显示屏越来越大... 7寸手机放在十几年前 可真是天方夜谭啊 随之而来的是电量加剧消耗 （能这么玩也 给人一种电力过剩的感觉 然而电池储电技术的上升 减少了充电和存电时的损耗 充起电来远比当初省电省时间）
n0099 Wien 有13900k的250w和4090的450w耗电？ https://www.intel.com/content/www/us/en/products/sku/230496/intel-core-i913900k-processor-36m-cache-up-to-5-80-ghz/specifications.html https://www.tomshardware.com/news/1200w-power-requirement-rtx-4090
n0099 BSDS集团 我的评价是：我专门为阁下临时禁用了此扩展 n0099 n0099 由js实现的裁剪选区窗口 具体是指的扩展 https://github.com/FriendsOfFlarum/profile-image-crop 等您设完头像我再启用
