MESSAGE
| DATE | 2016-12-06 |
| FROM | Christopher League
|
| SUBJECT | Re: [Hangout-NYLXS] [Learn] png data format
|
From hangout-bounces-at-nylxs.com Tue Dec 6 10:40:09 2016
Return-Path:
X-Original-To: archive-at-mrbrklyn.com
Delivered-To: archive-at-mrbrklyn.com
Received: from www.mrbrklyn.com (www.mrbrklyn.com [96.57.23.82])
by mrbrklyn.com (Postfix) with ESMTP id 647C316131C;
Tue, 6 Dec 2016 10:40:08 -0500 (EST)
X-Original-To: hangout-at-nylxs.com
Delivered-To: hangout-at-nylxs.com
Received: by mrbrklyn.com (Postfix, from userid 1000)
id 46FBB161311; Tue, 6 Dec 2016 10:07:28 -0500 (EST)
Resent-From: Ruben Safir
Resent-Date: Tue, 6 Dec 2016 10:07:28 -0500
Resent-Message-ID: <20161206150728.GD24997-at-www.mrbrklyn.com>
Resent-To: hangout-at-nylxs.com
X-Original-To: ruben-at-mrbrklyn.com
Delivered-To: ruben-at-mrbrklyn.com
Received: from liucs.net (contrapunctus.net [174.136.110.10])
by mrbrklyn.com (Postfix) with ESMTP id 5FE68161311
for ; Tue, 6 Dec 2016 09:32:45 -0500 (EST)
Received: from localhost (pool-98-113-34-169.nycmny.fios.verizon.net
[98.113.34.169]) by liucs.net (Postfix) with ESMTPSA id 7AB03E096;
Tue, 6 Dec 2016 09:32:43 -0500 (EST)
From: Christopher League
To: ruben safir , Hangout ,
learn-at-nylxs.com
In-Reply-To: <87bmwpf857.fsf-at-contrapunctus.net>
References: <66105244-4afa-4330-b0c2-0661bde965fd-at-mrbrklyn.com>
<87bmwpf857.fsf-at-contrapunctus.net>
User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/25.1.1
(x86_64-unknown-linux-gnu)
Date: Tue, 06 Dec 2016 09:32:39 -0500
Message-ID: <878trtf7qw.fsf-at-contrapunctus.net>
MIME-Version: 1.0
X-UID: 32783
X-Mailman-Approved-At: Tue, 06 Dec 2016 10:39:57 -0500
X-Content-Filtered-By: Mailman/MimeDel 2.1.17
Subject: Re: [Hangout-NYLXS] [Learn] png data format
X-BeenThere: hangout-at-nylxs.com
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: NYLXS Discussions List
List-Id: NYLXS Discussions List
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
Content-Type: multipart/mixed; boundary="===============0873416613=="
Errors-To: hangout-bounces-at-nylxs.com
Sender: "hangout"
--===============0873416613==
Content-Type: multipart/signed; boundary="===-=-=";
micalg=pgp-sha256; protocol="application/pgp-signature"
--===-=-=
Content-Type: multipart/alternative; boundary="==-=-="
--==-=-=
Content-Type: text/plain
Ah... I *can* confirm the 218103808 number now. The number you're seeing
in the dump *is* in octal: the three highest-order bytes are 000(oct)
and the low order byte is 015(oct) == 8+5 == 13(dec) == D(hex).
So the full 32-bit number in hexadecimal is 0x0000000D.
Intel architecture stores those bytes in the order 0x0D, 0x00, 0x00,
0x00.
This number, 0x0D000000 == 218103808.
The D is in column 6 (counting from zero at the right), whose
place-value is 16^6 == 16777216, and 13*16777216 == 218103808.
CL
Christopher League writes:
> I can't really confirm this based on the numbers you've given (218103808
> isn't how I think it would come out) but it sounds A LOT like an
> endianness issue. That is, the 4 bytes are stored big-endian in the
> file, but you're operating on a system (Intel) that is little-endian. So
> if you read an entire uint32 at once, it doesn't come out correctly.
> Reading one byte at a time, you can then swap the bytes into the right
> order.
>
> Also, that's not a hex dump, right...? is it octal? decimal?
>
> CL
>
> ruben safir writes:
>
>> Hello
>>
>> I'm having trouble with this imput of data from a PNG image. The
>> specification says that "chunks" have a 4 byte field that is the length
>> of the attached data segment. I tried to read the length in for a chunk
>> that has a length of 13, which was confirmed in a hexdump
>>
>> 0000000 211 120 116 107 015 012 032 012 -->>000 000 000 015<<-- 111 110
>> 104 122
>> 0000010 000 000 041 215 000 000 007 165 010 006 000 000 001 206 055 074
>> 0000020 336 000 000 000 004 147 101 115 101 000 000 261 217 013 374 141
>>
>> I am storing the data in a uint32_t variable using the following code,
>> but the value keeps showing up with a huge number 218103808 which
>> happens to be the number that is evaluated by iostream for the value of
>> the whole chunk
>>
>>
>> done reading header
>>
>>
>>
>> Sizeof Chunk 4
>> Raw Chunk Number 0: 218103808
>> ***LENGTH****
>> Length value => 218103808
>> Sizeof Byte 1
>> Character 0::
>> ^-at-
>> Byte 0::
>> 0
>> Character 1::
>> ^-at-
>> Byte 1::
>> 0
>> Character 2::
>> ^-at-
>> Byte 2::
>> 0
>> Character 3::
>> Byte 3::
>> 13
>>
>>
>> As yet, when I break it down by single bytes, it returns 0 0 0 13, which
>> is correct. ddd seems to say the same thing, and I don't know why.
>> When evaluated as 4 bytes, you get this large number, but when you
>> evaluate them seperately, each byte, it comes out right.
>>
>> The code snippet I'm using looks like this
>>
>> in the .h file #ifndef PNGPRJ
>> #define PNGPRJ
>> #include
>> namespace png_proj{
>> typedef uint32_t CHUNK;
>>
>>
>>
>> In the .cpp file
>> void Image::read_chunk()
>> {
>> char * cur = get_index();
>> CHUNK * tmp = reinterpret_cast(cur);
>> std::cout << std::endl << "Sizeof Chunk " << sizeof(*tmp) << std::endl;
>> for(int j = 0; j<4; j++){
>> std::cout << "Raw Chunk Number " << j << ": " << *tmp << std::endl;
>>
>>
>> switch ( j ) {
>> case 0:
>> std::cout << "***LENGTH****" << std::endl;
>> set_length(static_cast(*tmp));
>> std::cout << "Length value => " << static_cast(*tmp) << std::endl;
>> break;
>>
>> case 1:
>> std::cout << "***TYPE****" << std::endl;
>> set_type(static_cast(*tmp));
>> break;
>>
>> case 2:
>> {
>> std::cout << "***DATA****" << std::endl;
>> unsigned long int l = static_cast(get_length());
>> std::cout << "buffer size should be " << get_length() << std::endl;
>> int8_t * buffer = new int8_t[l];
>> std::cout << "buffer element size is " << *buffer << std::endl;
>> std::cout << "buffer size is " << l << std::endl;
>> for(unsigned int k = 0; k < get_length(); k++){
>> buffer[k] = static_cast(tmp[k]);
>> std::cout << "data " << *buffer << std::endl;
>> }
>> set_data(buffer);
>> }
>> break;
>>
>> case 3:
>> std::cout << "***CRC****" << std::endl;
>> set_crc(static_cast(*tmp));
>> break;
>>
>> default:
>> std::cout << "***NOMANDSLAND****" << std::endl;
>> break;
>> } /* ----- end switch ----- */
>>
>> char * tmp2 = reinterpret_cast(tmp); //reading each byte
>> std::cout << "Sizeof Byte " << sizeof(*tmp2) << std::endl;
>> //std::cout << "Mark ==>>" << __LINE__ << std::endl;
>> for(int i=0; i<4; i++){
>> std::cout << "Character " << i << "::" << std::endl << "\t" << *tmp2
>> << std::endl;
>> std::cout << "Byte " << i << "::" << std::endl << "\t" <<
>> static_cast(*tmp2) << std::endl;
>> tmp2++;
>> }
>> std::cout<>> std::cout<>> tmp++;
>> cur = ( reinterpret_cast(tmp) );
>> }
>> set_index(cur);
>> }
>>
>>
>>
>> I dug through libpng since this seems to not being doing what I
>> expected. They seem to set it up as 4 byte array
>>
>> void /* PRIVATE */
>> png_push_read_chunk(png_structrp png_ptr, png_inforp info_ptr)
>> {
>> png_uint_32 chunk_name;
>> #ifdef PNG_HANDLE_AS_UNKNOWN_SUPPORTED
>> int keep; /* unknown handling method */
>> #endif
>>
>> /* First we make sure we have enough data for the 4-byte chunk name
>> * and the 4-byte chunk length before proceeding with decoding the
>> * chunk data. To fully decode each of these chunks, we also make
>> * sure we have enough data in the buffer for the 4-byte CRC at the
>> * end of every chunk (except IDAT, which is handled separately).
>> */
>> if ((png_ptr->mode & PNG_HAVE_CHUNK_HEADER) == 0)
>> {
>> png_byte chunk_length[4];
>> png_byte chunk_tag[4];
>>
>> PNG_PUSH_SAVE_BUFFER_IF_LT(8)
>> png_push_fill_buffer(png_ptr, chunk_length, 4);
>> png_ptr->push_length = png_get_uint_31(png_ptr, chunk_length);
>> png_reset_crc(png_ptr);
>> png_crc_read(png_ptr, chunk_tag, 4);
>> png_ptr->chunk_name = PNG_CHUNK_FROM_STRING(chunk_tag);
>> png_check_chunk_name(png_ptr, png_ptr->chunk_name);
>> png_ptr->mode |= PNG_HAVE_CHUNK_HEADER;
>> }
>>
>>
>> I'm obviously not understanding something I'm evaluation here. So I'm
>> wondering if anyone can shed light on this.
>> http://www.nylxs.com/docs/grad_school/parallel/src/png/png_proj.h
>> http://www.nylxs.com/docs/grad_school/parallel/src/png/png_proj.cpp
>> http://www.nylxs.com/docs/grad_school/parallel/src/png/main_png.cpp
>> http://www.nylxs.com/docs/grad_school/parallel/src/png/makefile
>>
>> ruben
>>
>> let.me.in
>>
>>
>> Ruben
>> _______________________________________________
>> Learn mailing list
>> Learn-at-nylxs.com
>> http://lists.mrbrklyn.com/mailman/listinfo/learn
--==-=-=
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Ah... I can confirm the 218103808 number now. The number you're seeing
in the dump is in octal: the three highest-order bytes are 000(oct) and
the low order byte is 015(oct) == 8+5 == 13(dec) == D(hex).
So the full 32-bit number in hexadecimal is 0x0000000D.
Intel architecture stores those bytes in the order 0x0D, 0x00, 0x00,
0x00.
This number, 0x0D000000 == 218103808.
The D is in column 6 (counting from zero at the right), whose
place-value is 16^6 == 16777216, and 13*16777216 == 218103808.
CL
Christopher League [1]league-at-contrapunctus.net writes:
I can't really confirm this based on the numbers you've given
(218103808 isn't how I think it would come out) but it sounds A LOT
like an endianness issue. That is, the 4 bytes are stored big-endian
in the file, but you're operating on a system (Intel) that is
little-endian. So if you read an entire uint32 at once, it doesn't
come out correctly. Reading one byte at a time, you can then swap
the bytes into the right order.
Also, that's not a hex dump, right...? is it octal? decimal?
CL
ruben safir [2]ruben-at-mrbrklyn.com writes:
Hello
I'm having trouble with this imput of data from a PNG image. The
specification says that "chunks" have a 4 byte field that is the
length of the attached data segment. I tried to read the length in
for a chunk that has a length of 13, which was confirmed in a
hexdump
0000000 211 120 116 107 015 012 032 012 ->>000 000 000 015<<- 111
110 104 122 0000010 000 000 041 215 000 000 007 165 010 006 000 000
001 206 055 074 0000020 336 000 000 000 004 147 101 115 101 000 000
261 217 013 374 141
I am storing the data in a uint32_t variable using the following
code, but the value keeps showing up with a huge number 218103808
which happens to be the number that is evaluated by iostream for the
value of the whole chunk
done reading header
Sizeof Chunk 4 Raw Chunk Number 0: 218103808 LENGTH* Length value =>
218103808 Sizeof Byte 1 Character 0:: ^-at- Byte 0:: 0 Character 1:: ^-at-
Byte 1:: 0 Character 2:: ^-at- Byte 2:: 0 Character 3:: Byte 3:: 13
As yet, when I break it down by single bytes, it returns 0 0 0 13,
which is correct. ddd seems to say the same thing, and I don't know
why. When evaluated as 4 bytes, you get this large number, but when
you evaluate them seperately, each byte, it comes out right.
The code snippet I'm using looks like this
in the .h file #ifndef PNGPRJ #define PNGPRJ #include namespace
png_proj{ typedef uint32_t CHUNK;
In the .cpp file void Image::read_chunk() { char * cur =
get_index(); CHUNK * tmp = reinterpret_cast(cur); std::cout <<
std::endl << "Sizeof Chunk" << sizeof(tmp) << std::endl; for(int j =
0; j<4; j++){ std::cout << "Raw Chunk Number" << j << ":" << tmp <<
std::endl;
switch ( j ) {
case 0:
std::cout << "***LENGTH****" << std::endl;
set_length(static_cast(*tmp));
std::cout << "Length value => " << static_cast(*tmp) << std::e
ndl;
break;
case 1:
std::cout << "***TYPE****" << std::endl;
set_type(static_cast(*tmp));
break;
case 2:
{
std::cout << "***DATA****" << std::endl;
unsigned long int l = static_cast(get_length());
std::cout << "buffer size should be " << get_length() << std::endl;
int8_t * buffer = new int8_t[l];
std::cout << "buffer element size is " << *buffer << std::endl;
std::cout << "buffer size is " << l << std::endl;
for(unsigned int k = 0; k < get_length(); k++){
buffer[k] = static_cast(tmp[k]);
std::cout << "data " << *buffer << std::endl;
}
set_data(buffer);
}
break;
case 3:
std::cout << "***CRC****" << std::endl;
set_crc(static_cast(*tmp));
break;
default:
std::cout << "***NOMANDSLAND****" << std::endl;
break;
} /* ----- end switch ----- */
char * tmp2 = reinterpret_cast(tmp); //reading each byte
std::cout << "Sizeof Byte " << sizeof(*tmp2) << std::endl;
//std::cout << "Mark ==>>" << __LINE__ << std::endl;
for(int i=0; i<4; i++){
std::cout << "Character " << i << "::" << std::endl << "\t" << *tmp2
<< std::endl; std::cout << "Byte" << i << "::" << std::endl << "" <<
static_cast(*tmp2) << std::endl; tmp2++; } std::cout<(tmp) ); }
set_index(cur); }
I dug through libpng since this seems to not being doing what I
expected. They seem to set it up as 4 byte array
void /* PRIVATE / png_push_read_chunk(png_structrp png_ptr,
png_inforp info_ptr) { png_uint_32 chunk_name; #ifdef
PNG_HANDLE_AS_UNKNOWN_SUPPORTED int keep; / unknown handling method
*/ #endif
/* First we make sure we have enough data for the 4-byte chunk name
* and the 4-byte chunk length before proceeding with decoding the *
chunk data. To fully decode each of these chunks, we also make *
sure we have enough data in the buffer for the 4-byte CRC at the *
end of every chunk (except IDAT, which is handled separately). */ if
((png_ptr->mode & PNG_HAVE_CHUNK_HEADER) == 0) { png_byte
chunk_length[4]; png_byte chunk_tag[4];
PNG_PUSH_SAVE_BUFFER_IF_LT(8)
png_push_fill_buffer(png_ptr, chunk_length, 4);
png_ptr->push_length = png_get_uint_31(png_ptr, chunk_length);
png_reset_crc(png_ptr);
png_crc_read(png_ptr, chunk_tag, 4);
png_ptr->chunk_name = PNG_CHUNK_FROM_STRING(chunk_tag);
png_check_chunk_name(png_ptr, png_ptr->chunk_name);
png_ptr->mode |= PNG_HAVE_CHUNK_HEADER;
}
I'm obviously not understanding something I'm evaluation here. So
I'm wondering if anyone can shed light on this.
http://www.nylxs.com/docs/grad_school/parallel/src/png/png_proj.h
http://www.nylxs.com/docs/grad_school/parallel/src/png/png_proj.cpp
http://www.nylxs.com/docs/grad_school/parallel/src/png/main_png.cpp
http://www.nylxs.com/docs/grad_school/parallel/src/png/makefile
ruben
let.me.in
Ruben _______________________________________________ Learn mailing
list Learn-at-nylxs.com
http://lists.mrbrklyn.com/mailman/listinfo/learn
References
1. mailto:league-at-contrapunctus.net
2. mailto:ruben-at-mrbrklyn.com
--==-=-=--
--===-=-=
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEE3x0LN7z09c1wuX58a4uzPU8xsIsFAlhGzAgACgkQa4uzPU8x
sIumxAgAjJOgm8j+3VdoDoi7Q+KWPaE5CijBrzENzLvdnwhYvLPESotsk/s8o6b6
RKL2TDTDPNtT2ioyEKbtRYseHQYJofXpWYMFCemFfDzNuWawXCalWTTlJ7MvbZ3w
+JuCJP4kSeW6Fz5KONKz26se+taARS5KHWUoLQ5nBLVbC9mq8T2jGgmwVjE85Yo9
0uidmL5KaitsSeQYp1r9uRImr/DPVK/YXOLHWa5bVmjcUDFMvhnFQNZ1aoHE/YG2
rJk+/oFWz1ZFvTJkrtzAW2FtQL+cFG6jCzCXK7Qk8UFx13IZT9+l2/t4K7lc0LcO
joMC0klXtdrC857JNPmsMs7m7N7MtQ==
=QhWr
-----END PGP SIGNATURE-----
--===-=-=--
--===============0873416613==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
hangout mailing list
hangout-at-nylxs.com
http://www.nylxs.com/
--===============0873416613==--
--===============0873416613==
Content-Type: multipart/signed; boundary="===-=-=";
micalg=pgp-sha256; protocol="application/pgp-signature"
--===-=-=
Content-Type: multipart/alternative; boundary="==-=-="
--==-=-=
Content-Type: text/plain
Ah... I *can* confirm the 218103808 number now. The number you're seeing
in the dump *is* in octal: the three highest-order bytes are 000(oct)
and the low order byte is 015(oct) == 8+5 == 13(dec) == D(hex).
So the full 32-bit number in hexadecimal is 0x0000000D.
Intel architecture stores those bytes in the order 0x0D, 0x00, 0x00,
0x00.
This number, 0x0D000000 == 218103808.
The D is in column 6 (counting from zero at the right), whose
place-value is 16^6 == 16777216, and 13*16777216 == 218103808.
CL
Christopher League writes:
> I can't really confirm this based on the numbers you've given (218103808
> isn't how I think it would come out) but it sounds A LOT like an
> endianness issue. That is, the 4 bytes are stored big-endian in the
> file, but you're operating on a system (Intel) that is little-endian. So
> if you read an entire uint32 at once, it doesn't come out correctly.
> Reading one byte at a time, you can then swap the bytes into the right
> order.
>
> Also, that's not a hex dump, right...? is it octal? decimal?
>
> CL
>
> ruben safir writes:
>
>> Hello
>>
>> I'm having trouble with this imput of data from a PNG image. The
>> specification says that "chunks" have a 4 byte field that is the length
>> of the attached data segment. I tried to read the length in for a chunk
>> that has a length of 13, which was confirmed in a hexdump
>>
>> 0000000 211 120 116 107 015 012 032 012 -->>000 000 000 015<<-- 111 110
>> 104 122
>> 0000010 000 000 041 215 000 000 007 165 010 006 000 000 001 206 055 074
>> 0000020 336 000 000 000 004 147 101 115 101 000 000 261 217 013 374 141
>>
>> I am storing the data in a uint32_t variable using the following code,
>> but the value keeps showing up with a huge number 218103808 which
>> happens to be the number that is evaluated by iostream for the value of
>> the whole chunk
>>
>>
>> done reading header
>>
>>
>>
>> Sizeof Chunk 4
>> Raw Chunk Number 0: 218103808
>> ***LENGTH****
>> Length value => 218103808
>> Sizeof Byte 1
>> Character 0::
>> ^-at-
>> Byte 0::
>> 0
>> Character 1::
>> ^-at-
>> Byte 1::
>> 0
>> Character 2::
>> ^-at-
>> Byte 2::
>> 0
>> Character 3::
>> Byte 3::
>> 13
>>
>>
>> As yet, when I break it down by single bytes, it returns 0 0 0 13, which
>> is correct. ddd seems to say the same thing, and I don't know why.
>> When evaluated as 4 bytes, you get this large number, but when you
>> evaluate them seperately, each byte, it comes out right.
>>
>> The code snippet I'm using looks like this
>>
>> in the .h file #ifndef PNGPRJ
>> #define PNGPRJ
>> #include
>> namespace png_proj{
>> typedef uint32_t CHUNK;
>>
>>
>>
>> In the .cpp file
>> void Image::read_chunk()
>> {
>> char * cur = get_index();
>> CHUNK * tmp = reinterpret_cast(cur);
>> std::cout << std::endl << "Sizeof Chunk " << sizeof(*tmp) << std::endl;
>> for(int j = 0; j<4; j++){
>> std::cout << "Raw Chunk Number " << j << ": " << *tmp << std::endl;
>>
>>
>> switch ( j ) {
>> case 0:
>> std::cout << "***LENGTH****" << std::endl;
>> set_length(static_cast(*tmp));
>> std::cout << "Length value => " << static_cast(*tmp) << std::endl;
>> break;
>>
>> case 1:
>> std::cout << "***TYPE****" << std::endl;
>> set_type(static_cast(*tmp));
>> break;
>>
>> case 2:
>> {
>> std::cout << "***DATA****" << std::endl;
>> unsigned long int l = static_cast(get_length());
>> std::cout << "buffer size should be " << get_length() << std::endl;
>> int8_t * buffer = new int8_t[l];
>> std::cout << "buffer element size is " << *buffer << std::endl;
>> std::cout << "buffer size is " << l << std::endl;
>> for(unsigned int k = 0; k < get_length(); k++){
>> buffer[k] = static_cast(tmp[k]);
>> std::cout << "data " << *buffer << std::endl;
>> }
>> set_data(buffer);
>> }
>> break;
>>
>> case 3:
>> std::cout << "***CRC****" << std::endl;
>> set_crc(static_cast(*tmp));
>> break;
>>
>> default:
>> std::cout << "***NOMANDSLAND****" << std::endl;
>> break;
>> } /* ----- end switch ----- */
>>
>> char * tmp2 = reinterpret_cast(tmp); //reading each byte
>> std::cout << "Sizeof Byte " << sizeof(*tmp2) << std::endl;
>> //std::cout << "Mark ==>>" << __LINE__ << std::endl;
>> for(int i=0; i<4; i++){
>> std::cout << "Character " << i << "::" << std::endl << "\t" << *tmp2
>> << std::endl;
>> std::cout << "Byte " << i << "::" << std::endl << "\t" <<
>> static_cast(*tmp2) << std::endl;
>> tmp2++;
>> }
>> std::cout<>> std::cout<>> tmp++;
>> cur = ( reinterpret_cast(tmp) );
>> }
>> set_index(cur);
>> }
>>
>>
>>
>> I dug through libpng since this seems to not being doing what I
>> expected. They seem to set it up as 4 byte array
>>
>> void /* PRIVATE */
>> png_push_read_chunk(png_structrp png_ptr, png_inforp info_ptr)
>> {
>> png_uint_32 chunk_name;
>> #ifdef PNG_HANDLE_AS_UNKNOWN_SUPPORTED
>> int keep; /* unknown handling method */
>> #endif
>>
>> /* First we make sure we have enough data for the 4-byte chunk name
>> * and the 4-byte chunk length before proceeding with decoding the
>> * chunk data. To fully decode each of these chunks, we also make
>> * sure we have enough data in the buffer for the 4-byte CRC at the
>> * end of every chunk (except IDAT, which is handled separately).
>> */
>> if ((png_ptr->mode & PNG_HAVE_CHUNK_HEADER) == 0)
>> {
>> png_byte chunk_length[4];
>> png_byte chunk_tag[4];
>>
>> PNG_PUSH_SAVE_BUFFER_IF_LT(8)
>> png_push_fill_buffer(png_ptr, chunk_length, 4);
>> png_ptr->push_length = png_get_uint_31(png_ptr, chunk_length);
>> png_reset_crc(png_ptr);
>> png_crc_read(png_ptr, chunk_tag, 4);
>> png_ptr->chunk_name = PNG_CHUNK_FROM_STRING(chunk_tag);
>> png_check_chunk_name(png_ptr, png_ptr->chunk_name);
>> png_ptr->mode |= PNG_HAVE_CHUNK_HEADER;
>> }
>>
>>
>> I'm obviously not understanding something I'm evaluation here. So I'm
>> wondering if anyone can shed light on this.
>> http://www.nylxs.com/docs/grad_school/parallel/src/png/png_proj.h
>> http://www.nylxs.com/docs/grad_school/parallel/src/png/png_proj.cpp
>> http://www.nylxs.com/docs/grad_school/parallel/src/png/main_png.cpp
>> http://www.nylxs.com/docs/grad_school/parallel/src/png/makefile
>>
>> ruben
>>
>> let.me.in
>>
>>
>> Ruben
>> _______________________________________________
>> Learn mailing list
>> Learn-at-nylxs.com
>> http://lists.mrbrklyn.com/mailman/listinfo/learn
--==-=-=
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Ah... I can confirm the 218103808 number now. The number you're seeing
in the dump is in octal: the three highest-order bytes are 000(oct) and
the low order byte is 015(oct) == 8+5 == 13(dec) == D(hex).
So the full 32-bit number in hexadecimal is 0x0000000D.
Intel architecture stores those bytes in the order 0x0D, 0x00, 0x00,
0x00.
This number, 0x0D000000 == 218103808.
The D is in column 6 (counting from zero at the right), whose
place-value is 16^6 == 16777216, and 13*16777216 == 218103808.
CL
Christopher League [1]league-at-contrapunctus.net writes:
I can't really confirm this based on the numbers you've given
(218103808 isn't how I think it would come out) but it sounds A LOT
like an endianness issue. That is, the 4 bytes are stored big-endian
in the file, but you're operating on a system (Intel) that is
little-endian. So if you read an entire uint32 at once, it doesn't
come out correctly. Reading one byte at a time, you can then swap
the bytes into the right order.
Also, that's not a hex dump, right...? is it octal? decimal?
CL
ruben safir [2]ruben-at-mrbrklyn.com writes:
Hello
I'm having trouble with this imput of data from a PNG image. The
specification says that "chunks" have a 4 byte field that is the
length of the attached data segment. I tried to read the length in
for a chunk that has a length of 13, which was confirmed in a
hexdump
0000000 211 120 116 107 015 012 032 012 ->>000 000 000 015<<- 111
110 104 122 0000010 000 000 041 215 000 000 007 165 010 006 000 000
001 206 055 074 0000020 336 000 000 000 004 147 101 115 101 000 000
261 217 013 374 141
I am storing the data in a uint32_t variable using the following
code, but the value keeps showing up with a huge number 218103808
which happens to be the number that is evaluated by iostream for the
value of the whole chunk
done reading header
Sizeof Chunk 4 Raw Chunk Number 0: 218103808 LENGTH* Length value =>
218103808 Sizeof Byte 1 Character 0:: ^-at- Byte 0:: 0 Character 1:: ^-at-
Byte 1:: 0 Character 2:: ^-at- Byte 2:: 0 Character 3:: Byte 3:: 13
As yet, when I break it down by single bytes, it returns 0 0 0 13,
which is correct. ddd seems to say the same thing, and I don't know
why. When evaluated as 4 bytes, you get this large number, but when
you evaluate them seperately, each byte, it comes out right.
The code snippet I'm using looks like this
in the .h file #ifndef PNGPRJ #define PNGPRJ #include namespace
png_proj{ typedef uint32_t CHUNK;
In the .cpp file void Image::read_chunk() { char * cur =
get_index(); CHUNK * tmp = reinterpret_cast(cur); std::cout <<
std::endl << "Sizeof Chunk" << sizeof(tmp) << std::endl; for(int j =
0; j<4; j++){ std::cout << "Raw Chunk Number" << j << ":" << tmp <<
std::endl;
switch ( j ) {
case 0:
std::cout << "***LENGTH****" << std::endl;
set_length(static_cast(*tmp));
std::cout << "Length value => " << static_cast(*tmp) << std::e
ndl;
break;
case 1:
std::cout << "***TYPE****" << std::endl;
set_type(static_cast(*tmp));
break;
case 2:
{
std::cout << "***DATA****" << std::endl;
unsigned long int l = static_cast(get_length());
std::cout << "buffer size should be " << get_length() << std::endl;
int8_t * buffer = new int8_t[l];
std::cout << "buffer element size is " << *buffer << std::endl;
std::cout << "buffer size is " << l << std::endl;
for(unsigned int k = 0; k < get_length(); k++){
buffer[k] = static_cast(tmp[k]);
std::cout << "data " << *buffer << std::endl;
}
set_data(buffer);
}
break;
case 3:
std::cout << "***CRC****" << std::endl;
set_crc(static_cast(*tmp));
break;
default:
std::cout << "***NOMANDSLAND****" << std::endl;
break;
} /* ----- end switch ----- */
char * tmp2 = reinterpret_cast(tmp); //reading each byte
std::cout << "Sizeof Byte " << sizeof(*tmp2) << std::endl;
//std::cout << "Mark ==>>" << __LINE__ << std::endl;
for(int i=0; i<4; i++){
std::cout << "Character " << i << "::" << std::endl << "\t" << *tmp2
<< std::endl; std::cout << "Byte" << i << "::" << std::endl << "" <<
static_cast(*tmp2) << std::endl; tmp2++; } std::cout<(tmp) ); }
set_index(cur); }
I dug through libpng since this seems to not being doing what I
expected. They seem to set it up as 4 byte array
void /* PRIVATE / png_push_read_chunk(png_structrp png_ptr,
png_inforp info_ptr) { png_uint_32 chunk_name; #ifdef
PNG_HANDLE_AS_UNKNOWN_SUPPORTED int keep; / unknown handling method
*/ #endif
/* First we make sure we have enough data for the 4-byte chunk name
* and the 4-byte chunk length before proceeding with decoding the *
chunk data. To fully decode each of these chunks, we also make *
sure we have enough data in the buffer for the 4-byte CRC at the *
end of every chunk (except IDAT, which is handled separately). */ if
((png_ptr->mode & PNG_HAVE_CHUNK_HEADER) == 0) { png_byte
chunk_length[4]; png_byte chunk_tag[4];
PNG_PUSH_SAVE_BUFFER_IF_LT(8)
png_push_fill_buffer(png_ptr, chunk_length, 4);
png_ptr->push_length = png_get_uint_31(png_ptr, chunk_length);
png_reset_crc(png_ptr);
png_crc_read(png_ptr, chunk_tag, 4);
png_ptr->chunk_name = PNG_CHUNK_FROM_STRING(chunk_tag);
png_check_chunk_name(png_ptr, png_ptr->chunk_name);
png_ptr->mode |= PNG_HAVE_CHUNK_HEADER;
}
I'm obviously not understanding something I'm evaluation here. So
I'm wondering if anyone can shed light on this.
http://www.nylxs.com/docs/grad_school/parallel/src/png/png_proj.h
http://www.nylxs.com/docs/grad_school/parallel/src/png/png_proj.cpp
http://www.nylxs.com/docs/grad_school/parallel/src/png/main_png.cpp
http://www.nylxs.com/docs/grad_school/parallel/src/png/makefile
ruben
let.me.in
Ruben _______________________________________________ Learn mailing
list Learn-at-nylxs.com
http://lists.mrbrklyn.com/mailman/listinfo/learn
References
1. mailto:league-at-contrapunctus.net
2. mailto:ruben-at-mrbrklyn.com
--==-=-=--
--===-=-=
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEE3x0LN7z09c1wuX58a4uzPU8xsIsFAlhGzAgACgkQa4uzPU8x
sIumxAgAjJOgm8j+3VdoDoi7Q+KWPaE5CijBrzENzLvdnwhYvLPESotsk/s8o6b6
RKL2TDTDPNtT2ioyEKbtRYseHQYJofXpWYMFCemFfDzNuWawXCalWTTlJ7MvbZ3w
+JuCJP4kSeW6Fz5KONKz26se+taARS5KHWUoLQ5nBLVbC9mq8T2jGgmwVjE85Yo9
0uidmL5KaitsSeQYp1r9uRImr/DPVK/YXOLHWa5bVmjcUDFMvhnFQNZ1aoHE/YG2
rJk+/oFWz1ZFvTJkrtzAW2FtQL+cFG6jCzCXK7Qk8UFx13IZT9+l2/t4K7lc0LcO
joMC0klXtdrC857JNPmsMs7m7N7MtQ==
=QhWr
-----END PGP SIGNATURE-----
--===-=-=--
--===============0873416613==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
hangout mailing list
hangout-at-nylxs.com
http://www.nylxs.com/
--===============0873416613==--
|
|
