Support for the Netpbm suite formats?

[ulidtko]

It is kind of disappointing to see that... BMP (a.k.a. the Microsoft DIB) is preferred as the "debug" format, while there are way simpler formats, specifically designed for simplicity, debuggability and ease of implementation (in any language).

Doc here: http://netpbm.sourceforge.net/doc/#formats

Consider how simple the PGM format variation is: it's a few lines of ASCII headers, and then just a big array. That's it.

[Twinside]

Is this a whining about the readme or a real need for netpbm?

As they are one of the most inefficient format around, I'm not inclined to implement it, as there already is other librarires like netpbm and pnm to do that, and the png saving is much more indicated in nearly every case.

[ulidtko]

Not whining, but not a real need either. I was playing with the curves library which uses Juicy.Pixels and was kind of surprised of motivation for BMP support.

I'll note still that we used ppm formats extensively in a (successfully sold) face recognition startup; so it's a real thing.

Inefficiency of netpbm is not a good argument, for two reasons:

• there are "binary" PPM variations where the pixel array takes exactly as much as BMP equivalent (but with much simpler headers);
• when troubleshooting image processing algorithms, image format efficiency is a secondary concern (which is exactly the reason BMP is often used for this purpose), while simplicity is at premium.

So, I merely suggest that PPM support would likely be a good addition. Also again, pretty much trivial to implement.

[ulidtko]

Will you accept a pull-request implementing that?

[Twinside]

I'd gladly accept a pull request implementing the format, with the following restriction: no new package dependency, I really want to keep dependencies for this package to a minimum.

[dagit]

I really want to keep dependencies for this package to a minimum.

I apologize for hijacking an issue, but I think this needs to be said:

I really appreciate Juicy.Pixels and the way you've kept it pure/small/unencumbered.

I'm also glad to see that you're open to adding more formats, such as PPM. I too have used it in the past as a debugging format and found it valuable that way.

Keep up the good work! Thanks!

[hasufell]

Yes, it is surprising. For image processing algorithms you'll very likely use the PGM format for one thing or another.

@ulidtko an alternative might be the package friday (which uses the C library "devil" to load formats), but I found the interface to be a bit raw

[cies]

@hasufell Friday has it's DevIL dependency in a separate package friday-devil. I hope some day we can use JuicyPixels with Friday, thereby avoiding the extra dependencies and having a all-in-Haskell solution for basic image-processing needs (that many web apps at some point need). I've raised a separate issue for this some time ago.