On Mon, Jul 28, 2014 at 6:55 PM, FRIGN d...@frign.de wrote:
Hello,
after literally dozens of mails discussing a new suckless image-format,
I sat down last week to reflect on what could be the best of all
proposed format-specifications.
As a result I came up with the first implementation,
On Tue, 12 Aug 2014 09:43:42 +0200
Jordi Marine jordimar...@gmail.com wrote:
Is not the same as implementing a subset of PAM [1] ?
PAM is too complex and tries to offer separate modes for grayscale,
color and transparent.
imagefile always stores in 24 bit RGBA. In case an image is grayscale,
Here's an SDL loader for imagefile. If you are familiar with SDL_image's
syntax, you shouldn't have any problems.
SDL_Surface *IF_Load(char *name);
Returns an SDL surface made from an imagefile on the hard drive.
SDL_Surface *IF_Load_RW(SDL_RWops *ctx);
Returns an SDL_Surface
Charlie Murphy wrote:
Here's an SDL loader for imagefile. If you are familiar with SDL_image's
syntax, you shouldn't have any problems.
IF_Load_RW() has an incorrect line.
, needs to be 16
v
h =
On Fri, 8 Aug 2014 15:59:19 -0400
Charlie Murphy cmsmur...@gmail.com wrote:
IF_Load_RW() has an incorrect line.
, needs to be 16
v
h = (hdr[13]24) | (hdr[14]17) | (hdr[15]8) | hdr[16];
Attached is the
On Fri, Aug 08, 2014 at 03:59:19PM -0400, Charlie Murphy wrote:
Charlie Murphy wrote:
Here's an SDL loader for imagefile. If you are familiar with SDL_image's
syntax, you shouldn't have any problems.
very nice!
We also now have jpg2if[0] and gif2if[1] in the if-tools repo.
[0] http://git.2f30.org/imagefile/tree/jpg2if.c
[1] http://git.2f30.org/imagefile/tree/gif2if.c
On Thu, 31 Jul 2014 18:14:36 +0100
Dimitris Papastamos s...@2f30.org wrote:
We also now have jpg2if[0] and gif2if[1] in the if-tools repo.
[0] http://git.2f30.org/imagefile/tree/jpg2if.c
[1] http://git.2f30.org/imagefile/tree/gif2if.c
Thanks man! It's always better having a native solution
Louis Santillan wrote:
I know you're going for portability, but pulling in arpa/inet.h doesn't seem
so suckless.
Heyho Louis,
how would you handle different endianess in a simpler way than just using a
POSIX standard library function? Have you read the recent CEIL macro discussion?
The
On Tue, Jul 29, 2014 at 1:37 AM, Staven pvl.sta...@gmail.com wrote:
width = (hdr[9] 24) | (hdr[10] 16) | (hdr[11] 8) | hdr[12]
height = (hdr[13] 24) | (hdr[14] 16) | (hdr[15] 8) | hdr[16]
To reiterate this, each of these parenthesized expressions is in
native byte order
On Tue, Jul 29, 2014 at 12:17 PM, Martti Kühne mysat...@gmail.com wrote:
and ntohl/htonl would only have any impact if we bit off the whole
word in one byte. Pleasee don't make a mess with both of these
..in one bite. Damn.
cheers!
mar77i
The selection of bzip as the compression algorithm seems like a
compromise.
It seems to me part of the whole point is to *not* select a compression
algorithm, but allow that to be handled by the apropriate tools (probably
xz, in my case).
Hello,
after literally dozens of mails discussing a new suckless image-format,
I sat down last week to reflect on what could be the best of all
proposed format-specifications.
As a result I came up with the first implementation, the if-tools[0],
capable of easily converting between png and
FRIGN dixit:
Hello,
after literally dozens of mails discussing a new suckless image-format,
I sat down last week to reflect on what could be the best of all
proposed format-specifications.
Awesome. Thanks to everyone who contributed.
On Mon, Jul 28, 2014 at 06:55:59PM +0200, FRIGN wrote:
As a result I came up with the first implementation, the if-tools[0],
capable of easily converting between png and imagefiles.
Looks great! This would make a lot of image handling, automation and
editing operations much easier and simple.
On Mon, 28 Jul 2014 17:40:20 -0400
Lee Fallat ircsurfe...@gmail.com wrote:
Why was the specification in the header idea ditched? Just curious.
I think the current format is quite nice :)
I'm glad you like it!
Concerning the idea of specification in the header, I literally spent
half a day
On 2014-07-28 18:55:59, somebody claiming to be FRIGN d...@frign.de wrote:
4) USING THE IMAGEFILE-TOOLS
The imagefile[0]-tools provide a way to convert between png and if using
pipes.
4.1) Trivial conversions
$ png2if image.png image.if
$ if2png image.if
On Mon, Jul 28, 2014 at 6:55 PM, FRIGN d...@frign.de wrote:
fread(hdr, 1, 17, fd);
width = ntohl((hdr[9] 0) | (hdr[10] 8) | (hdr[11] 16) |
(hdr[12] 24));
height = ntohl((hdr[13] 0) | (hdr[14] 8) | (hdr[15] 16) |
(hdr[16] 24));
Isn't ntohl superfluous here?
On Tue, 29 Jul 2014 00:43:20 +0200
Robert Hülle robert.hu...@gmail.com wrote:
Possible problem with grayscale PNGs in png2if. I get bytes 00 ff 00
ff for black pixel when it should be 00 00 00 ff.
At first I thought, this couldn't be, as I set PNG_TRANSFORM_EXPAND in
png_read_png, but after
On Tue, 29 Jul 2014 01:37:30 +0200
Staven pvl.sta...@gmail.com wrote:
Isn't ntohl superfluous here? In fact, wouldn't this break on a big-endian
architecture? If I'm reading this right, we're storing the value in memory in
reverse (of native) byte order, assume it's now big-endian and convert
On Tue, Jul 29, 2014 at 1:59 AM, FRIGN d...@frign.de wrote:
Be careful: the n in ntohl does not stand for native, but network.
More or less by convention, the Network Byte Order today is BE. What
ntohl makes sure is that in case we are on a LE-system, it's arranged
properly.
ntohl is only
FRIGN writes:
The only reason I used ntohl() and htonl() here is
the fact they're POSIX, and endian.h isn't.
Isn't yet... http://austingroupbugs.net/view.php?id=162
--
Anthony J. Bentley
I know you're going for portability, but pulling in arpa/inet.h
doesn't seem so suckless.
The selection of bzip as the compression algorithm seems like a
compromise. suckless flate[0], lzham[1], miniz[2], lz4/lz4hc[3],
minilzo[4], fastlz[5] maybe deserve some consideration? flate, miniz,
lz4,
23 matches
Mail list logo
