VIPS for python-radiance
Thomas Bleicher
>> Do you see this as part of the python-radiance package or is it
>> just a 3rd party app that can be used on the final images?
>
> I think VIPS is very much aligned with the sort of processing we do in
> Radiance and its high performance and is tile based and processes
> *concurrently*.
> With other packages you'll have to write .hdr support, PIL doesn't do
> 32 bits RGB nor tile based ( problematic in terms of memory
> consumption ).
> So I suggest to use VIPS as an image processing dependency.
If the information on this wiki page
http://www.vips.ecs.soton.ac.uk/index.php?title=Python
is up-to-date I have a problem with making it a dependency
because the Python module is not available on Windows. I don't
know how soon the devs expect this to work but before Windows
support is available p-r should not depend on it.
> I don't think there's really another way of processing
> Radiance image in Python?
The way I see it a Radiance image is just a 2 or 3-dimensional
array of float values with a few extra bits in the header. All trivial
image processing (crop, flip) can be done on the array data and
I think there are libs out there that help with a few other operations
like scale or rotate.
Memory usage and processing time are good arguments but
I believe the majority of users will have reasonably sized images
to deal with. We could always add VIPS support as an optional
module ('large image support'). That way p-r will work without
VIPS and for those who need the extra speed it is available
separately.
Thomas
jelle
any ways of handling that without dependencies.
On the other hand you are absolutely right that a windows build should
be.
However, I feel its more constructive add a windows build option to
VIPS rather than supporting float images via PIL or something.
>>>I believe the majority of users will have reasonably sized images to deal with
images and do that myself too.
That's what radiance is capable of, that's what the python modules
hence should reflect.
Randolph Fritz
with Microsoft compiler licensing, which means the GUIs may never work
on Windows.
Bleh.
Randolph
Jelle Feringa
Given the unix orientation of the project, what about a wintel mingwc compile?
How is radiance build these days on windows, I wasn't aware of a MS compiler version?
-jelle
Randolph Fritz
Randolph
On Nov 9, 2010, at 7:49 AM, Thomas Bleicher wrote:
> On Tue, Nov 9, 2010 at 9:59 AM, jelle <jellef...@gmail.com> wrote:
>>> Do you see this as part of the python-radiance package or is it
>>> just a 3rd party app that can be used on the final images?
>>
>> I think VIPS is very much aligned with the sort of processing we do
>> in
>> Radiance and its high performance and is tile based and processes
>> *concurrently*.
>> With other packages you'll have to write .hdr support, PIL doesn't do
>> 32 bits RGB nor tile based ( problematic in terms of memory
>> consumption ).
>> So I suggest to use VIPS as an image processing dependency.
>
> If the information on this wiki page
>
> http://www.vips.ecs.soton.ac.uk/index.php?title=Python
>
> is up-to-date I have a problem with making it a dependency
> because the Python module is not available on Windows. I don't
> know how soon the devs expect this to work but before Windows
> support is available p-r should not depend on it.
There's also a licensing incompatibility, bleh.
>
>> I don't think there's really another way of processing
>> Radiance image in Python?
>
> The way I see it a Radiance image is just a 2 or 3-dimensional
> array of float values with a few extra bits in the header. All trivial
> image processing (crop, flip) can be done on the array data and
> I think there are libs out there that help with a few other operations
> like scale or rotate.
The header data is important, too.
The various p* applications do most common image processing
operations. Problem is, there isn't much tutorial documentation on
them. There are only a few people who know them well. Perhaps only
Greg, really.
Randolph
Thomas Bleicher
> Ok; there is _no_ module reading / writing .hdr files, so there aren't
> any ways of handling that without dependencies.
We can always wrap the existing image tools and rely
on that for the core features.
Even if we had RGBE reading/writing in a native Python
class would that allow us to use all the existing Radiance
tools on an image in Python or would we have to create
a file to run psign/pcompos etc?
>> I believe the majority of users will have reasonably
>> sized images to deal with
>
> False assumption. I know quite a few radiance users
> who do 10*10K+ images and do that myself too.
> That's what radiance is capable of, that's what the
> python modules hence should reflect.
I consider 10*10k still as 'reasonably' sized. Do you run
into memory problems with that already?
Thomas
Randolph Fritz
Mostly, it isn't. One of my many back-burner projects is a build on
the MS compilers. It might work on Windows 7 Ulitmate in the SUA
environment--I haven't tried it. Problem is, not being able to use
the Windows-native libraries means that we can never produce native
GUI apps on Windows. Since this is the most used platform, that's a
fairly big deal.
Then again, there are other problems on Windows. The X-windows
dependencies of Radiance are extensive.
Randolph
Thomas Bleicher
>> VIPS also has a licensing issue. I'm not sure that GPL
>> is compatible with Microsoft compiler licensing, which
>> means the GUIs may never work on Windows.
iirc at least the free Express Edition of MS Visual Studio
allows you to work on GPL projects.
> Given the unix orientation of the project, what about
> a wintel mingwc compile? How is radiance build these
> days on windows, I wasn't aware of a MS compiler
> version?
Does it matter how Radiance is built if we only access
the final binaries? If we look into C-extensions we may
have to use MS VS. I think since Python 2.5 the official
Windows packages are built with VS8.
Thomas
Jelle Feringa
> into memory problems with that already?
Hell yes ;)
Jelle Feringa
> into memory problems with that already?
That's 1.2GB of floats where often in image processing you have to deal with a few instances of that. so it can add up quickly.
Gregory J. Ward
It makes more sense to have the wrappers cache the image "variables" in a file of some kind, passing around filenames rather than actual data, which can then be processed by the Radiance p* filters. The syntax can still be the way you like it, but underneath you'll be dealing with files, instead.
I don't know enough about Python to say if this can work, but it's worth considering.
-Greg
rocketship
be avoided (except Radiance, of course). There's too much danger
getting dragged into other projects' problems or failings.
There's nothing worse than not being able to install a module because
it has one dependency that no longer compiles on your platform of
choice.
My experience with Python modules is that they should do one thing and
do it well, not try to cover too much.
Severn
Jelle Feringa
Guys, please check in the platitudes at the gate.
Please share practical and precise ideas, let's keep our holism's to ourselves…