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
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
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 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
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 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
> 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
(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 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 /
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
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: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
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
> 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 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
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 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 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: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 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
> 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, 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 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 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
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 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:-
>
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: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
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
Charlie Murphy wrote:
> * imageRGBA (exactly 10 bytes)
9 bytes, sorry.
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
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)
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, 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
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 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
> 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
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
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
> 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
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
41 matches
Mail list logo
