Comments (4)
Because the pixel swizzler (converting from one pixel format to another) only supports a limited number of destination formats.
wuffs/internal/cgen/base/pixconv-submodule-regular.c
Lines 5153 to 5225 in 49f50cc
is the relevant code. Note that the switch statement looks at the source pixel format and you have to drill into the functions (e.g.
wuffs/internal/cgen/base/pixconv-submodule-regular.c
Lines 4694 to 4771 in 49f50cc
For N
pixel formats, there are N*N
different (source, destination) combinations. It would be a lot of code (not just to write, but there's also a binary-size cost) to support all of the combinations. Instead, we support a smaller subset: supported source pixel formats are based on what's 'natural' for the image file formats (JPEG, PNG, etc) and supported destination pixel formats are based on what's commonly used.
Is there a particular destination format that you'd like added, or are you just curious?
from wuffs.
Thank you very much for such a detailed response! I was initially interested in WUFFS_BASE__PIXEL_FORMAT__RGB
destination pixel format, which appeared to be working fine for each input image from my PNG dataset, so I was curious why the auxiliary API doesn't cover this format too despite it's being quite 'natural' (for historical reasons) when it comes to computer vision models, especially neural networks. But now I see that WUFFS_BASE__PIXEL_FORMAT__RGB
has somewhat limited support (lots of TODOs across the swizzler dispatching code), so it's actually might be safer to disable it at a higher level. However, it seems to me like for wuffs_aux::DecodeImage code it might make sense to just pass through the destination pixel format parameter and let the actual decoder itself fail later while selecting a pixel swizzler. Or am I getting this wrong?
Anyway, thanks again and I'm closing the issue since the initial question was answered.
from wuffs.
I was initially interested in
WUFFS_BASE__PIXEL_FORMAT__RGB
destination pixel format, which appeared to be working fine for each input image from my PNG dataset, so I was curious why the auxiliary API doesn't cover this format too
WUFFS_BASE__PIXEL_FORMAT__RGB
works for most opaque (no alpha channel) PNG images because that's "the image file's natural pixel format" from
wuffs/internal/cgen/auxiliary/image.hh
Lines 129 to 131 in 4dfd709
In terms of the bytes in the file format, PNG uses RGB or RGBA byte order (and big-endian encoding) even when e.g. Windows/x86 typically uses BGR or BGRA and little-endian.
As of a few days ago, decoding WUFFS_BASE__PIXEL_FORMAT__RGB
didn't work for all PNGs, because of the "lots of TODOs across the swizzler dispatching code" that you noticed. Those TODOs were fixed since then, by 8954281
It wasn't zero new code, but it was a relatively small amount of new code, since we already supported WUFFS_BASE__PIXEL_FORMAT__BGR
and WUFFS_BASE__PIXEL_FORMAT__RGBA_{NONPREMUL,PREMUL}
.
despite it's being quite 'natural' (for historical reasons) when it comes to computer vision models, especially neural networks
You probably know more about image decoding in neural networks (e.g OpenCV) than I do. Do you know if they would work with a BGR pixel format or do they only speak RGB?
it seems to me like for wuffs_aux::DecodeImage code it might make sense to just pass through the destination pixel format parameter and let the actual decoder itself fail later while selecting a pixel swizzler. Or am I getting this wrong?
That might make a (small) difference, in theory, but in practice, the decoders just delegate to the pixel swizzler code and it seemed better to fail earlier. It might be worth revisiting that in the future, though. Thanks for the feedback.
from wuffs.
Thank you very much for the explanation and for efforts for adding RGB support!
You probably know more about image decoding in neural networks (e.g OpenCV) than I do. Do you know if they would work with a BGR pixel format or do they only speak RGB?
Generally speaking, it depends. Some of the solutions work with RGB and some work with BGR. I'd say they both are equally popular as there is no common convention for channel ordering, so support for both formats is very useful.
That might make a (small) difference, in theory, but in practice, the decoders just delegate to the pixel swizzler code and it seemed better to fail earlier. It might be worth revisiting that in the future, though. Thanks for the feedback.
That makes sense, thank you for explaining this!
from wuffs.
Related Issues (20)
- bang insert directives depend on linux line endings
- "truncated input" API change seems like a mess HOT 3
- print-image-metadata script can go into an infinite loop
- Slow f64 parsing HOT 13
- RGB/BGR 16 bit treated like RGBA/BGRA? HOT 1
- OSS-Fuzz issue 59018 HOT 1
- [JPEG] unsupported DQT after SOF markers HOT 1
- OSS-Fuzz issue 59182 HOT 1
- OSS-Fuzz issue 59540 HOT 1
- OSS-Fuzz issue 59966 HOT 1
- What is the status of version 0.3? HOT 3
- Empty slice manipulation triggers UBSAN by offsetting from a null pointer. HOT 2
- error: conversion to ‘uint32_t’ {aka ‘unsigned int’} from ‘int’ may change the sign of the result HOT 3
- Audio and video codecs HOT 6
- convert wuffs asserts into back-end asserts HOT 2
- Security Policy violation Binary Artifacts
- OSS-Fuzz issue 47846 HOT 1
- lib/readerat: delayed invalid seek offset detected? HOT 1
- example/zcat loops forever on short input files HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from wuffs.