I like your image format. It's really clever to split image representation and compression into two different stages. Dijkstra taught us about the importance of seperation of concerns and this embodies that in a way that has genius simplicity.
Name:
Anonymous2016-01-14 3:51
>>6 That's exactly the point. The position is irrelevant. Presuming a mostly random distribution of the other color channels (an actual image), the 1/4 frequency of the alpha channel will far surpass everything else and will have the lowest encoded length.
Name:
Anonymous2016-01-14 4:29
>>42 Frign's talking about parametric positional patterns, not frequency.
Name:
Anonymous2016-01-14 6:12
>>40 What's your favourite Touhou? Which Rozen maiden would you fuck?
I like your image format. It's really clever to split image representation and compression into two different stages. Dijkstra taught us about the importance of seperation of concerns and this embodies that in a way that has genius simplicity.
Yeah, and it's especially clever to put the format identifier behind the compression, so that you need to decompress the beginning of each file to get its real file type, or duplicate that information in some ad hoc unreliable way like using file extensions.
It's also pretty clever to force the use of generic compression algorithms instead of much more efficient specialized algorithms for lossless image compression.
I'm literally feeling suckless UNIX philosophy flowing through me right now.
Name:
Anonymous2016-01-14 11:38
| 4 | 32-Bit BE unsigned integer (width) Suppose its 2229 and i want to store my atomic-level hologram. Due format limitations of farbfeld i can only use 4B pixels resolution so thats about 56cmx56cm worth of carbon atoms. I'll probably use another format. | [2222] | 4⋅16-Bit BE unsigned integers [RGBA] / Why 16bits? sure just storing the format version will suffice 1 byte(version:0 to 255) where version0 is RGBA 16bit and you can extend it further in the future. | 8 | "farbfeld" magic value On the other hand wasting 8 bytes for a magic value where 2 bytes suffice.
Name:
Anonymous2016-01-14 11:43
I can't wait to rotate an image 90°, resize, adjust color, perform a sharpness pass, and stamp on my signature block by serially piping all this data through a bunch of different processes, each with their own copy of the image buffer.
would still have to use the endianness-conversion-functions for the BE systems it may run on.
Who cares about BE systems anyway? The only ones that are of any importance are network equipment, and that's just because of the stupid choice made 20 years ago...
Ironically, Ethernet is LE bit order but BE byte order.
>>41 Written like a true cargo-cult mouthbreather.
Name:
Anonymous2016-01-14 11:59
>>47 Suckless is taking the bloat out of abstract programming styles, and reapplying it to process composition.
Programming environments can at least optimize away abstraction boundaries & overhead. OS processes can't, without violating a ton of constraints. It is always more bloated, slower, and configuration-heavy (== error prone) to use a bunch of different independent tools to solve a problem than it is to use a monolithic one that does what you need, even though any individual independent tool might be light-weight.
(same goes to you, Cudder, now that you're here)
Name:
Anonymous2016-01-14 12:22
>>49 That why libraries exist. Its independent tools using the same core. And you can programmatically use them without writing a lot of code.
Name:
Anonymous2016-01-14 12:28
**On unix systems you'll need to write an equivalent to rundll32, to load with scripts.
Name:
Anonymous2016-01-14 13:44
>>50 When the philosophical constraint is how much flexibility or monolithicness any given executable has, the problem remains. If you bring in a ton of libs, that means a ton of options as to how to use them all in combination, which seems to be anti-suckless.
The unix philosophy of composite behavior is still at the commandline and piping layer.
>>53 Real-life numbers are a Semitic invention, that's why they are written (in the natural order) from right to left. Since memory addresses grow from left to right (and from down to up) (and here I'm using the notion of growth similar to that of a fir, with new leaves or needles as it is appearing at the top, as opposed to say a bamboo where new plant matter appears at the bottom), with all that said it would be appropriate to use LE.
Name:
Anonymous2016-01-14 16:23
kinda don't like the BE thing, everyone is complaining about it. Would you consider changing that?
Yeah, and it's especially clever to put the format identifier behind the compression, so that you need to decompress the beginning of each file to get its real file type, or duplicate that information in some ad hoc unreliable way like using file extensions.
That's a good point. It would be nice to be able to read some details off the file without performing any complex code like decompression.
It's also pretty clever to force the use of generic compression algorithms instead of much more efficient specialized algorithms for lossless image compression.
Could someone show the tradeoff? I thought bzip2 of raw image files was competitive with PNG?
Name:
Anonymous2016-01-14 17:07
Could someone show the tradeoff? I thought bzip2 of raw image files was competitive with PNG?
The difference between bzip2 and gzip (used by png internally) is in favor of bzip2 but is not that big. However png passes an image through a predictor first (several actually, and the encoder chooses that which gives the best compressible result) which really helps on certain kinds of images (with gradients for most prominent example).
You're welcome to test it yourself, of course.
Name:
Anonymous2016-01-14 18:17
>>21,23,28,30,48,53-55 Big-endian is the Right Thing. Chinese, Greeks, and Romans wrote their numbers big-endian.
Never fall for Intel shills' (``the Jews'') schemes.
123.45678... Imagine a number with that approximation. Intel shills want you to believe that the parts before and after the decimal points ``make more sense'' if they were written in different orders. What nonsense!
Next these shills would be telling us that ``the Jews'' made us say numbers in the sensible order like ``one billion, four hundred thirty million, ...'' instead of ``one, ten, two hundred, three thousand, ...'' or something backwards like that. When you say numbers the Right Way, you can cut it off at different places and get a good approximation. When they are read the Wrong Way, you can't even tell its order of magnitude until you hear the whole thing.
Name:
Anonymous2016-01-14 18:26
>>58 what if i come into the room half way through you speaking the number? Only with LE can i tell roughly how big it.
checkmate
Name:
Anonymous2016-01-14 18:56
>>59 Checkmate? That's nothing. If I murder you, you forfeit.
Name:
Anonymous2016-01-14 22:58
>>56 The tests in this thread has shown that keeping the extra bloated data in the file format is not made up by the compression. PNG etc al store less information, with 24bpp RBG, 8bpp greyscale, and such compared to always 64bpp. farbfeld feeds more data into bzip2 than PNG does, so the output is going to be bigger.
>>58 The best way we print numbers of different is to align the radix point. Little-endian has the radix point aligned across varying numeric lengths, so things like casting as smaller sizes work transparently. Big-endian does not align its radix point. End of story.
PNG uses (de/in)flate, which is basically gzip without headers.
Name:
Anonymous2016-01-15 5:28
>>35 You could make a restricted sub-standard from bimp, like how WebM is Matroska restricted to specific codecs, and GLib has a config parser for a simple XML subset.
Name:
Anonymous2016-01-15 8:00
>>66 PNG uses (de/in)flate, which is basically zlib without headers.
Name:
Anonymous2016-01-15 16:14
ok so lets take all the criticism we posted in the thread and design farbfeld 2.0 which is better than their suckmore shit?
And if it's too hard for wankers like suckless to manage using libpng, write some good wrappers or reimplementations around the basic algos to suit. You know, like every single modern high level language offers.
>>71 Why in all the fuck are people using C for core libraries like this? That's the stupidest decision in the universe. Get away from C, all this basic overflow security shit goes away. (Yes, other high level data leaks are still possible.)
But in any case, there are PNG implementations. It's not hard to write your own to the spec. Other languages have it built in. It's a good file format and does everything farbfeld does but with better compression.
>>72 People will continue using C for the next century until a better version of C will be created. All the contenders to replace C have drawbacks or lack standards/backward compatibility or portability. Security vulnerabilities matter if you are working for money:open source guys work for the art/ideals of open source/principles/etc. They pick C because its easy, fast, portable to anything and backward compatible for 40 years and counting.
Name:
Anonymous2016-01-15 17:37
I agree with 74-grojin-sama, while we all agree C is bad there isn't something better.. (design and make it!)
Name:
Anonymous2016-01-15 17:56
Here's the effect of converting about 1000 anime jpg pictures from danbooru into ff.bzip2:
murakami_suigun: 740 pics, 685.5 MB to 1.2 GB lena_28zoal29: 141 pics, 88.8 MB to 155.0 MB kanda_(ura-kanda): 80 pics, 44.8 MB to 143.7 MB bulge_tsuki: 52 pics, 11.6 MB to 19.6 MB
It is larger and I expected that because jpg is lossy and domain specific compression but it's really not bad.
Would like to do a test comparing sets of PNGs against FF but I don't know where to get a good sample set of PNGs - could someone else do this?
Name:
Anonymous2016-01-15 22:31
Just use tiff lol, it's just better.
>>72 You can't escape buffer overflow in any language except if you use an implementation that checks it, or if you use a language that forces you to prove that you are never going to overflow.