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 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
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
Evan Gates wrote:
> I've attached a version that works with the waterfall.image from
> earlier in the thread. (imgRGBA signature and 7 bytes for width and
> height). It also:
> 1) is POSIX compliant
> 2) works with null bytes separating the sig, width, and height
> 3) will run display serially on a
> Anyway, here's a viewer script in case anybody wants it. :-)
A few notes on the script.
> viewer.sh
I recommend against using the .sh extension. This is a new command you
are going to run. You don't type ls.elf why would you type viewer.sh?
What if at some point in the future you want to repla
FRIGN wrote:
> I think there's more to it than just being an intermediate format.
> My tests showed that especially for line-art, it beats png by far (I
> got results with over 60%!).
> Given the simplicity of the format, you could write a coder easily.
That compression is due to bzip2. Like a co
Charlie Murphy wrote:
> * imgRGBA (from Norman Koehring's script)
> * imageRGBA (exactly 10 bytes)
> * img16widhei8rgba (doesn't make sense for ASCII header)
> * imagefile (doesn't hint about file contents)
Heyho,
I did not find any format using „img“ as a magic string, but I can imagine that
the
> Is there an image format that's simpler than PPM and that supports
> alpha transparency?
If you want a format that works with existing tools, TGA can be
simple. Just don't use run-length encoding or indexed colour or
extension information (colour correction table, gamma field,
premultiplied alp
On Thu, 17 Jul 2014 15:26:40 -0400
Charlie Murphy wrote:
> This format was designed to _be_ an intermediate format. It's essentially
> a protocol for sending raw pixels across pipes. If we write small scripts
> that use ImageMagick, both the conversion and viewing problems are solved.
> ImageMa
Lee Fallat wrote:
> Excellent. I have time to create a converter as well, but I want
> suckless to agree on something final before I proceed. We also need to
> decide what our intermediate format is going to be (I was thinking
> bmp, because we can just slap a bmp header onto our data), unless
> im
On Thu, 17 Jul 2014 14:53:59 -0400
Lee Fallat wrote:
> Excellent. I have time to create a converter as well, but I want
> suckless to agree on something final before I proceed. We also need to
> decide what our intermediate format is going to be (I was thinking
> bmp, because we can just slap a b
FRIGN wrote:
> Basically speaking, I'm now more of a fan of storing the width and
> height in binary form (16 or 32 bit) instead of ASCII.
Binary form has benefits, but being able to print the header from a script
is why I like the ASCII header so much. It's possible to write a converter
script (
On Thu, Jul 17, 2014 at 2:47 PM, FRIGN wrote:
> On Thu, 17 Jul 2014 14:27:45 -0400
> Charlie Murphy wrote:
>
>> * imgRGBA (from Norman Koehring's script)
>> * imageRGBA (exactly 10 bytes)
>> * img16widhei8rgba (doesn't make sense for ASCII header)
>> * imagefile (doesn't hint about file contents)
On Thu, 17 Jul 2014 14:27:45 -0400
Charlie Murphy wrote:
> * imgRGBA (from Norman Koehring's script)
> * imageRGBA (exactly 10 bytes)
> * img16widhei8rgba (doesn't make sense for ASCII header)
> * imagefile (doesn't hint about file contents)
I personally like imgRGBA and imageRGBA, but there nee
Charlie Murphy wrote:
> * imageRGBA (exactly 10 bytes)
9 bytes, sorry.
FRIGN wrote:
> No, but I don't expect big changes to it any more.
> We also don't need a viewer yet. Just a converter.
I think we should pick a magic string, so that there is
less confusion.
Some magic strings I have seen are:
* imgRGBA (from Norman Koehring's script)
* imageRGBA (exactly 10 byt
On Thu, 17 Jul 2014 13:24:58 -0400
Lee Fallat wrote:
> Have we established the standard yet? Are we using SDL or something
> similar for the viewer?
No, but I don't expect big changes to it any more.
We also don't need a viewer yet. Just a converter.
--
FRIGN
On Thu, Jul 17, 2014 at 1:15 PM, FRIGN wrote:
> Can't somebody just write this damn thing in C already? :P
>
Have we established the standard yet? Are we using SDL or something
similar for the viewer?
On Thu, 17 Jul 2014 13:09:09 -0400
Nick wrote:
> Quoth FRIGN:
> > Here's my version:
> >
> > content=`cat $1`
> > if [ ${content:0:9} = "imageRGBA" ]; then
> > w=${content:10:9}
> > h=${content:20:9}
> > echo ${content:30} | convert -size "$w"x"$h" -depth 8 rgba:- png:-
>
Quoth FRIGN:
> Here's my version:
>
> content=`cat $1`
> if [ ${content:0:9} = "imageRGBA" ]; then
> w=${content:10:9}
> h=${content:20:9}
> echo ${content:30} | convert -size "$w"x"$h" -depth 8 rgba:- png:-
Isn't ${var:1:2} a bashism? I prefer cut :)
On Thu, 17 Jul 2014 11:48:13 -0400
Charlie Murphy wrote:
> Here's a script for turning one back into PNG.
This doesn't work for me. After modifying it for quite a bit, I get the
error:
convert: unexpected end-of-file `-': No such file or directory @
error/rgb.c/ReadRGBImage/231.
As so often, t
FRIGN wrote:
> BTW: How would we do the conversion? Write an imagemagick-coder?
> If so, I really can recommend the webp.c-coder[0] for its relative
> simplicity.
Here's a script for turning one back into PNG.
imgtopng.sh
Description: Bourne shell script
On Thu, 17 Jul 2014 16:28:34 +0200 (CEST)
Norman Köhring wrote:
> There are at least to simple (to handle) tools for that:
>
> http://search.cpan.org/~exiftool/Image-ExifTool-9.60/exiftool
> http://exiv2.org/
Exiftool came to my mind too, but mind that exiv2 is written in C++.
Another idea woul
> FRIGN hat am 17. Juli 2014 um 16:02 geschrieben:
>
> Converting an image to the imagefile-format would be as trivial as
> offering a flag to enable dumping the EXIF-information to a separate
> file.
There are at least to simple (to handle) tools for that:
http://search.cpan.org/~exiftool/Imag
On Thu, Jul 17, 2014 at 1:09 PM, Weldon Goree wrote:
> Now that I say that, I wonder if serial storage of the color channels
> would compress better, since you'll generally have low-frequency content
> for most of the channels most of the time.
Interesting idea. I'd be interested in knowing wethe
On Thu, 17 Jul 2014 15:56:26 +0200
Anselm R Garbe wrote:
> On 17 July 2014 15:05, FRIGN wrote:
> > I'm all against metadata. If someone wants to have his EXIF-info in his
> > picture-collection, he can provide these in plain text with image001.exif.
>
> The filename can be used for metadata ;)
On 17 July 2014 15:05, FRIGN wrote:
> I'm all against metadata. If someone wants to have his EXIF-info in his
> picture-collection, he can provide these in plain text with image001.exif.
The filename can be used for metadata ;)
-Anselm
On Thu, 17 Jul 2014 15:44:26 +0200
FRIGN wrote:
> In both cases, the imagefile+bz2 wins (due to reasons I gave in my last
> mail). Compressing the png's with bz2 obviously has only a minimal
> effect, because the compressor can't look through the interweaved
> png-format.
Argh, my mistake, of co
On Thu, 17 Jul 2014 17:39:39 +0530
Weldon Goree wrote:
> On that note, I'm now curious how this format would handle line
> noise/steganography. I'll report back if I find anything interesting on
> either question.
Okay, I did some short tests:
-- 1st test: waterfall.png (an example for a normal
On Thu, 17 Jul 2014 09:03:16 -0400
Nick wrote:
> bzcat < img.tar.bz2 | tar x -O
I heard from this flag too, but always mind the simplicity of the
implementation.
Running only one library-routine over a buffer is much simpler than
having to take care of two thing at the same time for little to no
> FRIGN hat am 17. Juli 2014 um 15:06 geschrieben:
>
> How did you convert it. Did I miss something? :D
#!/bin/sh
w=`identify -format %w "$1"`
h=`identify -format %h "$1"`
printf 'imgRGBA%8d%8d' $w $h
convert "$1" rgba:-
– koehrBEGIN:VCARD
VERSION:3.0
PRODID:OPEN-XCHANGE
FN:Köhring\, Norman
N
On Thu, 17 Jul 2014 17:39:39 +0530
Weldon Goree wrote:
Hey Weldon,
> I'm thinking back to my DSP class and trying to remember why time domain
> storage like this isn't in favor with most of the image formats. I guess
> TD storage limits you to lossless compression (you can lossy-ly compress
> fr
On Thu, 17 Jul 2014 14:24:00 +0200 (CEST)
Norman Köhring wrote:
> Not so much. I tried it with an image, which should be quite nice to compress
> (quite uniform, dark colours). Here for you to compare:
>
> 632K image.png
> 5.5M image.simpleimageformat
How did you convert it. Did I miss somethin
Quoth FRIGN:
> On Thu, 17 Jul 2014 12:46:53 +0200
> FRIGN wrote:
>
> > This is closer to the Unix-philosophy, however, as noted before,
> > bzip2 is way more efficient than gzip.
>
> As a small addition, .tar.bz2 gets closer, but there's no easy way to
> (b)zcat it.
I only read the manpage for
On Thu, 17 Jul 2014 14:11:25 +0200 (CEST)
Norman Köhring wrote:
> The container gives it a cleaner looking but then zcat (or any hypothetical
> bzip
> equivalent) is rendered unusable. This makes parsing is way more complex.
Yep, that's why being able to use (b)zcat is mandatory!
Using containe
> FRIGN hat am 17. Juli 2014 um 11:13 geschrieben:
> I suppose LZMA will give even better results.
Not so much. I tried it with an image, which should be quite nice to compress
(quite uniform, dark colours). Here for you to compare:
632K image.png
5.5M image.simpleimageformat
607K image.lzma /
(Sorry, Norman, you'll get this twice. One day I'll get "reply list"
down...)
On 07/17/2014 03:39 PM, Norman Köhring wrote:
> What about Meta-Data? Like with audio files, meta data can be very useful to
> have. I have two proposals for this:
>
Why add metadata capability to a format whose expres
> FRIGN hat am 17. Juli 2014 um 12:46 geschrieben:
> > Another way would be to have an additional meta data file. It could be
> > packed in
> > a TAR file together with the image data. This leads to a file like
> > example.image.tgz
>
> This is closer to the Unix-philosophy, however, as noted b
On 07/17/2014 02:43 PM, FRIGN wrote:
>
> I love this approach! Instead of trying to compress the image in the
> format itself (like PNG), we just leave it to the compressor to
> determine certain similarities and patterns.
> I suppose LZMA will give even better results.
>
I'm thinking back to my
On Thu, 17 Jul 2014 12:46:53 +0200
FRIGN wrote:
> This is closer to the Unix-philosophy, however, as noted before,
> bzip2 is way more efficient than gzip.
As a small addition, .tar.bz2 gets closer, but there's no easy way to
(b)zcat it.
--
FRIGN
On Thu, 17 Jul 2014 12:09:52 +0200 (CEST)
Norman Köhring wrote:
> What about Meta-Data? Like with audio files, meta data can be very useful to
> have. I have two proposals for this:
>
> Hence the image format describes the exact size of image data, the meta data
> could simple be attached. If th
What about Meta-Data? Like with audio files, meta data can be very useful to
have. I have two proposals for this:
Hence the image format describes the exact size of image data, the meta data
could simple be attached. If the format looks like:
imgFormat[4]Width[8]Height[8]Data[W×H]Metadata
e.g.:
On Wed, 16 Jul 2014 19:09:50 -0400
Charlie Murphy wrote:
> I take it back; you're absolutely right. An image by Buch from
> opengameart.org compresses well as an imagefile.
BTW: How would we do the conversion? Write an imagemagick-coder?
If so, I really can recommend the webp.c-coder[0] for its
On Wed, 16 Jul 2014 19:09:50 -0400
Charlie Murphy wrote:
> 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 is a little bigger than the PNG.
> * the bzip2 imagefile is a little smaller than
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
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
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
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
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
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
FRIGN wrote:
> Or give a hint on the format:
>
> img16widhei8rgba
I like this.
Charlie Murphy
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
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 5:46:25 PM CEST, Lee Fallat wrote:
>Robots are the best though.
Women *are* robots.
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 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
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, 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:
> 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, 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
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: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 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
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 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
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: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
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
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
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
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
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.
Neither the endianness nor the maximum width is in question for
space-separated human readable, variable width numbers.
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.
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
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 ;).
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 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
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
1 - 100 of 121 matches
Mail list logo
