Re: [boost] [gil] Who has a big-endian machine?

On Sep 1, 2010, at 1:24 PM, Belcourt, Kenneth wrote:
On Sep 1, 2010, at 12:05 PM, Christian Henning wrote:
Hi there, could someone with a big-endian machine run the following code with the latest gil code from the trunk?
./ibm.hw
purple.sandia.gov: 31488 MB 8 CPU PowerPC_POWER5 model IBM, 9118-575
xlC -g -I./boost-trunk gil.cpp
./a.out Assertion failed: v1 == 6, file gil.cpp, line 47 Abort (core dumped)
Same source code. -- Noel

Thanks for running the test. On Wed, Sep 1, 2010 at 3:30 PM, Belcourt, Kenneth <kbelco@sandia.gov> wrote:
./a.out Assertion failed: v1 == 6, file gil.cpp, line 47 Abort (core dumped)
Could you tell me what the values are? Thanks, Christian

On Sep 1, 2010, at 3:18 PM, Christian Henning wrote:
Thanks for running the test.
On Wed, Sep 1, 2010 at 3:30 PM, Belcourt, Kenneth <kbelco@sandia.gov> wrote:
./a.out Assertion failed: v1 == 6, file gil.cpp, line 47 Abort (core dumped)
Could you tell me what the values are?
On Solaris. v1, v2, v4, v5 = 5 v3 = 1 v6 = 3 v7, v8 = 0 -- Noel

Hi Kenneth thanks for sending me the values. I never really dealt with big endian. How would the bits are read? For instance, in my test code I create this bit pattern: 1011 0110 0110 1101 1101 1011 On my my little endian system I get 011 for each value, since each byte is read right to left. But how is it done with big endian? Thanks, Christian On Wed, Sep 1, 2010 at 5:27 PM, Belcourt, Kenneth <kbelco@sandia.gov> wrote:
On Sep 1, 2010, at 3:18 PM, Christian Henning wrote:
Thanks for running the test.
On Wed, Sep 1, 2010 at 3:30 PM, Belcourt, Kenneth <kbelco@sandia.gov> wrote:
./a.out
Assertion failed: v1 == 6, file gil.cpp, line 47 Abort (core dumped)
Could you tell me what the values are?
On Solaris.
v1, v2, v4, v5 = 5 v3 = 1 v6 = 3 v7, v8 = 0
-- Noel
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On Sep 2, 2010, at 1:34 PM, Christian Henning wrote:
thanks for sending me the values. I never really dealt with big endian. How would the bits are read?
The most significant byte (MSB) is stored at the lowest address.
For instance, in my test code I create this bit pattern:
1011 0110 0110 1101 1101 1011
On my my little endian system I get 011 for each value, since each byte is read right to left. But how is it done with big endian?
Eek, good question. I'm not quite sure what you're doing but you seem to be picking off consecutive 3 bit sequences in the buf vector and interpreting them as integers? For example, the bit_range for p2 references bit_offset 3 into the first byte while p3 references bit 6 in the first byte. And indeed the value for v2 is 5 which is what I'd expect though v3's value is 1 rather than 4. So I'd naively I'd expect the big endian bit sequence above to yield: 101 101 100 110 110 111 011 011 resulting in values for v1 to v8 as: 5 5 4 6 6 7 3 3 So v1 and v2 both seem to be interpreted correctly with the value 5, but p3 / v3 has clearly gone awry (perhaps due to spanning the byte boundary). Not sure if that helps. -- Noel

Hi Kenneth,
I'm not quite sure what you're doing but you seem to be picking off consecutive 3 bit sequences in the buf vector and interpreting them as integers? For example, the bit_range for p2 references bit_offset 3 into the first byte while p3 references bit 6 in the first byte. And indeed the value for v2 is 5 which is what I'd expect though v3's value is 1 rather than 4.
When reading a 3bit tiff image for instance I would have a byte array and need to pick off 3bit unsigned integers. There was a bug in gil that I have fixed. I also would like to add some test code to make sure we can detect problems earlier. But that test code needs to run on big and little endian machines.
So I'd naively I'd expect the big endian bit sequence above to yield:
101 101 100 110 110 111 011 011
resulting in values for v1 to v8 as:
5 5 4 6 6 7 3 3
Seems like bytes are read left to right on big endian machines. It's the other way around on my machine. Could you do me a favor and run again the code below. #include <cassert> #include <vector> #include <boost/assert.hpp> #include <boost/gil/gil_all.hpp> using namespace std; using namespace boost; using namespace gil; int main() { typedef bit_aligned_image1_type< 3, gray_layout_t >::type gray3_image_t; typedef gray3_image_t image_t; typedef image_t::view_t view_t; typedef view_t::reference ref_t; typedef bit_aligned_pixel_iterator< ref_t > iterator_t; std::vector< unsigned char > buf( 4 ); int x = 1; if( *( char*) &x ) { //small endian // bit pattern is: 1011 0110 0110 1101 1101 1011 // each byte is read right to left buf[0] = 182; buf[1] = 109; buf[2] = 219; } else { //little endian // bit pattern is: 1101 1011 0110 1101 1011 0110 // each byte is read right to left buf[0] = 219; buf[1] = 109; buf[2] = 182; } iterator_t it( &buf[0], 0 ); ref_t p1 = *it; it++; ref_t p2 = *it; it++; ref_t p3 = *it; it++; ref_t p4 = *it; it++; ref_t p5 = *it; it++; ref_t p6 = *it; it++; ref_t p7 = *it; it++; ref_t p8 = *it; it++; unsigned char v1 = get_color( p1, gray_color_t() ); unsigned char v2 = get_color( p2, gray_color_t() ); unsigned char v3 = get_color( p3, gray_color_t() ); unsigned char v4 = get_color( p4, gray_color_t() ); unsigned char v5 = get_color( p5, gray_color_t() ); unsigned char v6 = get_color( p6, gray_color_t() ); unsigned char v7 = get_color( p7, gray_color_t() ); unsigned char v8 = get_color( p8, gray_color_t() ); // all values should be 110b ( 6 ); assert( v1 == 6 ); assert( v2 == 6 ); assert( v3 == 6 ); assert( v4 == 6 ); assert( v5 == 6 ); assert( v6 == 6 ); assert( v7 == 6 ); assert( v8 == 6 ); return 0; } Thanks a lot, Christian

On Sep 3, 2010, at 12:31 PM, Christian Henning wrote:
Hi Kenneth,
DBA (doing business as) Noel.
I'm not quite sure what you're doing but you seem to be picking off consecutive 3 bit sequences in the buf vector and interpreting them as integers? For example, the bit_range for p2 references bit_offset 3 into the first byte while p3 references bit 6 in the first byte. And indeed the value for v2 is 5 which is what I'd expect though v3's value is 1 rather than 4.
When reading a 3bit tiff image for instance I would have a byte array and need to pick off 3bit unsigned integers. There was a bug in gil that I have fixed. I also would like to add some test code to make sure we can detect problems earlier. But that test code needs to run on big and little endian machines.
So I'd naively I'd expect the big endian bit sequence above to yield:
101 101 100 110 110 111 011 011
resulting in values for v1 to v8 as:
5 5 4 6 6 7 3 3
Seems like bytes are read left to right on big endian machines.
Yes.
Could you do me a favor and run again the code below.
Here's the bit pattern (0xDB,0x6D,0xB6). In decimal it's (219,109,182). Yes, updated against trunk and recompiled. The code below never enters the else clause (for big endian) so I modified your code by hand (the version I ran is attached). v1 = v2 = v3 = 5 v4 = v5 = v6 = 3 v7 = v8 = 0 -- Noel
participants (2)
-
Belcourt, Kenneth
-
Christian Henning