https://github.com/OpenImageIO/oiio/pull/184
Add Filesystem::filename, and use it in place of a few tricky boost ifdefs.
Also add Filesystem::extension that is like file_extension but includes the dot
(and thus is compatible with boost).
--
Larry Gritz
l...@larrygritz.com
It seems like the most expedient solution is to invoke CMake directly, as
Brecht instructs.
The Makefile is just for the convenience of those of us used to typing 'make',
and apparently depends on having the kind of gnu-ish make that is found on
Linux and OSX.
On Oct 5, 2011, at 4:23 PM, Brec
Thanks Brecht,
I will try that tomorrow. lol. It's funny to get response from a
fellow Blender guy in here... lol.
On Wed, Oct 5, 2011 at 6:23 PM, Brecht Van Lommel
wrote:
> Here are some steps to do build directly using cmake:
>
> mkdir -p build/freebsd
> cd build/freebsd
> cmake ../../src -D
Here are some steps to do build directly using cmake:
mkdir -p build/freebsd
cd build/freebsd
cmake ../../src -DCMAKE_INSTALL_PREFIX=../../dist/freebsd
make install
Regarding the errors, the makefile uses gnu make extensions, so
installing and using that instead would probably solve them.
I've n
On Oct 5, 2011, at 9:57 AM, Ciaran Wills wrote:
> On an aside - display windows with the origin != (0, 0) are a pain in
> the arse, and I kinda wish EXR hadn't allowed them ;)
We often have these, because our in-house tools and in-house format are happy
with them. However, we've learned painfu
I don't really want to change it, and actually "full" is what we use internally
and really was the normal term pre-exr. I think both "full" and "display" can
be misleading at times.
It's strange when you ask for the full image and it's smaller than the non-full
image. But at the same time, you
Just a short note: The main build system uses cmake - the makefile is
really just a convenience wrapper, so the more important question is
whether the cmake-generated build system works.
Having said that, the makefile shouldn't be giving you trouble...
~Chris
_
On Oct 5, 2011, at 9:57 AM, Ciaran Wills wrote:
> I'm with Hugh on this one - for formats that don't have data windows
> I'd expect to get the display window, with the pixel data
> padded/cropped to fit. Maybe it's from too many years of using Shake
> but that's what I'd see as the 'expected' beh
First it does not find the platform detector, so I manually pointed
the makefile to it, and still get errors as follows
[pete@pvdi386 /usr/home/pete/oiio]$ make > output.txt
"/usr/home/pete/oiio/src/make/detectplatform.mk", line 24: Missing
dependency operator
"/usr/home/pete/oiio/src/make/det
Good point.
On Oct 5, 2011, at 10:00 AM, Ciaran Wills wrote:
> On Wed, Oct 5, 2011 at 9:56 AM, Larry Gritz wrote:
>
>> I'm not claiming that "full" is more descriptive, only that if we change
>> it, I want a clear improvement beyond "that's the word OpenEXR uses."
>
> 'full' implies max(dat
On Wed, Oct 5, 2011 at 9:56 AM, Larry Gritz wrote:
> I'm not claiming that "full" is more descriptive, only that if we change it,
> I want a clear improvement beyond "that's the word OpenEXR uses."
'full' implies max(dataWindow, displayWindow) which seems even more ambiguous ;)
___
I'm with Hugh on this one - for formats that don't have data windows
I'd expect to get the display window, with the pixel data
padded/cropped to fit. Maybe it's from too many years of using Shake
but that's what I'd see as the 'expected' behaviour.
That said, it's ok if that's not the default as
On Oct 5, 2011, at 8:31 AM, Jonathan Gibbs wrote:
> Since we're playing with names, I like width/height as they are, but I
> wouldn't have used the terms "full_width" and ""full_height",
> preferring "display_width", etc.
If starting from scratch today, I probably wouldn't have used full_width,
Can you do a 'make nuke' followed by 'make > output.txt' and attach the full
output? Maybe somebody can spot what's going wrong.
-- lg
On Oct 5, 2011, at 9:38 AM, pete larabell wrote:
> Hello all,
>
> My name is Pete Larabell, I'm the Unix platform maintainer for the
> Blender Founda
Hello all,
My name is Pete Larabell, I'm the Unix platform maintainer for the
Blender Foundation. (http://www.blender.org)
There is a new renderer being developed for Blender, intended for an
upcoming release probably within 6 months or so, which needs OIIO to
build.
I'm emailing you all for hel
On Oct 5, 2011, at 3:33 AM, Hugh Macdonald wrote:
> I'm going to have to (I hope you don't mind!) disagree with you on what is
> considered the "image" vs what is extra information.
Not at all! That's why I wanted to get this discussion out in the open. My
hope is for a number of people to wei
Short reply: I agree with Larry on this one.
Longer reply:
Based on how things have been going here at DWA, I'm increasingly
seeing the "dislpayWindow" and simply metadata, and increasingly
arbitrary metadata. It's useful for sure, but no everyone dealing with
the image has the same notion of wha
What about the situation (which is more of the case for me) where the data
window is far smaller than the display window.
I would still far prefer the default behaviour to be to use the display window
and then a -dataWindow toggle that sets it to the full data window (either
enlarging or shrink
Hi there -
I'm not too sure if this falls under the remit of what OIIO should manage but
there's also the argument that you're data window is what you care about right
now and your full_x/y is what you might need in the future. In the past we've
used this when rendering stereo elements, the d
I'm going to have to (I hope you don't mind!) disagree with you on what is
considered the "image" vs what is extra information.
I would say that full_width and full_height are the resolution of the image.
They are the area that you care about. The data window (width/height/x/y) is
just a way fo
On Oct 3, 2011, at 6:34 AM, Hugh Macdonald wrote:
> We discovered last week that, if we took an EXR with a data window that was
> not it's display window (let's say, for example, that the display window is
> 2048x1556, but the data window has the soundtrack area cropped off, and is
> 1828x1556,
I replied already on the ticket, but now I've thought more about the issues and
so I'll follow up here.
What should we do for formats that do not support differing 'data'
(width,height) and 'display' windows (full_width, full_height)? And similarly,
for formats that don't support nonzero origi
22 matches
Mail list logo
