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
41 matches
Mail list logo
