On Sat, May 9, 2015 at 12:23 AM, simon place wrote:
also 'for the record', i still disagree, all colors are rbga from the
OUTSIDE, because they only have an RGBA() method in the interface, (images
should be on the 'outside', not caring about the colors implementation, this
is what interfaces are all about. colorModel() kind of leaks color types
into image.) Other code, thankfully, seems to work to the interface, this is
why the 'wrong' colormodel still works.
It's true that color.Color has only one method, RGBA, but that isn't
the only thing you can do with them. As I said earlier, you can do a
type assertion, and the following code is valid:

var m image.Image = etc
if m.ColorModel() == color.RGBAModel {
   for y := etc {
     for x := etc {
       c := m.At(x, y)
       // The next line should never panic because we've already
       // checked that m.ColorModel() == color.RGBAModel.
       rgba := c.(color.RGBA)

A type assertion is lossless, and the Color.RGBA method is allowed to
be lossy, so there is a reason to prefer the former.

i also have little idea what colormodel is for, what it can do, how to
implement it, from the docs, all i could do would be look at the stdlib
code, copy it, (is this the spirit of it?) and hope nobody re-interprets it.
not really tenable.
I've already agreed that the docs seem insufficiently clear, but I
will again repeat myself that the point of the Image.ColorModel
interface is for an image to be able to say to the PNG encoder or the
JPEG encoder or any other image encoder (in or out of the standard
library) that e.g. it is a grayscale image and so can be stored on
disk or sent on a network more efficiently than an RGBA image, and
likewise an RGBA image can be encoded more efficiently than an RGBA64

You are right that the standard library does not really use the
ColorModel method. The intention was to use it as I just described:
see the "switch on m.ColorModel() instead of type" TODO comment in
http://golang.org/src/image/jpeg/writer.go. But in practice, this
hasn't come up very often, including code outside the standard library
that uses the standard library, so it has been a low priority bug to
fix. As I have said before, in hindsight, it may have been a better
design for the ColorModel method to be optional, but we are bound by
the Go 1.x compatibility promise.

but by using an image type (without colormodel) this leak is plugged, i
believe this fixes all issues properly. are you seeing any downsides to
Look, if your code solves your problem, then it solves your problem.
The downside I see is that you need two types: your custom image
implementation, and a wrapper type to add the ColorModel method.
Having two types means that you have to wrap whenever you use any
package that expects to take the standard image.Image, whether that
other package is in the standard library (such as PNG and JPEG
codecs), the extended libraries (such as golang.org/x/image/draw), or
third party libraries (such as
https://github.com/disintegration/gift). Why use two types and care
about the boundary between your and other code, when a single type
will do?

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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts


Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 12 of 12 | next ›
Discussion Overview
groupgolang-nuts @
postedApr 25, '15 at 8:20p
activeMay 8, '15 at 11:52p

2 users in discussion

Simon place: 7 posts Nigel Tao: 5 posts



site design / logo © 2021 Grokbase