Farbfeld

So tell me, user, why are you still using harmful and bloated image formats instead of farbfeld?

Attached: farbfeld.png (686x332, 14K)

it's better than PPM (and anything is better than BPM)

>Farbfeld
> suckless.com
pure fucking cancer. fuck off and die, cunt.

this

show me other sane bitmap format and I will admit that farbfeld is useless

Nice argument, nigger

>uncompressed
this is why suckless software runs only on manchildrens computers

>what is bzip

haha just use `gzip` haha

>let me just manually decompress every picture every time I want to look at it instead of having the image decoder do it for me

yes, and that's how it should be done, any other way is just harmful

>32bit width
>32bit height

fucking trash

You don't need anything more than that, bloatfaggot

Ah, the classic "You don't need that anyway" argument.

tfw can't save the high-res image of Mars

So, how is it any different than bmp?

ok it probably could, largest photo ever takes was allegedly 846.07 gigapixels, if it was square then 16-bit would be enough

it's doesn't have insane disgusting specs

>retard can't into unix
>here let me spoon feed you
2ff > file.ff | xz -zc - > file.ff.xz
or
2ff > file.ff | gzip - > file.ff.gz
To view with lel
xz -dc file.ff.gz | lel
or
gunzip -dc file.ff.gz | lel

If you're not a total retard you script it and then you can get file sizes that are smaller than png's
I've been using it almost exclusively for several months now to convert to and store my raw photos off my camera. I used to convert to png but farbfeld has smaller file sizes when compressed.

But it's literally same width, height and bitmap map.

>use a generic compression algorithm instead of one tuned for compressing images!
Classic suckmore

>us an image encoding tuned for an algorithm that is tuned for compressing images but is bad.
>rather than encoding your image to be good for any compression algorithm.
You can use an algorithm designed for image compression if you really want to.

That's the whole point of the suckless philosophy. Having functionalities that you don't need is harmful. Do more with less.

>14,314 B 1551634914370.png
13,435 B 1551634914370.ff.bz2
Well I'll be damned

64bpp BE why exactly? Kind of defeats the point of an uncompressed format if you can't load it into memory and use it directly. And is it normalized, fixed point, what's the dynamic range?

Oh of course. Instead of just having an image format with compression in the spec we should have a separate program called imgzip and all our images should should have two extensions and require running something like imgzip -dc pic.ff.iz | ffcat because by god a program doing more than one thing is WRONG!

do you know what a script is?

Attached: 1511413203993_0.jpg (558x614, 15K)

Post a single image that is bigger than png with best compression.

>Having functionalities that you don't need is harmful.
Thanks, but usually I decide what I need and not my software.

>because by god a program doing more than one thing is WRONG!
that is the premise

ultimately, larger programs are expected to be composed of smaller ones
and bzip literally compresses this shit better

>ultimately, larger programs are expected to be composed of smaller ones
Does suckless endorse functional programming?

look up the bmp spec
it's needlessly complicated and stores pictures upside down

OP's image isn't optimized though. This version is only 12,259 bytes.

Attached: opt.png (686x332, 12K)

12,245 bytes seems to be the minimum file size achievable with PNG (ect -9 -strip --pal_sort=120 --allfilters-b).

Attached: opt.png (686x332, 12K)

It stores them upside down because of how GDI draws on a device context. When the format was designed, it was cripplingly slow to translate a "correctly" stored image.

No, you really don't.