[SciPy-user] The IO library and image file formats -- compare with with PIL
Mon Apr 21 15:37:17 CDT 2008
On Apr 21, 2008, at 1:20 PM, Robert Kern wrote:
> On Mon, Apr 21, 2008 at 12:13 PM, Stéfan van der Walt <email@example.com
> > wrote:
>> On 21/04/2008, Zachary Pincus <firstname.lastname@example.org> wrote:
>>> Again, what I'm imagining wouldn't be a full-featured image IO
>>> library, but something lightweight with no dependencies outside of
>>> numpy, and potentially (if JPEG decoding isn't desired), no C-
>>> extensions. (One could conceivably use numpy to do JPEG encoding and
>>> decoding, but I've no interest in doing that...)
>> I love it -- let's do it (if everyone agrees, of course). Having a
>> Python reference implementation is the way to go. Should we separate
>> the io and the image processing routines, or put it all in
> If you are thinking about using PIL's code, I would prefer that it not
> go into scipy. It smells too much like a fork, and I just don't want
> scipy to get involved.
Understandable. It does seem pretty clear to me that the most
expeditious way to proceed with a lightweight library would be to
start by modifying (perhaps heavily, as in beyond-recognition, or
perhaps lightly to not-at-all) some of the pure-python PIL code that
is responsible for reading image file headers.
While I wouldn't call this a "fork" so much as the kind of horizontal-
code-transfer between related projects that is one of the major
rationales for open-source, there's no reason to be potentially
Let me look into whether this idea is at all feasible, and if it is we
can revisit the issue of whether it belongs anywhere near scipy.
(Would getting Fredrik Lundh's OK to use various bits in this way make
things easier? He does seem much more responsive to direct queries
I'm glad that there's some support for the idea, so let me look at the
code that I have and see if it's worth pursuing.
More information about the SciPy-user