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

image: ARGB proposal #12966

Closed
stephenwithav opened this issue Oct 17, 2015 · 8 comments
Closed

image: ARGB proposal #12966

stephenwithav opened this issue Oct 17, 2015 · 8 comments
Milestone

Comments

@stephenwithav
Copy link

@stephenwithav stephenwithav commented Oct 17, 2015

Would a patch adding ARGB support to Go's image/* packages be considered?

(cairo requires ARGB pixel ordering to support alpha transparency--that's the impetus for the request.)

@bradfitz bradfitz changed the title image.ARGB proposal image: ARGB proposal Oct 17, 2015
@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Oct 17, 2015

/cc @nigeltao

Loading

@adg
Copy link
Contributor

@adg adg commented Oct 21, 2015

Note that @nigeltao is not working at the moment so you may wait a while for a response. He's definitely the person to respond to this, though.

Loading

@stephenwithav
Copy link
Author

@stephenwithav stephenwithav commented Oct 21, 2015

Thank you for the heads up, @adg. I hope he's okay.

Loading

@adg
Copy link
Contributor

@adg adg commented Oct 21, 2015

@stephenwithav he's fine. :-)

Loading

@rsc
Copy link
Contributor

@rsc rsc commented Oct 23, 2015

I think it's a mistake to add every possible pixel layout to package image. Leaving for @nigeltao.

Loading

@rsc rsc added this to the Go1.6 milestone Oct 23, 2015
@nigeltao
Copy link
Contributor

@nigeltao nigeltao commented Oct 25, 2015

Yeah, we added an image.RGB type (without the 'A') in the 1.3 or 1.4 cycle, and rolled it back because it complicated the other image/* libraries too much. Similarly, I don't think we want an image.BGRA type.

In hindsight, it might have been more efficient for interop with other C libraries if the standard type was image.BGRA instead of image.RGBA. On the other hand, the PNG order is RGBA. In any case, that horse has bolted.

For an alternative approach to dealing with BGRA interop (e.g. X11, and presumably cairo uses the same byte order), grep for "swizzle" under golang.org/x/exp/shiny/driver.

Loading

@nigeltao nigeltao closed this Oct 25, 2015
@stephenwithav
Copy link
Author

@stephenwithav stephenwithav commented Oct 25, 2015

Thank you for the explanation, @nigeltao. And for pointing out swizzle--I hadn't realized that Go supported assembly via cgo.

cairo doesn't support BGRA, unfortunately; fortunately, adding ARGB support via an external package wasn't too difficult.

I'll polish that code and push it in the next week or two, then add a link here in case anyone needs it in the future.

Loading

@nigeltao
Copy link
Contributor

@nigeltao nigeltao commented Oct 26, 2015

Assembly isn't cgo. It's assembly. :-)

As for cairo, CAIRO_FORMAT_ARGB32 (for little-endian CPUs) is what Go (and Go's swizzle) calls BGRA. The cairo naming convention is most significant bytes to least significant bytes, and is endian-ness dependent. The Go naming convention is in memory order, and is endian-ness independent. For little-endian CPUs, cairo's least significant byte (blue) comes first, so they're the same, and the world seems to have settled on little-endian, for better or worse.

Loading

@golang golang locked and limited conversation to collaborators Oct 26, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants