Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RGB/BGR 16 bit treated like RGBA/BGRA? #115

Open
pmsoftware78 opened this issue Apr 26, 2023 · 1 comment
Open

RGB/BGR 16 bit treated like RGBA/BGRA? #115

pmsoftware78 opened this issue Apr 26, 2023 · 1 comment

Comments

@pmsoftware78
Copy link

why PNG color_type == 2 (so RGB triple) in the file

https://github.com/google/wuffs/blob/main/std/png/decode_png.wuffs

} else if this.depth == 16 {
this.dst_pixfmt = base.PIXEL_FORMAT__BGRA_NONPREMUL_4X16LE
this.src_pixfmt = base.PIXEL_FORMAT__BGRA_NONPREMUL_4X16LE
this.filter_distance = 6
choose filter_and_swizzle = [filter_and_swizzle_tricky]
}

is treated like BGRA_NONPREMUL_4X16LE plus swizzle instead of a PIXEL_FORMAT__BGR_16LE?

Best
Paolo

@nigeltao
Copy link
Collaborator

Because functions like wuffs_base__pixel_buffer__set_color_u32_at support WUFFS_BASE__PIXEL_FORMAT__BGRA_NONPREMUL_4X16LE (see link below) but do not support WUFFS_BASE__PIXEL_FORMAT__BGR_16LE. The latter is rare enough that optimizing for it is not a priority. Supporting N different pixel formats means that the pixel swizzler code (converting from one pixel format to another) needs roughly N*N different code paths.

case WUFFS_BASE__PIXEL_FORMAT__BGRA_NONPREMUL_4X16LE:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants