On Tue, 12 Aug 2014 09:43:42 +0200
Jordi Marine 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,
the bzip2-compression d
On Mon, Jul 28, 2014 at 6:55 PM, FRIGN 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, the if-to
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!
On Fri, 8 Aug 2014 15:59:19 -0400
Charlie Murphy 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 fixed lib
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 = (hdr[1
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 mad
On Thu, 31 Jul 2014 18:14:36 +0100
Dimitris Papastamos 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 than havin
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
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).
On Tue, Jul 29, 2014 at 12:17 PM, Martti Kühne 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
On Tue, Jul 29, 2014 at 1:37 AM, Staven 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 *already
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 sel
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, mi
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
FRIGN wrote:
> Bytes Description
> 9 "imagefile"
> 4 32-bit BE - width
> 4 32-bit BE - height
> [] RGBA
Hello!
I changed my mind and agree that using 32-bit integers is better than using
ASCII strings.
> Porting the xscreenshot-tool to imagefile cut almost half the LOC a
On Tue, Jul 29, 2014 at 1:59 AM, FRIGN 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 superfluous
On Tue, 29 Jul 2014 01:37:30 +0200
Staven 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 it to
> native byt
On Tue, 29 Jul 2014 00:43:20 +0200
Robert Hülle 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 some research, I fo
On Mon, Jul 28, 2014 at 6:55 PM, FRIGN 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
On 2014-07-28 18:55:59, somebody claiming to be FRIGN 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 > im
On Mon, 28 Jul 2014 17:40:20 -0400
Lee Fallat 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 making up my mind on
On Mon, Jul 28, 2014 at 12:55 PM, FRIGN wrote:
>
> ...
>
> Bytes Description
> 9 "imagefile"
> 4 32-bit BE - width
> 4 32-bit BE - height
> [] RGBA
>
> ...
>
> FRIGN
Why was the "specification in the header" idea ditched? Just curious.
I think the current format is quite
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.
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.
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 imagefi
25 matches
Mail list logo
