MESSAGE
| DATE | 2016-12-08 |
| FROM | ruben safir
|
| SUBJECT | Subject: [Learn] Fwd: Re: png data format
|
From learn-bounces-at-nylxs.com Thu Dec 8 21:52:49 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 7AA4D161312;
Thu, 8 Dec 2016 21:52:49 -0500 (EST)
X-Original-To: learn-at-nylxs.com
Delivered-To: learn-at-nylxs.com
Received: from [10.0.0.62] (flatbush.mrbrklyn.com [10.0.0.62])
by mrbrklyn.com (Postfix) with ESMTP id 2CF90160E77
for ; Thu, 8 Dec 2016 21:52:47 -0500 (EST)
References:
To: learn-at-nylxs.com
From: ruben safir
X-Forwarded-Message-Id:
Message-ID:
Date: Thu, 8 Dec 2016 21:52:47 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
Thunderbird/45.5.0
MIME-Version: 1.0
In-Reply-To:
Subject: [Learn] Fwd: Re: 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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: learn-bounces-at-nylxs.com
Sender: "Learn"
-------- Forwarded Message --------
Subject: Re: png data format
Date: Thu, 8 Dec 2016 12:24:42 -0600
From: BGB
Organization: albasani.net
Newsgroups: comp.lang.c++
References:
On 12/8/2016 5:41 AM, Jorgen Grahn wrote:
> On Wed, 2016-12-07, David Brown wrote:
>> On 07/12/16 14:35, Scott Lurndal wrote:
>>> Jorgen Grahn writes:
>>>> On Tue, 2016-12-06, ruben safir wrote:
>>>>> On 12/06/2016 03:41 PM, David Brown wrote:
>>>>>> x86 uses little endian format, so 13 is stored as 0b 00 00 00 as a
>>>>>> 32-bit integer. PNG, like many network-related formats, uses big
>>>>>> endian. So it stores 32-bit 13 as 00 00 00 0b. (Incidentally, use hex
>>>>>> for this sort of thing - octal had no place in computing outside of
>>>>>> "chmod" since the 1970's.)
>>>>>>
>>>>>> Assuming you are trying to learn and understand this, rather than
>>>>>> copy-and-paste working code, then this should be enough to get you going.
>>>>>
>>>>>
>>>>> thanks, excellent. What I don't understand though is why when I set up
>>>>> a loop and take it by the byte that the order is correct. It gets 00 00
>>>>> 00 and then 0d
>>>>
>>>> I can't answer that, and I didn't read the code. However, treating
>>>> the file as a series of bytes /is/ the right thing to do, so it
>>>> doesn't surprise me if the result is correct. If the file looks like
>>>>
>>>> f0 0d 12 34 00 00 00 0d 47 11
>>>> -----------
>>>>
>>>> and the file format specification says "we store an integer in
>>>> big-endian form in the marked area", I'd read it using a function
>>>> similar to this one:
>>>>
>>>> static unsigned get_bigendian32(const uint8_t* p)
>>>> {
>>>> unsigned n = 0;
>>>> n = (n<<8) | *p++;
>>>> n = (n<<8) | *p++;
>>>> n = (n<<8) | *p++;
>>>> n = (n<<8) | *p++;
>>>> return n;
>>>> }
>>>>
>>>> (You also have to watch out for buffer overflows.)
>>>
>>> I'd read it as a 32-bit int
>>
>> That /might/ be acceptable, assuming you have control of aligned or
>> unaligned accesses, as well as aliasing issues.
>>
>>> then byteswap it:
>
> Here he also has to know he's on a little-endian machine, and with
> certain compilers. IMO, a high price to pay to avoid byte-level
> reads.
>
> There is ntohl() if you're on Unix.
>
it also exists on Windows if using Winsock.
though, it is not as good, as it is a function call into a DLL, so
faster options are possible.
>>> static inline uint32
>>> swap32(uint32 value)
>>> {
>>> __asm__ __volatile__ ("bswap %0": "=a"(value): "0"(value));
>>> return value;
>>> }
>>>
>>> or
>>>
>>> static inline uint32
>>> swap32(uint32 value)
>>> {
>>> return __builtin_bswap32(value);
>>> }
>>>
>>
>> That's okay when you have something working and are looking for greater
>> optimisation - or if you are familiar enough with the endianness issues
>> that you are happy to jump straight to an endianness swap routine. But
>> one step at a time is best until the OP is confident in what he is doing
>> here.
>
those are not exactly portable options though.
also possible could be:
uint32 bswap32(uint32 v0)
{
uint32 v1, v2;
v1=((v0&0xFF00FF00U)>> 8)|((v0&0x00FF00FFU)<< 8);
v2=((v1&0xFFFF0000U)>>16)|((v1&0x0000FFFFU)<<16);
return(v2);
}
with more specialized options based on combination of arch and compiler.
> Yes. Part of the point with my get_bigendian32() above is that it
> shows[0] that there /are/ no 32-bit integers in binary files, not in
> the C++ sense. There are just bytes, and your code is responsible for
> the conversion (according to the rules set by whoever created the file
> format).
>
yep.
file formats get fun, endianess is variable, non-power-of-2 integer
sizes are common, bitstreams are also common (with multiple variations
thereof), ...
wrote various stuff about having multiple variations of an LZ compressed
bitstream format intended for large numbers of small buffers (where
minimizing constant factors becomes a bigger issue), but decided to
leave this out as it drifts a bit far from the topic at hand.
but, yes, entropy coded bitstreams are also fun...
_______________________________________________
Learn mailing list
Learn-at-nylxs.com
http://lists.mrbrklyn.com/mailman/listinfo/learn
|
|
