POV-Ray : Newsgroups : povray.programming : OpenEXR 3.x issues - call to arms Server Time
28 Mar 2024 09:21:49 EDT (-0400)
  OpenEXR 3.x issues - call to arms (Message 1 to 10 of 13)  
Goto Latest 10 Messages Next 3 Messages >>>
From: clipka
Subject: OpenEXR 3.x issues - call to arms
Date: 2 Jun 2021 17:46:09
Message: <60b7fc21$1@news.povray.org>
Hi everyone,

anyone trying to compile POV-Ray with a modern version of OpenEXR - i.e. 
3.0.0 or higher - will have noticed that we're having some snag there.

The reason behind this is that some time in the past, Industrial Light 
and Magic (who had kicked off the OpenEXR thingumajig) had transferred 
the whole shebang to the public, who picked up the ball and ran with it 
like crazy.

Now, in March this year, this transfer has left its mark to the 
structure of the project itself, leading to two major changes:

(1) The OpenEXR library, which used to be named `IlmImf` (for Intustrial 
Light and Magic Image Format), has now officially been renamed to `OpenEXR`.

(2) An accompanying library, providing low-level mathematical stuff, 
like a 16-bit floating-point data type, that used to go by the moniker 
`IlmBase`, has been renamed to `Imath`.

This breaks all our builds, because those are not the libraries we are 
looking for.

And someone needs to fix this.


I presume it's more a matter of diligence, that requires a bit of 
understanding how an Automake-based build process works, but other than 
that will hopefully not need deep insight into the bowels of POV-Ray 
itself. And it also needs someone who can test any fixes before checking 
them in - which I can't, because my Linux Fu is limited, and the Linux 
machine I have convenient access to doesn't have OpenEXR 3 installed.

What I *think* needs to be done, is the following:

* Fix the Unix build process to do the right kind of version checking 
and pulling-in of libraries (primarily relevant files: 
`unix/configure.ac` and `unix/config/ax_check_openexr.m4`). The test for 
the actual `IlmImf` library would have to be changed, to test for 
`OpenEXR` instead if the version number detected is 3.0 or higher; also 
in that case, a test for the `Imath` library would have to be performed, 
which we currently don't have because it was effectively implicit when 
OpenEXR was present.

* Fix whatever needs fixing to make sure our OpenEXR handling source 
file (in v3.8 that would be `source/base/image/openexr.cpp` includes 
whatever files need including. Maybe we need to include different files 
if OpenEXR 3.x is installed. Maybe we just need to somehow adjust the 
include paths. I'm not sure yet. I haven't dug that deep.

* Fix `source/base/povray.cpp` to pull in the proper version information 
header files for the two libraries; again, you may need to change them, 
or maybe you don't.

* (optional) While you're at it, you might also want to concoct a 
mechanism by which to decide (depending on version number) whom to 
credit as copyright holders, and what internet address to refer to. 
Maybe also pull version information from the libraries via function 
calls (as we do for other libs; but note the comment saying that such 
function is unavailable in older versions). And maybe split up the 
credit into two chunks, one for IlmImf/OpenEXR and the other for 
IlmBase/Imath, as the libs are now fully separate projects.

* IMPORTANT: In all you do, make sure that the whole smash pretty much 
behaves as before (except for maybe improvements to the copyright 
notice) unless OpenEXR 3.0.0 or higher is indeed installed.

* If you're familiar with Git, submit your changes as a pull request to 
the `master` branch in the repo.

The issues affect both v3.8 and v3.7, so you're not done yet:

* Do all of the above again for the `v3.7.0` branch, starting from 
scratch. Whatever you did to fix v3.8, the same approach should also 
work for v3.7, and the changes won't be much different. But the two 
versions have grown too far apart to try and do anything that involves 
merges. They'd bite you in the arse for trying. You figured out what 
needed to be done, so you can do it again.


There. Now for the $0.000.000 question:

Any takers?


I know I could do it myself, but I'd prefer to spare my energy (which is 
limited, as we've seen) and time for the work that still needs to be 
done in POV-Ray's deep, deep gory bowels, where I dare not send anyone 
else, lest they be devoured by the abominations that lurk there. You 
know, the parser. The thing that software developers tell their children 
bedtime stories about when they're refusing to go to sleep. The thing 
that goes "bump" in the night `#if` you don't put an `#end` to it in 
time. The thing that scares you shitless when you meet it at night in a 
dark alleyway...

I think Lovecraft must have had premonitions of the POV-Ray parser code...


Post a reply to this message

From: jr
Subject: Re: OpenEXR 3.x issues - call to arms
Date: 3 Jun 2021 05:00:00
Message: <web.60b898d8cb27e48a79819d986cde94f1@news.povray.org>
hi,

clipka <ano### [at] anonymousorg> wrote:
> Hi everyone,
>
> anyone trying to compile POV-Ray with a modern version of OpenEXR - i.e.
> 3.0.0 or higher - will have noticed that we're having some snag there.
>
> The reason behind this is that some time in the past, Industrial Light
> and Magic (who had kicked off the OpenEXR thingumajig) had transferred
> the whole shebang to the public, who picked up the ball and ran with it
> like crazy.
>
> Now, in March this year, this transfer has left its mark to the
> structure of the project itself, leading to two major changes:
>
> (1) The OpenEXR library, which used to be named `IlmImf` (for Intustrial
> Light and Magic Image Format), has now officially been renamed to `OpenEXR`.
>
> (2) An accompanying library, providing low-level mathematical stuff,
> like a 16-bit floating-point data type, that used to go by the moniker
> `IlmBase`, has been renamed to `Imath`.
>
> This breaks all our builds, because those are not the libraries we are
> looking for.
>
> And someone needs to fix this.

my knowledge of the autotools is limited, but a quick look in 'unix/config'
shows that various macros test for the various libs, and 'ax_check_openexr.m4'
uses 'pkg-config' to do its thing.  looks like as long as 'pkg-config' is
up-to-date, only actual changed names of header files should impact.


> I think Lovecraft must have had premonitions of the POV-Ray parser code...

:-)


regards, jr.


Post a reply to this message

From: jr
Subject: Re: OpenEXR 3.x issues - call to arms
Date: 3 Jun 2021 09:35:00
Message: <web.60b8da01cb27e48a79819d986cde94f1@news.povray.org>
"jr" <cre### [at] gmailcom> wrote:
> ...
> my knowledge of the autotools is limited, ...

and so are my reading and comprehension, at times, evidently.


> Fix the Unix build process to do the right kind of version checking
> and pulling-in of libraries (primarily relevant files:
> `unix/configure.ac` and `unix/config/ax_check_openexr.m4`). The test for
> the actual `IlmImf` library would have to be changed, to test for
> `OpenEXR` instead if the version number detected is 3.0 or higher; also
> in that case, a test for the `Imath` library would have to be performed,
> which we currently don't have because it was effectively implicit when
> OpenEXR was present.

confused by your point (2) since 'Imath' is part of version 2.2.0 (and 1.7.1)
already.


regards, jr.


Post a reply to this message

From: clipka
Subject: Re: OpenEXR 3.x issues - call to arms
Date: 3 Jun 2021 19:43:39
Message: <60b9692b$1@news.povray.org>
Am 03.06.2021 um 15:32 schrieb jr:

>> Fix the Unix build process to do the right kind of version checking
>> and pulling-in of libraries (primarily relevant files:
>> `unix/configure.ac` and `unix/config/ax_check_openexr.m4`). The test for
>> the actual `IlmImf` library would have to be changed, to test for
>> `OpenEXR` instead if the version number detected is 3.0 or higher; also
>> in that case, a test for the `Imath` library would have to be performed,
>> which we currently don't have because it was effectively implicit when
>> OpenEXR was present.
> 
> confused by your point (2) since 'Imath' is part of version 2.2.0 (and 1.7.1)
> already.

I'm confused by it all, too. At any rate, the math portions are no 
longer found (even when fixing the IlmImf->OpenEXR thing), and that has 
to be fixed.

 From all I've read on the internet, one thing seems quite obvious: 
Those math portions are no longer part of an accompanying library, but a 
library that - at least at this point - constitutes an entirely 
independent project. And I've found talk about it having been "renamed" 
(whatever that means) from `IlmBase` to `Imath`.


It's an ideal job to be delegated: I'm just as confuzzled by it all as 
anyone else.


Post a reply to this message

From: Bald Eagle
Subject: Re: OpenEXR 3.x issues - call to arms
Date: 3 Jun 2021 20:10:00
Message: <web.60b96ea1cb27e48a1f9dae3025979125@news.povray.org>
I am excellent at asking about or stating the obvious, so...

Presumably you have seen these (?):

https://github.com/AcademySoftwareFoundation/Imath/blob/master/docs/PortingGuide2-3.md

https://github.com/aforsythe/IlmBase


Post a reply to this message

From: clipka
Subject: Re: OpenEXR 3.x issues - call to arms
Date: 4 Jun 2021 15:15:16
Message: <60ba7bc4@news.povray.org>
Am 04.06.2021 um 02:06 schrieb Bald Eagle:
> I am excellent at asking about or stating the obvious, so...
> 
> Presumably you have seen these (?):
> 
>
https://github.com/AcademySoftwareFoundation/Imath/blob/master/docs/PortingGuide2-3.md

Nope.

> https://github.com/aforsythe/IlmBase

That repo has been inactive since 2012.


As I mentioned, I haven't looked too deep into this yet. And there's 
other stuff I have on my plate at the moment, which I can't delegate as 
easily.

So if anyone could step up and take over this task - from digging up 
info like the above, to actually implementing the necessary fixes - that 
would be terrific.


Post a reply to this message

From: Ton
Subject: Re: OpenEXR 3.x issues - call to arms
Date: 6 Jun 2021 22:40:00
Message: <web.60bd8638cb27e48a6aa9bed67597fb06@news.povray.org>
clipka <ano### [at] anonymousorg> wrote:
> Am 04.06.2021 um 02:06 schrieb Bald Eagle:
> > I am excellent at asking about or stating the obvious, so...
> >
> > Presumably you have seen these (?):
> >
> >
https://github.com/AcademySoftwareFoundation/Imath/blob/master/docs/PortingGuide2-3.md
>
> Nope.
>
> > https://github.com/aforsythe/IlmBase
>
> That repo has been inactive since 2012.
>
>
> As I mentioned, I haven't looked too deep into this yet. And there's
> other stuff I have on my plate at the moment, which I can't delegate as
> easily.
>
> So if anyone could step up and take over this task - from digging up
> info like the above, to actually implementing the necessary fixes - that
> would be terrific.

Hi clipka, I'll have a look at this. I hope that installing openexr 3 will go
alright and when that's done I can start telling povray to use then new openexr.

Cheers
Ton.


Post a reply to this message

From: clipka
Subject: Re: OpenEXR 3.x issues - call to arms
Date: 7 Jun 2021 03:35:10
Message: <60bdcc2e$1@news.povray.org>
Am 07.06.2021 um 04:36 schrieb Ton:

> Hi clipka, I'll have a look at this. I hope that installing openexr 3 will go
> alright and when that's done I can start telling povray to use then new openexr.

Thanks, much appreciated!


Post a reply to this message

From: Ton
Subject: Re: OpenEXR 3.x issues - call to arms
Date: 15 Jun 2021 00:30:00
Message: <web.60c82c1fcb27e48a6aa9bed67597fb06@news.povray.org>
Persistence of Vision(tm) Ray Tracer Version 3.7.0.9.unofficial (g++ 9 @
x86_64-pc-linux-gnu)
  OpenEXR 2.3.0 and IlmBase 2.3.0, Copyright (c) 2002-2011 Industrial Light &
Magic.
  ldd unix/povray
        libIlmImf-2_3.so.24 => /lib/x86_64-linux-gnu/libIlmImf-2_3.so.24
(0x00007fd918405000)
        libHalf.so.24 => /lib/x86_64-linux-gnu/libHalf.so.24
(0x00007fd9183c0000)
        libIex-2_3.so.24 => /lib/x86_64-linux-gnu/libIex-2_3.so.24
(0x00007fd91839f000)
        libIlmThread-2_3.so.24 => /lib/x86_64-linux-gnu/libIlmThread-2_3.so.24
(0x00007fd917902000)

  OpenEXR 3.1.0-dev and Imath 3.1.0-dev, Copyright (c) Contributors to the
OpenEXR Project.
  ldd unix/povray
        libOpenEXR-3_1.so.29 => /usr/local/lib/libOpenEXR-3_1.so.29
(0x00007f7266ba5000)
        libIlmThread-3_1.so.29 => /usr/local/lib/../lib/libIlmThread-3_1.so.29
(0x00007f7266108000)
        libImath-3_1.so.29 => /usr/local/lib/../lib/libImath-3_1.so.29
(0x00007f72660b3000)
        libIex-3_1.so.29 => /usr/local/lib/../lib/libIex-3_1.so.29
(0x00007f7266032000)


Persistence of Vision(tm) Ray Tracer Version 3.8.0-alpha.11272893.unofficial
(g++ 9 @ x86_64-pc-linux-gnu)
  OpenEXR 2.3.0 and IlmBase, Copyright (c) 2002-2011 Industrial Light & Magic.
  ldd unix/povray
        libIlmImf-2_3.so.24 => /lib/x86_64-linux-gnu/libIlmImf-2_3.so.24
(0x00007fa2290b8000)
        libHalf.so.24 => /lib/x86_64-linux-gnu/libHalf.so.24
(0x00007fa229073000)
        libIex-2_3.so.24 => /lib/x86_64-linux-gnu/libIex-2_3.so.24
(0x00007fa229052000)
        libIlmThread-2_3.so.24 => /lib/x86_64-linux-gnu/libIlmThread-2_3.so.24
(0x00007fa2285e1000)


So that seems to be working. What is the best way forward with the changed
files, ax_check_openexr.m4, povray.cpp and openexr.cpp?


Post a reply to this message

From: clipka
Subject: Re: OpenEXR 3.x issues - call to arms
Date: 15 Jun 2021 08:51:41
Message: <60c8a25d$1@news.povray.org>
Am 15.06.2021 um 06:29 schrieb Ton:

> So that seems to be working. What is the best way forward with the changed
> files, ax_check_openexr.m4, povray.cpp and openexr.cpp?

Thanks, much appreciated!

Ideally, you'd set up a Git pull request for the `POV-Ray/povray` 
repository, based on the `release/v3.7.0` branch (NOT `master`); and if 
you feel like it, do the same based on the `release/v3.8.0` branch as 
well (again NOT `master`), but I reckon it should be easy to port the 
change over to v3.8 once it's in the Git repo.

If Git is not your sort of thing, please attach the files (complete - no 
diffs please!) to a post over at `povray.binaries.programming`, 
mentioning in the post what version you took the original files from. 
Ideally someone else can take it from there and turn it into a pull 
request or two - if not, I'll probably be able to find some time to take 
it from there myself eventually.


Post a reply to this message

Goto Latest 10 Messages Next 3 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.