首页 文章 精选 留言 我的

精选列表

搜索[图像分割],共10000篇文章
优秀的个人博客,低调大师

关于安卓图像显示比iOS差的原因(英文文档)

There are so many comparations between Android phone and iPhone. We cannot make the conclusion about which one is better, but we all knows that the image quality of Android phone is much worse than iPhone. No matter you are using Facebook, Twitter or even Instagram, after taking the photo, adding a filter, then sharing to the social network, the images produced by Android phone are always coarse. Why? Our team had been working on this issue in the last year. After very deep research, we found that this was a "TINY" mistake made by Google. Although tiny, but the influence was very huge (all Android Apps related to image), and lasted till today. The problem is : libjpeg. We all know that libjpeg is widely used open source JPEG library. Android also uses libjpeg to compress images. After digging into the source code of Android, we can find that instead of using libjpeg directly, Android is based on an open source image engine called Skia. The Skia is a wonderful engine maintained by Google himself, all image functions are implemented in it, and it is widely used by Google and other companies' products (e.g.: Chrome, Firefox, Android......). The Skia has a good encapsulation of libjpeg, you can easily develop image utilites base on this engine. When using libjpeg to compress images, optimize_coding is a very important parameter. In libjpeg.doc, we can find following introductions about this parameter: boolean optimize_coding TRUE causes the compressor to compute optimal Huffman coding tables for the image. This requires an extra pass over the data and therefore costs a good deal of space and time. The default is FALSE, which tells the compressor to use the supplied or default Huffman tables. In most cases optimal tables save only a few percent of file size compared to the default tables. Note that when this is TRUE, you need not supply Huffman tables at all, and any you do supply will be overwritten. As the libjpeg.doc, we now know that because setting the optimize_coding to TRUE may cost a good deal of space and time, the default in libjpeg is FALSE. Everything seems fine about the doc, and libjpeg is very stable. But many people ignored that this document was writen for more than 10 years. At that time, space and computing abilities are very limited. With today's modern computers or even mobile phones, this is not an issue. On the contrary, we should pay more attention to the image quality (retina screens) and image size (cloud services). Google's engineers of skia project did not set this parameter, so the optimize_coding in Skia was remained to FALSE as the default value, and Skia concealed this setting, you could not change the setting outside of Skia. This became to a big problem, we had to endure worse image and bigger file size. Our team had tested optimize_coding for many different images. If you want the same quality of image compressing, the file size are 5-10 times bigger when setting the optimze_coding to FALSE than to TRUE. The difference is quite significant. We also compared the jpeg compressing between iOS and Android (they both concealed the optimize_coding parameter). With the same original images, if you want same quality level, you need 5-10 times file size on Android. The result is clear, Apple does know the importance of optimize_coding and Huffman tables and Google does not. (Apple uses their own Huffman table algorithm, not like libjpeg or libjpeg-turbo. It seems that Apple has done more tuning works on image compressing.) Finally, we decided not to use JPEG compress functions provided by Android, and we compiled our own native library based on libjpeg-turbo (libjpeg-turbo also has performance improvements). Now we can save 5-10 times of image space and enjoy the same or even better image quality. This work is totally worth to do. Thanks for reading, :) Our project on github: https://github.com/bither

优秀的个人博客,低调大师

小红书图像编辑 FireRed-Image-Edit v1.1 开源发布

在距离 1.0 版本发布不到一个月的时间,小红书 Super Intelligence 团队宣布推出了 FireRed-Image-Edit-1.1,模型在处理 ID 一致性编辑 、多元素融合 、人像美妆 、字体风格参考等方面进行了升级。目前,该项目代码、技术报告、模型参数、训练蒸馏推理框架均已开源。 1.1 版本升级点 优秀的编辑性能 前沿的 ID 一致性:开源领域最优的角色身份保持技术,确保人物主体在经历复杂编辑后依然可识别。 多元素融合:自由组合 10 余种元素,配备 Agent 智能自动裁剪与拼接功能——告别短提示词的困扰。 全面的人像美妆:涵盖数十种风格,从专业级美颜精修、黄皮/橄榄皮提亮,到万圣节女巫妆等各类创意妆容。 字体风格参考:保持高保真排版与风格化文字渲染,效果媲美闭源解决方案。 专业级照片修复:高质量老照片修复与增强,具备卓越的细节还原能力。 极致的工程优化 开放的 LoRA 训练生态:开源完整训练代码,支持自定义风格创作;优化采样器在面对相同任务、尺寸和输入数量时最大化 GPU 效率。 极限速度优化:全套加速方案,集成模型蒸馏、量化与静态编译技术——仅需 30GB 显存即可实现 4.5 秒端到端生成。 智能 Agent 工作流:自动多图处理流程,轻松应对虚拟试穿等复杂构图场景,无需繁琐的提示词工程。 全平台部署支持:原生 ComfyUI 节点支持与 GGUF 轻量级格式兼容,实现无缝生产环境集成。 高效的训练方式:提前离线抽取特征,仅调用 VLM 的生成结果(与训练完全隔离),大幅提升模型训练速度。 T2I骨干网络原生的编辑能力 骨干无关的架构设计:基于 Qwen-Image 的文生图模型通过完整的预训练→SFT→RL 流程注入编辑能力,可迁移至任意文生图(T2I)基础模型(Qwen-VL仅调用)。 FireRed 是小红书 Super Intelligence 团队的模型系列名,包括FireRed-ASR、FireRed-TTS、FireRed-Chat、FireRed-OCR、FireRed-Image、FireRed-OpenStoryline等。该团队包括Audio Lab、Vison Lab、Foundation Lab 等基础技术实验室。

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长,特征是大鼻子、头戴帽子、身穿背带裤,还留着胡子。与他的双胞胎兄弟路易基一起,长年担任任天堂的招牌角色。

Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Rocky Linux

Rocky Linux

Rocky Linux(中文名:洛基)是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版,作为CentOS稳定版停止维护后与RHEL(Red Hat Enterprise Linux)完全兼容的开源替代方案,由社区拥有并管理,支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性,采用模块化包装和SELinux安全架构,默认包含GNOME桌面环境及XFS文件系统,支持十年生命周期更新。

Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能,例如代码缩略图,Python的插件,代码段等。还可自定义键绑定,菜单和工具栏。Sublime Text 的主要功能包括:拼写检查,书签,完整的 Python API , Goto 功能,即时项目切换,多选择,多窗口等等。Sublime Text 是一个跨平台的编辑器,同时支持Windows、Linux、Mac OS X等操作系统。

用户登录
用户注册