On Fri, 2014-07-18 at 20:57 +0200, FRIGN wrote:
> On Fri, 18 Jul 2014 13:45:50 -0500
> Samuel Holland wrote:
>
> > Then put it after the magic string. And they don't have to be
> > characters; they can be one-byte integers, which would be better
> > anyway. My point is that the format shouldn't b
On Fri, 18 Jul 2014 13:45:50 -0500
Samuel Holland wrote:
> Then put it after the magic string. And they don't have to be
> characters; they can be one-byte integers, which would be better
> anyway. My point is that the format shouldn't be limited to just ,
> especially if you're concerned wit
On Fri, 2014-07-18 at 20:32 +0200, koneu wrote:
> On 07/18/2014 08:28 PM, Samuel Holland wrote:
> > I think it would be slightly more useful to put the number of bits
> > per channel in the header instead of the string "rgba". It would allow
> > more freedom in reducing the file size when color d
On Fri, Jul 18, 2014 at 01:45:08PM -0400, Lee Fallat wrote:
> On Fri, Jul 18, 2014 at 1:41 PM, Truls Becken wrote:
> > On Fri, Jul 18, 2014 at 7:15 PM, Charlie Murphy wrote:
> > How about putting the widthxheight in the file name and having RGBA
> > data only inside? Would that result in the best
On 07/18/2014 08:28 PM, Samuel Holland wrote:
I think it would be slightly more useful to put the number of bits
> per channel in the header instead of the string "rgba". It would allow
> more freedom in reducing the file size when color depth isn't very
> important. For example, you could do 56
On Jul 18, 2014, at 1:10 PM, FRIGN wrote:
> I'd rather put it this way:
>
> BytesDescription
> 13ASCII string: "img13w4h4rgba"
> 432 bit Big-Endian integer for width
> 432 bit Big-Endian integer for height
> (w*h)Raw RGBA.
I think it would be slightly more useful to put the n
On Fri, 18 Jul 2014 13:56:31 -0400
Charlie Murphy wrote:
> Perhaps it can have an option, like tar does?
>
> tar -cjf archive.tar.bz2 archive
>
> imagergba -j ponies.png ponies.image.bz2
I like this idea!
--
FRIGN
On Fri, 18 Jul 2014 13:44:20 -0400
Charlie Murphy wrote:
> Bytes Description
> 13ASCII string: "img13w7h7rgba"
> 7 Right-justified, space-padded ASCII string containing width.
> 7 Right-justified, space-padded ASCII string containing height.
> (w*h) Raw RGBA.
I still don't like the i
On Fri, Jul 18, 2014 at 1:56 PM, Charlie Murphy wrote:
> FRIGN wrote:
>> But it would be cool if the user wouldn't have to manage this and
>> instead was able to rely on any converter to take care of this.
>
> Perhaps it can have an option, like tar does?
>
> tar -cjf archive.tar.bz2 archi
FRIGN wrote:
> But it would be cool if the user wouldn't have to manage this and
> instead was able to rely on any converter to take care of this.
Perhaps it can have an option, like tar does?
tar -cjf archive.tar.bz2 archive
imagergba -j ponies.png ponies.image.bz2
Charlie Murp
Charlie Murphy wrote:
> Branding such a general format would be unjust, IMO. I like having the
s/general/simple/
Köhring, Norman wrote:
> them? Also, regarding the magic number: Image is a very common description. We
> could also think about words like “picture” (or “pic”) or use some
> abbreviation
> of “simple image format”: SIF or SIMG?
Branding such a general format would be unjust, IMO. I like having
On Fri, Jul 18, 2014 at 1:41 PM, Truls Becken wrote:
> On Fri, Jul 18, 2014 at 7:15 PM, Charlie Murphy wrote:
>
>> Interesting. How could a header change the compression so much?
>
> How about putting the widthxheight in the file name and having RGBA
> data only inside? Would that result in the
On Fri, Jul 18, 2014 at 7:15 PM, Charlie Murphy wrote:
> Interesting. How could a header change the compression so much?
How about putting the widthxheight in the file name and having RGBA
data only inside? Would that result in the best possible compression?
Or have a header, but compress the d
On 07/18/2014 10:45 PM, Charlie Murphy wrote:
>
> Interesting. How could a header change the compression so much?
>
http://en.wiktionary.org/wiki/Shannon_entropy
Ideal compression is based on a known PMF. Actual compression is based
on a heuristic PMF. A header changes that heuristic PMF, some
On Fri, 18 Jul 2014 13:15:31 -0400
Charlie Murphy wrote:
> Compression of images should be up to the user. I understand why
> one would want compression in the spec, but it only makes sense in
> contexts like hard-disk storage or network transfer. The user also
> doesn't need the spec's permiss
On July 18, 2014 7:59:26 PM EEST, Hiltjo Posthuma
wrote:
>On Fri, Jul 18, 2014 at 4:33 PM, Dimitris Zervas
>wrote:
>> On July 18, 2014 2:00:41 PM EEST, Hiltjo Posthuma
> wrote:
>>
>> We (rafael & me) have no access to the sl repo, so we'll apply the
>patch at bitbucket: http://bitbucket.org/rafa
On 07/18/2014 10:27 PM, Weldon Goree wrote:
> On 07/18/2014 06:46 PM, Zack Breckenridge wrote:
>>
\>>
>> Of course you never know... Is it possible to make severity and
>> facility unsigned integers?
>>
>
> It comes over the wire as an ASCII char which is by contract between 0
> and 7
I should ad
On Fri, Jul 18, 2014 at 4:33 PM, Dimitris Zervas wrote:
> On July 18, 2014 2:00:41 PM EEST, Hiltjo Posthuma
> wrote:
>
> We (rafael & me) have no access to the sl repo, so we'll apply the patch at
> bitbucket: http://bitbucket.org/rafaelgg/sandy
Ah cool stuff. Any chance of the development con
On 07/18/2014 06:46 PM, Zack Breckenridge wrote:
>
> Regarding line 91-92 of logwd.c:
>
>> if ((severity > 7) || (severity < 0)) { severity = 8; }
>> /* Sue me. I'm paranoid. I'm aware of how this "can't happen"... */
>
> Of course you never know... Is it possible to make severity and
> facilit
On July 18, 2014 2:00:41 PM EEST, Hiltjo Posthuma
wrote:
>Attached is a patch that fixes a crash with musl.
>
>Commit message:
>
>"f_syntax: set regexec nmatch to 0.
>
>this is correct according to POSIX with REG_NOSUB, but it doesn't make
>much sense to set to > 0 when pmatch is NULL and will cr
Weldon,
I think this is pretty interesting, though I'd have to compare some
other implementations of syslogd to actually be able to tell you what
functionality is missing that I "can't live without". The code is nice
and short though.
> ... It currently uses
> daemon(3) to detach, but I'm open to
On Fri, Jul 18, 2014 at 2:19 PM, Martti Kühne wrote:
> webservice from where you could download the image decoding code. The
> same thing is done with gpg keys already, so we could integrate gpg
> keyservers into the whole process...
>
Business idea: Let's sell "closed" formats on those servers,
On Fri, Jul 18, 2014 at 2:15 PM, Martti Kühne wrote:
> On Fri, Jul 18, 2014 at 2:14 PM, FRIGN wrote:
>> On Fri, 18 Jul 2014 14:04:17 +0200 (CEST)
>> "Köhring, Norman" wrote:
>>
>>> I thought we already skipped the intermediate bytes? Is there any worth
>>> having
>>> them?
>>
>> No. I assumed w
On Fri, 18 Jul 2014 14:15:28 +0200
Martti Kühne wrote:
> Let's just disagree. Let's build a meta image framework in python that
> creates the format code you like.
Haha, let's wait for Saturday when I actually go time to discuss this
with you ;).
--
FRIGN
On Fri, Jul 18, 2014 at 2:14 PM, FRIGN wrote:
> On Fri, 18 Jul 2014 14:04:17 +0200 (CEST)
> "Köhring, Norman" wrote:
>
>> I thought we already skipped the intermediate bytes? Is there any worth
>> having
>> them?
>
> No. I assumed we also already ditched the ASCII-approach and went for
> binary-
On Fri, 18 Jul 2014 14:04:17 +0200 (CEST)
"Köhring, Norman" wrote:
> I thought we already skipped the intermediate bytes? Is there any worth having
> them?
No. I assumed we also already ditched the ASCII-approach and went for
binary-16 or 32-bit-BE-integers
> Also, regarding the magic number: I
On Fri, Jul 18, 2014 at 2:04 PM, "Köhring, Norman" wrote:
> I thought we already skipped the intermediate bytes? Is there any worth having
> them? Also, regarding the magic number: Image is a very common description. We
> could also think about words like “picture” (or “pic”) or use some
> abbrev
I thought we already skipped the intermediate bytes? Is there any worth having
them? Also, regarding the magic number: Image is a very common description. We
could also think about words like “picture” (or “pic”) or use some abbreviation
of “simple image format”: SIF or SIMG?
The format could look
Hi all,
So, I got tired of trying to make sysklogd play nice with musl, and I
built this[0].
It probably needs work, but I thought I would request comments. It's the
syslog for my toy/personal obsession distro. I think it adheres to the
suckless philosophy pretty well. It opens a UNIX socket at /
Attached is a patch that fixes a crash with musl.
Commit message:
"f_syntax: set regexec nmatch to 0.
this is correct according to POSIX with REG_NOSUB, but it doesn't make
much sense to set to > 0 when pmatch is NULL and will crash on musl"
I reported this to the musl project and a fix is comm
On Thu, 17 Jul 2014 17:03:11 -0400
Charlie Murphy wrote:
> That compression is due to bzip2. Like a compressed text file, there's
> nothing special about the underlying image format.
Sure it was! :D
But you can't just compress a png-file (As I noted later on).
If you compress an equivalent bmp
32 matches
Mail list logo
