Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #34017 > unrolled thread

Imaging libraries in active development?

Back to article view | Back to comp.lang.python

Contents

  Imaging libraries in active development? Alasdair McAndrew <amca01@gmail.com> - 2012-11-28 04:30 -0800
    Re: Imaging libraries in active development? Michael Torrie <torriem@gmail.com> - 2012-11-28 11:14 -0700
      Re: Imaging libraries in active development? Alasdair McAndrew <amca01@gmail.com> - 2012-11-28 22:53 -0800
        Re: Imaging libraries in active development? Adrien <adnothing@gmail.com> - 2012-11-29 10:29 +0100
          Re: Imaging libraries in active development? Alasdair McAndrew <amca01@gmail.com> - 2012-11-29 03:22 -0800
          Re: Imaging libraries in active development? Alasdair McAndrew <amca01@gmail.com> - 2012-11-29 03:22 -0800
      Re: Imaging libraries in active development? Alasdair McAndrew <amca01@gmail.com> - 2012-11-28 22:53 -0800
    Re: Imaging libraries in active development? Christian Heimes <christian@python.org> - 2012-11-28 20:00 +0100
      Re: Imaging libraries in active development? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-11-28 21:11 +0000
        Re: Imaging libraries in active development? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-11-28 19:27 -0500
          Imaging library zoom <zoom@yahoo.com> - 2012-11-29 10:01 +0100
        Re: Imaging libraries in active development? Christian Heimes <christian@python.org> - 2012-11-29 09:37 +0100
    Re: Imaging libraries in active development? Nobody <nobody@nowhere.com> - 2012-11-29 18:45 +0000
    RE: Imaging libraries in active development? "Prasad, Ramit" <ramit.prasad@jpmorgan.com> - 2012-11-29 23:04 +0000

#34017 — Imaging libraries in active development?

I'm investigating Python for image processing (having used Matlab, then Octave for some years).  And I'm spoiled for choice: PIL and its fork pillow, scipy.ndimage, scikits-image, mahotas, the Python interface to openCV...

However, PIL doesn't seem to be in active development.  What I want to know is - what are the current "standard" libraries for image processing in Python which are in active development?  

I have quite a few image processing student notes which I'm thinking of converting to Python, but I'd like to use the most up-to-date library.

Thanks,
Alasdair

[toc] | [next] | [standalone]

#34027

On 11/28/2012 05:30 AM, Alasdair McAndrew wrote:
> I'm investigating Python for image processing (having used Matlab,
> then Octave for some years).  And I'm spoiled for choice: PIL and its
> fork pillow, scipy.ndimage, scikits-image, mahotas, the Python
> interface to openCV...
> 
> However, PIL doesn't seem to be in active development.  What I want
> to know is - what are the current "standard" libraries for image
> processing in Python which are in active development?
> 
> I have quite a few image processing student notes which I'm thinking
> of converting to Python, but I'd like to use the most up-to-date
> library.

I'm curious.  What features do you need that pil doesn't have?  Other
than updating pil to fix bugs, support new image types or new versions
of Python, what kind of active development do you think it needs to
have? Maybe pil has all the features the original author wanted and is
pretty stable.  To judge a package on how fast it's changing seems a bit
odd to me.  Obviously you want to know that bugs can get fixed of
course.  Perhaps none have been reported recently.

[toc] | [prev] | [next] | [standalone]

#34049

I take your point that not being actively developed doesn't necessarily mean that the software is bad - but in general healthy software is continuously updated and expanded to meet the needs of its users, or to take advantage of new algorithms or hardware.

And in its current form PIL has a number of limitations: it doesn't allow linear filters of arbitrary size or shape, or non-linear filters (such as median filter) of arbitrary size. There doesn't seem to be built in support for standard imaging filters: Gaussian, Laplacian, LoG, edge detection, unsharp masking and so on.  It doesn't seem to have support for color space conversions (RGB, YIQ, HSV etc).  There don't seem to be standard edge detection routines (Laplacian of Gaussian, Canny, etc).  And so on.  Now maybe some of these can be found in other Python libraries, but I can't imagine I'm the only person who would ever want them in an imaging library.  Other libraries (scipy.ndimage, scikits-image) do go a long way to addressing my concerns.

Anyway, I was curious to know why PIL is lacking so much of what I would consider fairly fundamental imaging facilities, and why development seems to have stalled since 2009.

On Thursday, 29 November 2012 05:14:30 UTC+11, Michael Torrie  wrote:
> On 11/28/2012 05:30 AM, Alasdair McAndrew wrote:
> 
> > I'm investigating Python for image processing (having used Matlab,
> 
> > then Octave for some years).  And I'm spoiled for choice: PIL and its
> 
> > fork pillow, scipy.ndimage, scikits-image, mahotas, the Python
> 
> > interface to openCV...
> 
> > 
> 
> > However, PIL doesn't seem to be in active development.  What I want
> 
> > to know is - what are the current "standard" libraries for image
> 
> > processing in Python which are in active development?
> 
> > 
> 
> > I have quite a few image processing student notes which I'm thinking
> 
> > of converting to Python, but I'd like to use the most up-to-date
> 
> > library.
> 
> 
> 
> I'm curious.  What features do you need that pil doesn't have?  Other
> 
> than updating pil to fix bugs, support new image types or new versions
> 
> of Python, what kind of active development do you think it needs to
> 
> have? Maybe pil has all the features the original author wanted and is
> 
> pretty stable.  To judge a package on how fast it's changing seems a bit
> 
> odd to me.  Obviously you want to know that bugs can get fixed of
> 
> course.  Perhaps none have been reported recently.

[toc] | [prev] | [next] | [standalone]

#34057

Hey Alasdair,

I believe OpenCV might do the trick for you:
- it contains everything you seem to need (+ much much more);
- it is efficient;
- it is cross-platform;
- it has a usable python interface since version 2.4;
- it is not going away any time soon and is constantly improved;
- it has an active user base.

But (there is always a but), it also has some issues:
- (the main one for me) documentation is often incomplete or even 
sometimes cryptic: the website (http://docs.opencv.org/) is great, but, 
IIRC, the docstrings are automatically generated from the C++ prototypes 
using Boost.Python; some trial & error is often necessary to find out 
what the parameters of a function should be;
- it may be overkill if you just want to do some basic image processing 
(maybe scikits-image is a better choice there?).

Hope this helps,

Adrien

Le 29/11/2012 07:53, Alasdair McAndrew a écrit :
> I take your point that not being actively developed doesn't necessarily mean that the software is bad - but in general healthy software is continuously updated and expanded to meet the needs of its users, or to take advantage of new algorithms or hardware.
>
> And in its current form PIL has a number of limitations: it doesn't allow linear filters of arbitrary size or shape, or non-linear filters (such as median filter) of arbitrary size. There doesn't seem to be built in support for standard imaging filters: Gaussian, Laplacian, LoG, edge detection, unsharp masking and so on.  It doesn't seem to have support for color space conversions (RGB, YIQ, HSV etc).  There don't seem to be standard edge detection routines (Laplacian of Gaussian, Canny, etc).  And so on.  Now maybe some of these can be found in other Python libraries, but I can't imagine I'm the only person who would ever want them in an imaging library.  Other libraries (scipy.ndimage, scikits-image) do go a long way to addressing my concerns.
>
> Anyway, I was curious to know why PIL is lacking so much of what I would consider fairly fundamental imaging facilities, and why development seems to have stalled since 2009.
>
> On Thursday, 29 November 2012 05:14:30 UTC+11, Michael Torrie  wrote:
>> On 11/28/2012 05:30 AM, Alasdair McAndrew wrote:
>>
>>> I'm investigating Python for image processing (having used Matlab,
>>> then Octave for some years).  And I'm spoiled for choice: PIL and its
>>> fork pillow, scipy.ndimage, scikits-image, mahotas, the Python
>>> interface to openCV...
>>> However, PIL doesn't seem to be in active development.  What I want
>>> to know is - what are the current "standard" libraries for image
>>> processing in Python which are in active development?
>>> I have quite a few image processing student notes which I'm thinking
>>> of converting to Python, but I'd like to use the most up-to-date
>>> library.
>>
>>
>> I'm curious.  What features do you need that pil doesn't have?  Other
>>
>> than updating pil to fix bugs, support new image types or new versions
>>
>> of Python, what kind of active development do you think it needs to
>>
>> have? Maybe pil has all the features the original author wanted and is
>>
>> pretty stable.  To judge a package on how fast it's changing seems a bit
>>
>> odd to me.  Obviously you want to know that bugs can get fixed of
>>
>> course.  Perhaps none have been reported recently.

[toc] | [prev] | [next] | [standalone]

#34061

Thanks for the heads-up about OpenCV.  I have in fact briefly looked at OpenCV (well, the documentation), and it does seem remarkably complete.  And what it doesn't provide, such as image transforms (FFT, DCT etc), are offered elsewhere by other Python libraries.

Probably the combinations of OpenCV, Scipy.ndimage and scikits-image would cover pretty much all of my needs.

Thanks,
Alasdair 
> Hey Alasdair,
> 
> 
> 
> I believe OpenCV might do the trick for you:
> 
> - it contains everything you seem to need (+ much much more);
> 
> - it is efficient;
> 
> - it is cross-platform;
> 
> - it has a usable python interface since version 2.4;
> 
> - it is not going away any time soon and is constantly improved;
> 
> - it has an active user base.
> 
> 
> 
> But (there is always a but), it also has some issues:
> 
> - (the main one for me) documentation is often incomplete or even 
> 
> sometimes cryptic: the website (http://docs.opencv.org/) is great, but, 
> 
> IIRC, the docstrings are automatically generated from the C++ prototypes 
> 
> using Boost.Python; some trial & error is often necessary to find out 
> 
> what the parameters of a function should be;
> 
> - it may be overkill if you just want to do some basic image processing 
> 
> (maybe scikits-image is a better choice there?).
> 
> 
> 
> Hope this helps,
> 
> 
> 
> Adrien
> 
> 
> 
> Le 29/11/2012 07:53, Alasdair McAndrew a écrit :
> 
> > I take your point that not being actively developed doesn't necessarily mean that the software is bad - but in general healthy software is continuously updated and expanded to meet the needs of its users, or to take advantage of new algorithms or hardware.
> 
> >
> 
> > And in its current form PIL has a number of limitations: it doesn't allow linear filters of arbitrary size or shape, or non-linear filters (such as median filter) of arbitrary size. There doesn't seem to be built in support for standard imaging filters: Gaussian, Laplacian, LoG, edge detection, unsharp masking and so on.  It doesn't seem to have support for color space conversions (RGB, YIQ, HSV etc).  There don't seem to be standard edge detection routines (Laplacian of Gaussian, Canny, etc).  And so on.  Now maybe some of these can be found in other Python libraries, but I can't imagine I'm the only person who would ever want them in an imaging library.  Other libraries (scipy.ndimage, scikits-image) do go a long way to addressing my concerns.
> 
> >
> 
> > Anyway, I was curious to know why PIL is lacking so much of what I would consider fairly fundamental imaging facilities, and why development seems to have stalled since 2009.
> 
> >
> 
> > On Thursday, 29 November 2012 05:14:30 UTC+11, Michael Torrie  wrote:
> 
> >> On 11/28/2012 05:30 AM, Alasdair McAndrew wrote:
> 
> >>
> 
> >>> I'm investigating Python for image processing (having used Matlab,
> 
> >>> then Octave for some years).  And I'm spoiled for choice: PIL and its
> 
> >>> fork pillow, scipy.ndimage, scikits-image, mahotas, the Python
> 
> >>> interface to openCV...
> 
> >>> However, PIL doesn't seem to be in active development.  What I want
> 
> >>> to know is - what are the current "standard" libraries for image
> 
> >>> processing in Python which are in active development?
> 
> >>> I have quite a few image processing student notes which I'm thinking
> 
> >>> of converting to Python, but I'd like to use the most up-to-date
> 
> >>> library.
> 
> >>
> 
> >>
> 
> >> I'm curious.  What features do you need that pil doesn't have?  Other
> 
> >>
> 
> >> than updating pil to fix bugs, support new image types or new versions
> 
> >>
> 
> >> of Python, what kind of active development do you think it needs to
> 
> >>
> 
> >> have? Maybe pil has all the features the original author wanted and is
> 
> >>
> 
> >> pretty stable.  To judge a package on how fast it's changing seems a bit
> 
> >>
> 
> >> odd to me.  Obviously you want to know that bugs can get fixed of
> 
> >>
> 
> >> course.  Perhaps none have been reported recently.

[toc] | [prev] | [next] | [standalone]

#34062

Thanks for the heads-up about OpenCV.  I have in fact briefly looked at OpenCV (well, the documentation), and it does seem remarkably complete.  And what it doesn't provide, such as image transforms (FFT, DCT etc), are offered elsewhere by other Python libraries.

Probably the combinations of OpenCV, Scipy.ndimage and scikits-image would cover pretty much all of my needs.

Thanks,
Alasdair 
> Hey Alasdair,
> 
> 
> 
> I believe OpenCV might do the trick for you:
> 
> - it contains everything you seem to need (+ much much more);
> 
> - it is efficient;
> 
> - it is cross-platform;
> 
> - it has a usable python interface since version 2.4;
> 
> - it is not going away any time soon and is constantly improved;
> 
> - it has an active user base.
> 
> 
> 
> But (there is always a but), it also has some issues:
> 
> - (the main one for me) documentation is often incomplete or even 
> 
> sometimes cryptic: the website (http://docs.opencv.org/) is great, but, 
> 
> IIRC, the docstrings are automatically generated from the C++ prototypes 
> 
> using Boost.Python; some trial & error is often necessary to find out 
> 
> what the parameters of a function should be;
> 
> - it may be overkill if you just want to do some basic image processing 
> 
> (maybe scikits-image is a better choice there?).
> 
> 
> 
> Hope this helps,
> 
> 
> 
> Adrien
> 
> 
> 
> Le 29/11/2012 07:53, Alasdair McAndrew a écrit :
> 
> > I take your point that not being actively developed doesn't necessarily mean that the software is bad - but in general healthy software is continuously updated and expanded to meet the needs of its users, or to take advantage of new algorithms or hardware.
> 
> >
> 
> > And in its current form PIL has a number of limitations: it doesn't allow linear filters of arbitrary size or shape, or non-linear filters (such as median filter) of arbitrary size. There doesn't seem to be built in support for standard imaging filters: Gaussian, Laplacian, LoG, edge detection, unsharp masking and so on.  It doesn't seem to have support for color space conversions (RGB, YIQ, HSV etc).  There don't seem to be standard edge detection routines (Laplacian of Gaussian, Canny, etc).  And so on.  Now maybe some of these can be found in other Python libraries, but I can't imagine I'm the only person who would ever want them in an imaging library.  Other libraries (scipy.ndimage, scikits-image) do go a long way to addressing my concerns.
> 
> >
> 
> > Anyway, I was curious to know why PIL is lacking so much of what I would consider fairly fundamental imaging facilities, and why development seems to have stalled since 2009.
> 
> >
> 
> > On Thursday, 29 November 2012 05:14:30 UTC+11, Michael Torrie  wrote:
> 
> >> On 11/28/2012 05:30 AM, Alasdair McAndrew wrote:
> 
> >>
> 
> >>> I'm investigating Python for image processing (having used Matlab,
> 
> >>> then Octave for some years).  And I'm spoiled for choice: PIL and its
> 
> >>> fork pillow, scipy.ndimage, scikits-image, mahotas, the Python
> 
> >>> interface to openCV...
> 
> >>> However, PIL doesn't seem to be in active development.  What I want
> 
> >>> to know is - what are the current "standard" libraries for image
> 
> >>> processing in Python which are in active development?
> 
> >>> I have quite a few image processing student notes which I'm thinking
> 
> >>> of converting to Python, but I'd like to use the most up-to-date
> 
> >>> library.
> 
> >>
> 
> >>
> 
> >> I'm curious.  What features do you need that pil doesn't have?  Other
> 
> >>
> 
> >> than updating pil to fix bugs, support new image types or new versions
> 
> >>
> 
> >> of Python, what kind of active development do you think it needs to
> 
> >>
> 
> >> have? Maybe pil has all the features the original author wanted and is
> 
> >>
> 
> >> pretty stable.  To judge a package on how fast it's changing seems a bit
> 
> >>
> 
> >> odd to me.  Obviously you want to know that bugs can get fixed of
> 
> >>
> 
> >> course.  Perhaps none have been reported recently.

[toc] | [prev] | [next] | [standalone]

#34050

I take your point that not being actively developed doesn't necessarily mean that the software is bad - but in general healthy software is continuously updated and expanded to meet the needs of its users, or to take advantage of new algorithms or hardware.

And in its current form PIL has a number of limitations: it doesn't allow linear filters of arbitrary size or shape, or non-linear filters (such as median filter) of arbitrary size. There doesn't seem to be built in support for standard imaging filters: Gaussian, Laplacian, LoG, edge detection, unsharp masking and so on.  It doesn't seem to have support for color space conversions (RGB, YIQ, HSV etc).  There don't seem to be standard edge detection routines (Laplacian of Gaussian, Canny, etc).  And so on.  Now maybe some of these can be found in other Python libraries, but I can't imagine I'm the only person who would ever want them in an imaging library.  Other libraries (scipy.ndimage, scikits-image) do go a long way to addressing my concerns.

Anyway, I was curious to know why PIL is lacking so much of what I would consider fairly fundamental imaging facilities, and why development seems to have stalled since 2009.

On Thursday, 29 November 2012 05:14:30 UTC+11, Michael Torrie  wrote:
> On 11/28/2012 05:30 AM, Alasdair McAndrew wrote:
> 
> > I'm investigating Python for image processing (having used Matlab,
> 
> > then Octave for some years).  And I'm spoiled for choice: PIL and its
> 
> > fork pillow, scipy.ndimage, scikits-image, mahotas, the Python
> 
> > interface to openCV...
> 
> > 
> 
> > However, PIL doesn't seem to be in active development.  What I want
> 
> > to know is - what are the current "standard" libraries for image
> 
> > processing in Python which are in active development?
> 
> > 
> 
> > I have quite a few image processing student notes which I'm thinking
> 
> > of converting to Python, but I'd like to use the most up-to-date
> 
> > library.
> 
> 
> 
> I'm curious.  What features do you need that pil doesn't have?  Other
> 
> than updating pil to fix bugs, support new image types or new versions
> 
> of Python, what kind of active development do you think it needs to
> 
> have? Maybe pil has all the features the original author wanted and is
> 
> pretty stable.  To judge a package on how fast it's changing seems a bit
> 
> odd to me.  Obviously you want to know that bugs can get fixed of
> 
> course.  Perhaps none have been reported recently.

[toc] | [prev] | [next] | [standalone]

#34029

Am 28.11.2012 19:14, schrieb Michael Torrie:
> I'm curious.  What features do you need that pil doesn't have?  Other
> than updating pil to fix bugs, support new image types or new versions
> of Python, what kind of active development do you think it needs to
> have? Maybe pil has all the features the original author wanted and is
> pretty stable.  To judge a package on how fast it's changing seems a bit
> odd to me.  Obviously you want to know that bugs can get fixed of
> course.  Perhaps none have been reported recently.

PIL is missing a bunch of features like proper TIFF support (no
multipage, g3/g4 compression and more), JPEG 2000, RAW and HDR image
formats, tone mapping, proper ICC support, PEP 3128 buffer support ...

PIL is also rather slow. My smc.freeimage library can write JPEGs about
six times faster, because it uses libjpeg-turbo. Only some Linux
distributions have replaced libjpeg with the turbo implementation.

[toc] | [prev] | [next] | [standalone]

#34035

On Wed, 2012-11-28, Christian Heimes wrote:
> Am 28.11.2012 19:14, schrieb Michael Torrie:
>> I'm curious.  What features do you need that pil doesn't have?  Other
>> than updating pil to fix bugs, support new image types or new versions
>> of Python, what kind of active development do you think it needs to
>> have? Maybe pil has all the features the original author wanted and is
>> pretty stable.  To judge a package on how fast it's changing seems a bit
>> odd to me.

Not to me -- the slower the change, the better!

>> Obviously you want to know that bugs can get fixed of
>> course.  Perhaps none have been reported recently.
>
> PIL is missing a bunch of features like proper TIFF support (no
> multipage, g3/g4 compression and more), JPEG 2000,

I thought those formats were dead since about a decade?  (Ok, I know
TIFF has niches, but JPEG 2000?)

> RAW and HDR image
> formats, tone mapping, proper ICC support, PEP 3128 buffer support ...

I won't comment on those, but they seem likely to be valid complaints.

> PIL is also rather slow. My smc.freeimage library can write JPEGs about
> six times faster, because it uses libjpeg-turbo. Only some Linux
> distributions have replaced libjpeg with the turbo implementation.

That seems like an argument for *not* having support for many file
formats in the imaging library itself -- just pipeline into the best
standalone utilities available.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#34045

On 28 Nov 2012 21:11:07 GMT, Jorgen Grahn <grahn+nntp@snipabacken.se>
declaimed the following in gmane.comp.python.general:

> On Wed, 2012-11-28, Christian Heimes wrote:
> > PIL is missing a bunch of features like proper TIFF support (no
> > multipage, g3/g4 compression and more), JPEG 2000,
> 
> I thought those formats were dead since about a decade?  (Ok, I know
> TIFF has niches, but JPEG 2000?)
>
	TIFF is, so far as I know, still a standard format for high quality
photo transfer.
 
> > RAW and HDR image
> > formats, tone mapping, proper ICC support, PEP 3128 buffer support ...
> 
> I won't comment on those, but they seem likely to be valid complaints.
>
	RAW is not a specific format -- Canon, alone, has had TWO formats
that are considered "RAW" (.CRW, and the newer .CR2). Notice the lag
with Adobe Camera RAW as they have to reverse engineer the format
whenever a new camera model is released (the format may not have
changed, but some meta-data may be new).

	Expecting a volunteer development to spend time keeping up with, and
reverse-engineering, each manufacturer's RAW format is, to my mind,
asking for a bit much.

	I'd not heard of an "HDR" format before... Most software I know of
expects to get two or more /regular/ images as input, and THEN process
to create an HDR -- tone mapping being part of that processing.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#34053 — Imaging library

C'mon guys, don't be so picky.
The point is that that he cannot find python library that can easily 
create HDR image or process RAW images (or some other image format).
Also, AFAIK there is no built in support for standard imaging filters, 
color space conversion, etc (as Alasdair also mentioned). One can do 
this with scipy, and this is how I do it. But I'm also interested if 
there is some library that implements any of those. IMHO it would be 
useful if one could code the same effects easily as clicking on the 
effect button in GIMP or Blender.
This is interesting question, and if any of you have any ideas on how 
this can be achieved, please share your knowledge with us.

P.S.
We do not need to tutor people about whether a RAW format is a specific 
image format or not (http://en.wikipedia.org/wiki/Raw_image_format) - we 
understand the point of his question albeit it is not clearly stated.
Assume good will - nobody is stating that PIL or scipy are bad, we 
simply ask whether there is something more out there.

It would be more useful if we would provide information on how to do it, 
or connect him with someone who can do it. Or point where he can request 
such feature or publish his solution. The policy not to implement every 
format under the sky is a legal one, but by implementing it one-by-one - 
together we might even get there.

[toc] | [prev] | [next] | [standalone]

#34052

Am 28.11.2012 22:11, schrieb Jorgen Grahn:
> I thought those formats were dead since about a decade?  (Ok, I know
> TIFF has niches, but JPEG 2000?)

Baseline TIFF is still used a lot when a lossless image format is
required. It's widely used for scientific stuff, long-time preservation,
health care (e.g. MRI) and for many more applications. If you need to
deal with formats like 32bit float RGBA or 128bit complex float pixels
or color spaces like CMYK, CIELUV, CIEXYZ, then TIFF is your man.

I'm sitting on nearly a quarter petabyte of TIFF images. The data should
still be usable in 200 years. Bit rot *is* a serious issue for long
periods of time.

> That seems like an argument for *not* having support for many file
> formats in the imaging library itself -- just pipeline into the best
> standalone utilities available.

An imaging library shouldn't implement all file formats on its own and
rather use existing libraries. That's what I'm doing with smc.freeimage.
It wraps and ties together FreeImage and lcms. FreeImage itself contains
and encapsulates eight libraries (e.g. libjpeg, libtiff4, libraw, libpng
...) in a powerful API.

Christian

[toc] | [prev] | [next] | [standalone]

#34076

On Wed, 28 Nov 2012 04:30:25 -0800, Alasdair McAndrew wrote:

> What I want to know is - what are the current "standard" libraries for
> image processing in Python which are in active development?

NumPy/SciPy.

PIL is fine for loading/saving image files (although if you're using a GUI
toolkit, that probably has its own equivalents). But for any non-trivial
processing, I normally end up using either NumPy or (if speed is an issue)
PyOpenGL/GLSL.

[toc] | [prev] | [next] | [standalone]

#34080

Christian Heimes wrote:
> 
> Am 28.11.2012 19:14, schrieb Michael Torrie:
> > I'm curious.  What features do you need that pil doesn't have?  Other
> > than updating pil to fix bugs, support new image types or new versions
> > of Python, what kind of active development do you think it needs to
> > have? Maybe pil has all the features the original author wanted and is
> > pretty stable.  To judge a package on how fast it's changing seems a bit
> > odd to me.  Obviously you want to know that bugs can get fixed of
> > course.  Perhaps none have been reported recently.
> 
> PIL is missing a bunch of features like proper TIFF support (no
> multipage, g3/g4 compression and more), JPEG 2000, RAW and HDR image
> formats, tone mapping, proper ICC support, PEP 3128 buffer support ...
> 
> PIL is also rather slow. My smc.freeimage library can write JPEGs about
> six times faster, because it uses libjpeg-turbo. Only some Linux
> distributions have replaced libjpeg with the turbo implementation.
> 

Have you tried libtiff? I believe the author may read this list.
(He posted here for at least one release). 
http://code.google.com/p/pylibtiff/


Hope that helps,
Ramit


This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.  

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web