UNIX philosophy.

Why is the opposite of cat tee, and it's not even a proper opposite but also does a different thing (outputs to stdout) (which is ostensibly its real purpose)?

Also, why do I even need the opposite of cat (and cat itself while we are at it) when those needs should have been served by input and output redirection, but turns out that the latter is completely made up and broken shell bullshit: you can't cat <file1 <file2, and you can't EDITOR='echo zzz >>$1' visudo for example.

Orthogonal design, my ass. Do one thing and do it well, my ass.

>>32

yeah I saw it. I will just keep it short here: The presenter will probably mention out-of-gamut-cases (people not enlightened about color spaces will call it "negative RGB values"). I'm looking forward to it.

>>32

It all boils down to the fact that I chose sRGB as a mandated colorspace for farbfeld. Thing here is: It is too early to talk about color management, and somehow, the Linux desktop is really bad with it. GIMP has only added color management a few months ago (that works properly).

You are free to use other color spaces (like ProPhotoRGB) with farbfeld, but it's not "endorsed". It all boils down to the fact that color spaces are a complex matter and currently the benefits don't weigh out the complexity. If people don't use your format because it's too complex nobody wins.

>>32

For image processing, an example use case would be to import all farbfeld images that are sRGB, convert them to ProPhotoRGB, do all calculations internally using ProPhotoRGB and then convert it to sRGB for output. But it doesn't end there.

There has to be respect for the photographers who do RAW shootings, with all the raw-pipeline involved.
We can't talk about a "suckless Photoshop" unless we are really sure what the users want, and in most cases, you just want to have really simple filters to enhance pictures in some way or to cut them in some respect. Think of Instagram, which has only a few filters, but it's sufficient for the 99% who just want to have some image effects.

I did some extensive testing with color spaces in farbfeld a year ago and actually turned it into a CIELab+Alpha-storage format. However, it turned out to be rather bad even though with CIELab you don't have to worry about color spaces.

The compression didn't work well any more and bzipping the farbfeld data yielded no good results. I also tried to express the data ranges within the CIELab color space using discrete unsigned integers (e.g. for the a-channel to be between -100 and 100 and then having 16-Bit increments), but it just didn't save the compression-problem.

But a much bigger problem was this: People don't know how to deal with CIELab color spaces and it's complex to transform sRGB-coordinates to CIELab. Why would anybody do this when he can use any other format which does it much simpler (like PBM)?