Re: [go-nuts] overriding image.Decode image type detection
On Mon, 2023-03-06 at 14:38 +1100, Nigel Tao wrote: > On Sun, Feb 26, 2023 at 12:43 PM 'Dan Kortschak' via golang-nuts > wrote: > > The alternative is to > > replicate the image.Decode functionality, including registration > > which > > seems ugly. > > It may seem ugly but that is what I'd recommend. > https://go.dev/src/image/format.go is only 110 lines of code. Yeah, this is what I went with. > > Would a change to > > image.RegisterFormat that did a replacement of existing > registrations > > that are identical to a new registration rather than an append be > > entertained (I can see good reasons for a no here)? > > I'd be unlikely to entertain it, due to https://www.hyrumslaw.com/ Indeed. I think there are foot guns in the approach as well. Though it's been the way it is for years, it may be worth have a comment that registration for a type will only be effective once. thanks Dan -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/fae84889ed3a44f0f0e9c0fac3dd9a931305c354.camel%40kortschak.io.
Re: [go-nuts] overriding image.Decode image type detection
On Sun, Feb 26, 2023 at 12:43 PM 'Dan Kortschak' via golang-nuts wrote: > The alternative is to > replicate the image.Decode functionality, including registration which > seems ugly. It may seem ugly but that is what I'd recommend. https://go.dev/src/image/format.go is only 110 lines of code. In hindsight, I think the image.RegisterFormat API was a mistake, being backed by global state that's modified by init functions you may not be aware of (if in transitively imported packages). These days, I'd create my own multiFormatImageDecoder that explicitly listed its constituent single-format decoders. It would also be a small amount of code, and could easily live outside of the stdlib. > Would a change to > image.RegisterFormat that did a replacement of existing registrations > that are identical to a new registration rather than an append be > entertained (I can see good reasons for a no here)? I'd be unlikely to entertain it, due to https://www.hyrumslaw.com/ -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOeFMNX6miKyca5Xp_v%2B4uvXft3fKxQmrk5Ab-LEveCtyYKDnA%40mail.gmail.com.
[go-nuts] overriding image.Decode image type detection
I'm implementing a image renderer on an external device and want to include GIF animation support. So far this is working fine, but I've found a difficulty that comes from for image.Decode's file type detection is registered. What I have is shim type that wraps *gif.GIF but also implements image.Image. Registering the decoder for this for "GIF8?a" does not work because the registration function, image.RegisterFormat appends the registration details to the existing registered formats. Since my code depends on "image/gif", the package registration has already happened during init and I don't see a way to ever beat the "image/gif" registration call during init. The workaround is to seek to the start of the file if image.Decode finds a gif, which is inefficient and will not handle the case of a non-seekable io.Reader. The alternative is to replicate the image.Decode functionality, including registration which seems ugly. The existing behaviour is somewhat surprising since there is no indication in the docs that a new registration of the same magic bytes will not work. Is there a commonly used work-around for this? Would a change to image.RegisterFormat that did a replacement of existing registrations that are identical to a new registration rather than an append be entertained (I can see good reasons for a no here)? Dan -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/63152ea80145ea3076f68772e3d03156ba23f680.camel%40kortschak.io.
