FRIGN wrote:
> The writing-function is rather trivial.
> Now, what puzzles me is why no explanation is given on how the data
> itself should be stored. It says RGBA, so I suppose he meant
Thanks for the feedback. The header is strict to avoid complex text
handling. I have attached a script to co
Heyho,
Charlie Murphy wrote:
> The X axis runs fastest.
You did not introduce the directions of x and y axis previously.
> len = *w * *h * 4;
For readability I would leave the brackets.
len = (*w) * (*h) * 4;
> data = malloc(len);
> if (!data)
On Wed, 16 Jul 2014 12:00:42 +0200
Markus Teich wrote:
> You can combine these, since free(NULL) does nothing.
>
> if (!(data = malloc(len)) || read(fd, data, len) != len) {
> free(data);
> return NULL;
> }
Cf. my version ;)
I love idiomatic C-code :D.
C
On Tue, 15 Jul 2014 20:40:08 +0200
Markus Teich wrote:
> I hope this explains my issue.
The definition is ambiguous and I start to get the impression the guy
who defined this format had a naive view on what a "blank" is:
Just a normal whitepace (0x20), as you already suspected.
We now have two
On Wed, Jul 16, 2014 at 2:02 PM, FRIGN wrote:
> Why not do it like this:
>
> 9 "imagefile"
> 1 0x20
> var width
> 1 0x20
> var height
> 1 0x00
>
> and work with it like this:
>
Yes. I had that in mind as well.
On July 16, 2014 2:02:27 PM CEST, FRIGN wrote:
>On Tue, 15 Jul 2014 20:40:08 +0200
>Markus Teich wrote:
>
>> I hope this explains my issue.
>
>The definition is ambiguous and I start to get the impression the guy
>who defined this format had a naive view on what a "blank" is:
>Just a normal white
On Wed, 16 Jul 2014 14:24:04 +0200
koneu wrote:
> Pathetic. Why would you do that to save at most 16 bytes?
> Reasons against it:
> 0. This implementation is way cooler.
Great point.
> 1. Storage is cheap.
CPU-cycles are cheap. Memory is cheap. Network is cheap, ...
Still, neglecting these ar
why not just binary
uint32 width (BIG_ENDIAN)
uint32 height (BIG_ENDIAN)
uint32 pixel(s) (BIG_ENDIAN)
with uint64 length of pixels = width * height;
If you need ascii, just dump it to some hex or base64 converter and good is...
-Anselm
FRIGN wrote:
> Another thing that bugs me is the inflexiblity of the width and
> height-definition. 99% of all images have at most coordinates < , which
> means that you waste 10 bytes of image size on 99% of all images, because
> every number is zero-padded.
>
> This implementation allows arb
On Wed, 16 Jul 2014 14:16:30 +0200
Martti Kühne wrote:
> Yes. I had that in mind as well.
Writing a parser in C is inarguably more complex, however, I think the
priority is keeping the format as simple as possible, but not simpler.
We need to set our priorities well enough: How often do you read
koneu wrote:
> If anything, I would store the numbers as unsigned 64 bit LSB and change the
> read/write functions for MSB architectures.
Heyho,
max(uint32_t) = 4.294.967.296 is already way more than the proposed max of
999.999.999. I would even suggest uint16_t is enough. To store images larger
On July 16, 2014 3:28:44 PM CEST, Markus Teich
wrote:
>koneu wrote:
>> If anything, I would store the numbers as unsigned 64 bit LSB and
>change the
>> read/write functions for MSB architectures.
>
>Heyho,
>
>max(uint32_t) = 4.294.967.296 is already way more than the proposed max
>of
>999.999.999
On Wed, 16 Jul 2014 14:51:32 +0200
Anselm R Garbe wrote:
> why not just binary
>
> uint32 width (BIG_ENDIAN)
> uint32 height (BIG_ENDIAN)
> uint32 pixel(s) (BIG_ENDIAN)
>
> with uint64 length of pixels = width * height;
>
> If you need ascii, just dump it to some hex or base64 converter and go
On Wed, 16 Jul 2014 15:51:07 +0200
FRIGN wrote:
> This is very similar to Markus Teich' approach, but be32toh is much
> more favorable than ntohs, because it's clear we are converting from
> big endian.
But, to be fair, ntohs is POSIX and the be_nn_toh-family isn't.
Let's go for the former ;).
FRIGN wrote:
> Now, what's left to discuss if we should use uint32 or uint16.
Heyho,
as I've said already, I see no use case for an image greater than 65536 pixels
in any dimension when I am stuck with 8bit per channel.
--Markus
koneu wrote:
> On July 16, 2014 3:28:44 PM CEST, Markus Teich
> wrote:
> > *w = ntohs(hdr[9]);
> > *h = ntohs(hdr[11]);
>
> This will pass a char to ntohs; expanding it to a uint16_t, instead of passing
> ntohs two bytes from the header.
Heyho,
of course you are right.
Neither the endianness nor the maximum width is in question for
space-separated human readable, variable width numbers.
On July 16, 2014 4:05:52 PM CEST, "Martti Kühne" wrote:
>Neither the endianness nor the maximum width is in question for
>space-separated human readable, variable width numbers.
Then again, who wants a human readable header? Could aswell save the image in
ASCII art then.
On July 16, 2014 4:09:03 PM CEST, Markus Teich
wrote:
>koneu wrote:
>> On July 16, 2014 3:28:44 PM CEST, Markus Teich
> wrote:
>> >*w = ntohs(hdr[9]);
>> >*h = ntohs(hdr[11]);
>>
>> This will pass a char to ntohs; expanding it to a uint16_t, instead
>of passing
>> ntohs t
Charlie Murphy wrote:
> Is there an image format that's simpler than PPM and that supports
> alpha transparency? PPM's syntax is too flexible; to parse an image
> you have to skip arbitrary whitespace in the header. You can't
> simply read() it.
Martti Kühne wrote:
> Neither the endianness nor t
I'm with koneu on this one- why make it human readable?
I don't think you need to store the height either- just the width.
Then just read until EOF and the height will be implicit.
Honestly I'm surprised the header is just not [width] and nothing
else. Sure, if the file ever gets lost in deletion
Quoth Markus Teich:
> First it would be inconsistent to allow for variable sized width and height
> field lengths, but force the usage of 8 bit per color channel per pixel.
So, um, why aren't you considering variable colour depth? It's a
small complexity cost, but it increases the flexibility
c
On Wed, Jul 16, 2014 at 10:33 AM, FRIGN wrote:
> On Wed, 16 Jul 2014 10:16:17 -0400
> Lee Fallat wrote:
>
>> I'm with koneu on this one- why make it human readable?
>>
>> I don't think you need to store the height either- just the width.
>> Then just read until EOF and the height will be implicit
On Wed, 16 Jul 2014 10:16:17 -0400
Lee Fallat wrote:
> I'm with koneu on this one- why make it human readable?
>
> I don't think you need to store the height either- just the width.
> Then just read until EOF and the height will be implicit.
Well, how would we know how large the buffer should b
On Wed, Jul 16, 2014 at 10:36 AM, Lee Fallat wrote:
> On Wed, Jul 16, 2014 at 10:33 AM, FRIGN wrote:
>> On Wed, 16 Jul 2014 10:16:17 -0400
>> Lee Fallat wrote:
>>> Honestly I'm surprised the header is just not [width] and nothing
>>> else. Sure, if the file ever gets lost in deletion space it'll
Lee Fallat wrote:
> fseek(filehandle, 0, SEEK_END);
> height = (ftell(filehandle) / RGBA_CHANNEL_SIZE) / width;
>
> Then you allocate your buffer.
Heyho Lee,
This needs FILE* instead of just a file descriptor, making usage in pipes
intractable.
--Markus
On Wed, Jul 16, 2014 at 11:05 AM, Markus Teich
wrote:
> Lee Fallat wrote:
>> fseek(filehandle, 0, SEEK_END);
>> height = (ftell(filehandle) / RGBA_CHANNEL_SIZE) / width;
>>
>> Then you allocate your buffer.
>
> Heyho Lee,
>
> This needs FILE* instead of just a file descriptor, making usage in pipe
On Wed, 16 Jul 2014 10:53:37 -0400
Lee Fallat wrote:
> To answer my own question- because in 20 years from now people won't
> know the format of the image files. So I vote for calling this image
> format, internally in the header: "thecharliemurphy", because why not?
> It's a pretty unique image
On July 16, 2014 5:05:01 PM CEST, Markus Teich
wrote:
>Lee Fallat wrote:
>> fseek(filehandle, 0, SEEK_END);
>> height = (ftell(filehandle) / RGBA_CHANNEL_SIZE) / width;
>>
>> Then you allocate your buffer.
>
>Heyho Lee,
>
>This needs FILE* instead of just a file descriptor, making usage in
>pipe
On Wed, 16 Jul 2014 10:30:32 -0400
Nick wrote:
> So, um, why aren't you considering variable colour depth? It's a
> small complexity cost, but it increases the flexibility
> considerably.
The issue with this is that the used color-depth needs to be specified
in the header.
24 bit is close to f
FRIGN wrote:
> Or give a hint on the format:
>
> img16widhei8rgba
Heyho,
in this case we could also just include the whole specification as magic string,
then it should be comprehensible for everyone ever stumbling upon such a file.
--Markus
On Wed, Jul 16, 2014 at 11:21 AM, Markus Teich
wrote:
> FRIGN wrote:
>> Or give a hint on the format:
>>
>> img16widhei8rgba
>
> Heyho,
>
> in this case we could also just include the whole specification as magic
> string,
> then it should be comprehensible for everyone ever stumbling upon such a
FRIGN wrote:
> 24 bit is close to full color, however, I didn't find an exact definition of
> full color anywhere. Do you need floating point numbers to get there?
Heyho,
I don't think floats will help our cause at all. This would just use more space
(at least I haven't seen a usable 8bit floati
On Wed, 16 Jul 2014 17:38:21 +0200
Markus Teich wrote:
> I don't think floats will help our cause at all. This would just use more
> space
> (at least I haven't seen a usable 8bit floating point specification yet) and
> we
> would probably use less of the values range. In floating point represe
On Wed, Jul 16, 2014 at 11:45 AM, FRIGN wrote:
> On Wed, 16 Jul 2014 17:38:21 +0200
> Markus Teich wrote:
>
>> I don't think floats will help our cause at all. This would just use more
>> space
>> (at least I haven't seen a usable 8bit floating point specification yet) and
>> we
>> would probab
On July 16, 2014 5:46:25 PM CEST, Lee Fallat wrote:
>Robots are the best though.
Women *are* robots.
Quoth Markus Teich:
> 8bit per component are sufficient for the human eye. This leads to 2 ^ (3*8) =
> 16.777.216 colors. Can you differentiate any pair of them I would show you?
For some domains it's useful to preserve more detail than the eye
can differentiate, so that different image enhancem
On July 16, 2014 6:20:35 PM CEST, Nick wrote:
>Quoth Markus Teich:
>> 8bit per component are sufficient for the human eye. This leads to 2
>^ (3*8) =
>> 16.777.216 colors. Can you differentiate any pair of them I would
>show you?
>
>For some domains it's useful to preserve more detail than the ey
FRIGN wrote:
> Or give a hint on the format:
>
> img16widhei8rgba
I like this.
Charlie Murphy
Nick wrote:
> I suppose the reason why is that nobody has stated a use-case for
> this nice little image storage format. "Store all my images in a
> format I can understand and parse easily" seems reasonable to me,
> and I would like the ability to do that for any image I happen to
> value, reg
Lee Fallat wrote:
> ...And today I learned the beneficial gains from storing height in an
> image format. So much for extreme minimalism!
It's so you can allocate the buffer before reading from a pipe.
Charlie Murphy
Markus Teich wrote:
> spec
>
>
> Bytes Description
> 9 ASCII string: "imagefile"
> 2 Width of the image stored in network byte order (big-endian)
> 2 Height of the image stored in network byte order (big-endian)
>
> Then, (width*height) pixels arranged in height scanlines, where
Charlie Murphy wrote:
> Storing these images on a hard drive is a bad idea because they are
> too big. IMO one shouldn't discard PNG or JPEG unless one is afraid
That is, storing images in this hypothetical format is a bad idea.
Charlie Murphy
Charlie Murphy wrote:
> Charlie Murphy wrote:
> > Storing these images on a hard drive is a bad idea because they are
> > too big. IMO one shouldn't discard PNG or JPEG unless one is afraid
>
> That is, storing images in this hypothetical format is a bad idea.
Heyho,
I can imagine saving compre
XFilterEvent need to be called against every event, otherwise it would
missing some message in the xim protocol and misbehave on some im server.
---
st.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/st.c b/st.c
index 040638a..546db41 100644
--- a/st.c
+++ b/st.c
@@ -3786,6 +3786,8 @@ run(
Markus Teich wrote:
> I can imagine saving compressed imagefile files and then using them like:
>
> zcat IMAGEFILE | ${some_imagefile_handling_tool}
I take it back; you're absolutely right. An image by Buch from
opengameart.org compresses well as an imagefile.
In this case:
* the gzip imagefile
46 matches
Mail list logo
