MESSAGE
| DATE | 2016-12-06 |
| FROM | Christopher League
|
| SUBJECT | Re: [Learn] png data format
|
From learn-bounces-at-nylxs.com Tue Dec 6 09:56:29 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 5B4AF161312;
Tue, 6 Dec 2016 09:56:29 -0500 (EST)
X-Original-To: learn-at-nylxs.com
Delivered-To: learn-at-nylxs.com
Received: from liucs.net (contrapunctus.net [174.136.110.10])
by mrbrklyn.com (Postfix) with ESMTP id 2A68C161311;
Tue, 6 Dec 2016 09:56:25 -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 0E65DE096;
Tue, 6 Dec 2016 09:56:23 -0500 (EST)
From: Christopher League
To: Ruben Safir , Hangout ,
learn-at-nylxs.com
In-Reply-To: <86dabb9c-361b-354b-1d44-1f4593cc70eb-at-mrbrklyn.com>
References: <66105244-4afa-4330-b0c2-0661bde965fd-at-mrbrklyn.com>
<87bmwpf857.fsf-at-contrapunctus.net> <878trtf7qw.fsf-at-contrapunctus.net>
<86dabb9c-361b-354b-1d44-1f4593cc70eb-at-mrbrklyn.com>
User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/25.1.1
(x86_64-unknown-linux-gnu)
Date: Tue, 06 Dec 2016 09:56:22 -0500
Message-ID: <871sxlf6nd.fsf-at-contrapunctus.net>
MIME-Version: 1.0
Subject: Re: [Learn] png data format
X-BeenThere: learn-at-nylxs.com
X-Mailman-Version: 2.1.17
Precedence: list
List-Id:
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
Content-Type: multipart/mixed; boundary="===============0932736509=="
Errors-To: learn-bounces-at-nylxs.com
Sender: "Learn"
--===============0932736509==
Content-Type: multipart/alternative; boundary="=-=-="
--=-=-=
Content-Type: text/plain
Ruben Safir writes:
> damn
>
> so your saying that the bytes are being stored left to right and the
> array is right to left?
>
> hexdup corrects the order of them automatically by itself?
Yeah, something like that. That's why the commands `hexdump` and `od`
have options that tell them whether to interpret as *individual* bytes,
or 16-bit words, or 32-bit words, etc. I'm more familiar with the
options of `od` than `hexdump`, so compare these:
% echo -n '\000\000\000\015'|od -t x1u1
0000000 00 00 00 0d
0 0 0 13
% echo -n '\000\000\000\015'|od -t x2u2
0000000 0000 0d00
0 3328
% echo -n '\000\000\000\015'|od -t x4u4
0000000 0d000000
218103808
% echo -n '\000\000\000\015'|od --endian=big -t x4u4
0000000 0000000d
13
CL
--=-=-=
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
1.0, user-scalable=3Dyes">
Ruben Safir ruben-at-mrbrklyn.com=
writes:
damn
so your saying that the bytes are being stored left to right and the arr=
ay is right to left?
hexdup corrects the order of them automatically by itself?
Yeah, something like that. That=E2=80=99s why the commands hexdump=
and od have options that tell them whether to interpre=
t as individual bytes, or 16-bit words, or 32-bit words, etc. I=E2=
=80=99m more familiar with the options of od than hexdum=
p, so compare these:
% echo -n '\000\000\000\015'|od -t x1u1
0000000 00 00 00 0d
0 0 0 13
% echo -n '\000\000\000\015'|od -t x2u2
0000000 0000 0d00
0 3328
% echo -n '\000\000\000\015'|od -t x4u4
0000000 0d000000
218103808
% echo -n '\000\000\000\015'|od --endian=3Dbig -t x4u4
0000000 0000000d
13
CL
--=-=-=--
--===============0932736509==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Learn mailing list
Learn-at-nylxs.com
http://lists.mrbrklyn.com/mailman/listinfo/learn
--===============0932736509==--
|
|
