Thanks again Dan, I enjoyed reading Rob Pike's blog post.
I think you are right with your point, it has to be one way and not every
machine use the same representation anyway.
Cheers,
Pablo
On Wed, Jan 11, 2017 at 7:32 PM, Dan Kortschak <
dan.kortsc...@adelaide.edu.au> wrote:
> On Wed, 2017-01-
On Wed, 2017-01-11 at 16:46 +1100, Pablo Rozas Larraondo wrote:
> Thanks Dan. I'm just surprised that Gray16 uses big endian when, for
> example, Go's uint16 type uses the little endian convention.
On *most* supported architectures.
> I guess I find this weird and I want to know if there is a rea
Thanks Dan. I'm just surprised that Gray16 uses big endian when, for
example, Go's uint16 type uses the little endian convention.
I guess I find this weird and I want to know if there is a reason for
implementing Gray16 this way.
On Wed, Jan 11, 2017 at 4:40 PM, Dan Kortschak <
dan.kortsc...@adel
On Wed, 2017-01-11 at 16:21 +1100, Pablo Rozas Larraondo wrote:
> I'm confused with image.Gray16 having pixel values represented in the
> wrong order. It seems to me that image.Gray16 considers numbers to be
> big endian instead of little endian.
Why do you think that is the wrong order?
Here is
Hi,
I'm confused with image.Gray16 having pixel values represented in the wrong
order. It seems to me that image.Gray16 considers numbers to be big endian
instead of little endian.
I've created a small playground example to illustrate this:
https://play.golang.org/p/bhYbuIkkOz
Is there something
