Actually, it was developed by LBNL (or by other contractors for LBNL),
and licensed to me as part of "the computer program(s) described in
attached exhibit A and known as Radiance (LBNL reference number
CR-1266/1387/1667/1668/1669)".
But that only reinforces your point, so I'll go with your statement.
That brings us to the practical questions.
Should I just commit two new subdirectories to CVS?
But that would probably be the most "official" solution.
It's not production code at the moment, and most certainly won't even
compile with the current version of Radiance. I'd rather treat it as
a kind of rock quarry of concepts and ideas to use when doing it right.
It won't interact with any of the build systems though, and maybe it
doesn't need to be included in the nightly HEAD downloads either.
-schorsch
PS: Darn, just started snowing again here...
···
Am 2016-03-15 03:40, schrieb Gregory J. Ward:
The sources to both winrview and winimage are sitting here on my
disk. I don't think the DR team changed anything relevant after
my fixes.
Unfortunately, my old contract with LBNL does not cover
redistribution in source form. To make this possible, we'd need
some statement from them that those programs can be considered a
part of the normal Radiance distribution and fall under the
"Radiance open source license".
@Greg, are you entitled to make such a statement?
I think so. I'm generally the gatekeeper to the Radiance source tree,
and can "welcome" new code that is offered. Since LBNL contracted you
to develop it in the first place from what you say, this should not
present a problem.
--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/
Hi Georg,
I vaguely remember winrview as being somewhat buggy. Did you fix it up? Does it offer advantages to Windows users over the current qt-based interface? Similarly, is the winimage program superior to what Windows folks are using now?
I don't want to welcome back something that's going to be more trouble than it's worth, now that I've been told *we* developed it....
Cheers,
-Greg
···
From: Georg Mischler <[email protected]>
Subject: [Radiance-dev] Winrview and Winimage sources
Date: March 15, 2016 3:55:10 AM PDT
Am 2016-03-15 03:40, schrieb Gregory J. Ward:
The sources to both winrview and winimage are sitting here on my
disk. I don't think the DR team changed anything relevant after
my fixes.
Unfortunately, my old contract with LBNL does not cover
redistribution in source form. To make this possible, we'd need
some statement from them that those programs can be considered a
part of the normal Radiance distribution and fall under the
"Radiance open source license".
@Greg, are you entitled to make such a statement?
I think so. I'm generally the gatekeeper to the Radiance source tree,
and can "welcome" new code that is offered. Since LBNL contracted you
to develop it in the first place from what you say, this should not
present a problem.
Actually, it was developed by LBNL (or by other contractors for LBNL),
and licensed to me as part of "the computer program(s) described in
attached exhibit A and known as Radiance (LBNL reference number
CR-1266/1387/1667/1668/1669)".
But that only reinforces your point, so I'll go with your statement.
That brings us to the practical questions.
Should I just commit two new subdirectories to CVS?
But that would probably be the most "official" solution.
It's not production code at the moment, and most certainly won't even
compile with the current version of Radiance. I'd rather treat it as
a kind of rock quarry of concepts and ideas to use when doing it right.
It won't interact with any of the build systems though, and maybe it
doesn't need to be included in the nightly HEAD downloads either.
-schorsch
PS: Darn, just started snowing again here...
I did fix winrview as well as I could back then. It has a more
complete and smoothely working user interface than the NREL winrvu.
All that provided someone gets it to work with the current Radiance
release, of course.
As far as I am aware, there is no other standalone image viewer
available on Windows. Winimage will require some fixing though, my old
binaries seem to have trouble recognizing the magic scanline header
in the files. But I'm pretty sure that DR used to include a working
version, so that shouldn't be too hard.
Both have a native Windows-GUI, which can be seen as an advantage (no
thirdparty libraries required) or a disadvantage (not portable to other
systems).
Both of them could either find a new life as working programs in the
distribution, or later be scrapped again after all the useful parts have
been scavenged for reuse in other solutions. And don't worry, nobody
will be blaming you for either possible outcome... 
For the moment the repository would just be the most convenient place
for interested developers to access and fix the sources.
-schorsch
···
Am 2016-03-15 14:36, schrieb Gregory J. Ward:
Hi Georg,
I vaguely remember winrview as being somewhat buggy. Did you fix it
up? Does it offer advantages to Windows users over the current
qt-based interface? Similarly, is the winimage program superior to
what Windows folks are using now?
I don't want to welcome back something that's going to be more trouble
than it's worth, now that I've been told *we* developed it....
Cheers,
-Greg
From: Georg Mischler <[email protected]>
Subject: [Radiance-dev] Winrview and Winimage sources
Date: March 15, 2016 3:55:10 AM PDT
Am 2016-03-15 03:40, schrieb Gregory J. Ward:
The sources to both winrview and winimage are sitting here on my
disk. I don't think the DR team changed anything relevant after
my fixes.
Unfortunately, my old contract with LBNL does not cover
redistribution in source form. To make this possible, we'd need
some statement from them that those programs can be considered a
part of the normal Radiance distribution and fall under the
"Radiance open source license".
@Greg, are you entitled to make such a statement?
I think so. I'm generally the gatekeeper to the Radiance source tree,
and can "welcome" new code that is offered. Since LBNL contracted you
to develop it in the first place from what you say, this should not
present a problem.
Actually, it was developed by LBNL (or by other contractors for LBNL),
and licensed to me as part of "the computer program(s) described in
attached exhibit A and known as Radiance (LBNL reference number
CR-1266/1387/1667/1668/1669)".
But that only reinforces your point, so I'll go with your statement.
That brings us to the practical questions.
Should I just commit two new subdirectories to CVS?
But that would probably be the most "official" solution.
It's not production code at the moment, and most certainly won't even
compile with the current version of Radiance. I'd rather treat it as
a kind of rock quarry of concepts and ideas to use when doing it right.
It won't interact with any of the build systems though, and maybe it
doesn't need to be included in the nightly HEAD downloads either.
-schorsch
PS: Darn, just started snowing again here...
_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev
--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/
As far as I am aware, there is no other standalone image viewer
available on Windows.
I use HDRView.exe under Windows. It used to be available on Paul
Debevec's site, but is no longer. I send him an email a couple of
years ago, asking him whether he'd allow me to pass it on, but I did
not receive a reply. HDRView is still available on some rather
obscure sites. It's lightning fast, allows you to zoom in and out,
and to adjust the exposure with the +/- keys.
Cheers
Axel
On Windows, I used to use Picturenaut, which I liked a lot, but lately it's
been giving me library issues. No one else is complaining about that on
their forum, though, so it could just be a problem with my system.
Now I'm using Mitsuba, which is also a full-blown open source renderer but
has the ability to open and tonemap a variety of HDR image formats and is
very quick. I miss being able to get luminance/radiance values by mousing
over the image, though.
Nathaniel
···
On Tue, Mar 15, 2016 at 1:30 PM, Axel Jacobs <[email protected]> wrote:
> As far as I am aware, there is no other standalone image viewer
> available on Windows.
I use HDRView.exe under Windows. It used to be available on Paul
Debevec's site, but is no longer. I send him an email a couple of
years ago, asking him whether he'd allow me to pass it on, but I did
not receive a reply. HDRView is still available on some rather
obscure sites. It's lightning fast, allows you to zoom in and out,
and to adjust the exposure with the +/- keys.
Cheers
Axel
_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev
"I miss being able to get luminance/radiance values by mousing over the
image, though."
Sigh. "If we had..."
Hi,
There is our tool RadDisplay, which shows values when mousing over image.
On site there is rather old version of tool, but still does basic image
exploration http://deluminaelab.com/en/raddisplay_details.html
We are preparing new version of web site, and have in some plan to release
newer version of RadDisplay soon.
Marija
···
On Tue, Mar 15, 2016 at 7:26 PM, Randolph M. Fritz <[email protected]> wrote:
"I miss being able to get luminance/radiance values by mousing over the
image, though."
Sigh. "If we had..."
_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev
Just shows that I've been away from Radiance for too long, and didn't
follow closely enough what other people are doing.
RadDisplay looks very nice and useful! That's the direction I wouldd have
liked to take the old viever in Rayfront (given the time I didn't have).
But my ignorance was only a minor point in the current discussion.
The real question was if it would be interesting to have a native viewer
for Windows in the Radiance source repository and distribution.
Everybody else has ximage, but Windows users need to find an external
solution to even just look at a picture. This is about providing the
most elementary basics, and not about competing with other people's
more advanced tools.
Winimage is very simple, and still needs fixing for robustness.
It is designed to:
* display hdr pictures
* offer simple analysis (by calling falsecolor and friends)
* store images in a small number of other formats
After I tweaked the sources a bit to conform to the current C++ standards,
it currently builds with both Visual Studio 2015 and SCons.
It has no thirdparty dependencies at all.
The only "basic" feature currently missing is displaying luminance values
by picking or hovering over the picture. I haven't checked yet how easy
it would be to add this, but I expect someone would find a solution.
-schorsch
···
Am 2016-03-16 09:18, schrieb Marija Velickovic:
Hi,
There is our tool RadDisplay, which shows values when mousing over
image.
On site there is rather old version of tool, but still does basic
image exploration http://deluminaelab.com/en/raddisplay_details.html
[2]
We are preparing new version of web site, and have in some plan to
release newer version of RadDisplay soon.
Marija
On Tue, Mar 15, 2016 at 7:26 PM, Randolph M. Fritz > <[email protected]> wrote:
"I miss being able to get luminance/radiance values by mousing over
the image, though."
Sigh. "If we had..."
--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/
Hi All,
It would be great if you guys could pool resources and decide which tool to advance as the standard Radiance picture viewer for Windows. Then, we could re-introduce it to the source tree and keep it up to date in future releases. Likewise for rvu, which I would prefer to be a driver connected using the existing call mechanism.
Cheers,
-Greg
···
From: Georg Mischler <[email protected]>
Subject: Re: [Radiance-dev] Winrview and Winimage sources
Date: March 16, 2016 4:59:48 AM PDT
Just shows that I've been away from Radiance for too long, and didn't
follow closely enough what other people are doing.
RadDisplay looks very nice and useful! That's the direction I wouldd have
liked to take the old viever in Rayfront (given the time I didn't have).
But my ignorance was only a minor point in the current discussion.
The real question was if it would be interesting to have a native viewer
for Windows in the Radiance source repository and distribution.
Everybody else has ximage, but Windows users need to find an external
solution to even just look at a picture. This is about providing the
most elementary basics, and not about competing with other people's
more advanced tools.
Winimage is very simple, and still needs fixing for robustness.
It is designed to:
* display hdr pictures
* offer simple analysis (by calling falsecolor and friends)
* store images in a small number of other formats
After I tweaked the sources a bit to conform to the current C++ standards,
it currently builds with both Visual Studio 2015 and SCons.
It has no thirdparty dependencies at all.
The only "basic" feature currently missing is displaying luminance values
by picking or hovering over the picture. I haven't checked yet how easy
it would be to add this, but I expect someone would find a solution.
-schorsch
Am 2016-03-16 09:18, schrieb Marija Velickovic:
Hi,
There is our tool RadDisplay, which shows values when mousing over
image.
On site there is rather old version of tool, but still does basic
image exploration http://deluminaelab.com/en/raddisplay_details.html
[2]
We are preparing new version of web site, and have in some plan to
release newer version of RadDisplay soon.
Marija
On Tue, Mar 15, 2016 at 7:26 PM, Randolph M. Fritz >> <[email protected]> wrote:
"I miss being able to get luminance/radiance values by mousing over
the image, though."
Sigh. "If we had..."
--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/
Agreed, this is awesome, even if it means turning away from qtrvu. Qt is a
rather onerous dependency, especially to support just one program in all of
Radiance. Most of what Schorsch has to say here is sailing over my head,
but I'm happy to help update the CMake build system to support whatever
ends up getting added and/or dropped here.
Same for testing; any tests for scons should probably be "ported" to CMake
and vice versa, assuming each testing framework has the the other's
ability...
···
On Wed, Mar 16, 2016 at 9:48 AM, Gregory J. Ward <[email protected]> wrote:
Hi All,
It would be great if you guys could pool resources and decide which tool
to advance as the standard Radiance picture viewer for Windows. Then, we
could re-introduce it to the source tree and keep it up to date in future
releases. Likewise for rvu, which I would prefer to be a driver connected
using the existing call mechanism.
Cheers,
-Greg
> From: Georg Mischler <[email protected]>
> Subject: Re: [Radiance-dev] Winrview and Winimage sources
> Date: March 16, 2016 4:59:48 AM PDT
>
> Just shows that I've been away from Radiance for too long, and didn't
> follow closely enough what other people are doing.
> RadDisplay looks very nice and useful! That's the direction I wouldd have
> liked to take the old viever in Rayfront (given the time I didn't have).
>
> But my ignorance was only a minor point in the current discussion.
> The real question was if it would be interesting to have a native viewer
> for Windows in the Radiance source repository and distribution.
> Everybody else has ximage, but Windows users need to find an external
> solution to even just look at a picture. This is about providing the
> most elementary basics, and not about competing with other people's
> more advanced tools.
>
> Winimage is very simple, and still needs fixing for robustness.
> It is designed to:
> * display hdr pictures
> * offer simple analysis (by calling falsecolor and friends)
> * store images in a small number of other formats
> After I tweaked the sources a bit to conform to the current C++
standards,
> it currently builds with both Visual Studio 2015 and SCons.
> It has no thirdparty dependencies at all.
>
> The only "basic" feature currently missing is displaying luminance values
> by picking or hovering over the picture. I haven't checked yet how easy
> it would be to add this, but I expect someone would find a solution.
>
> -schorsch
>
>
> Am 2016-03-16 09:18, schrieb Marija Velickovic:
>> Hi,
>> There is our tool RadDisplay, which shows values when mousing over
>> image.
>> On site there is rather old version of tool, but still does basic
>> image exploration http://deluminaelab.com/en/raddisplay_details.html
>> [2]
>> We are preparing new version of web site, and have in some plan to
>> release newer version of RadDisplay soon.
>> Marija
>> On Tue, Mar 15, 2016 at 7:26 PM, Randolph M. Fritz > >> <[email protected]> wrote:
>>> "I miss being able to get luminance/radiance values by mousing over
>>> the image, though."
>>> Sigh. "If we had..."
>
> --
> Georg Mischler -- simulations developer -- schorsch at schorsch com
> +schorsch.com+ -- lighting design tools -- http://www.schorsch.com/
>
_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev
Why is Qt an especially onerous dependency? It's LGPL and pretty common.
···
--
Randolph M. Fritz, Lighting Design and Simulation
+1 206 659-8617 || [email protected]
On Wed, Mar 16, 2016 at 9:00 AM, Rob Guglielmetti < [email protected]> wrote:
Agreed, this is awesome, even if it means turning away from qtrvu. Qt is a
rather onerous dependency, especially to support just one program in all of
Radiance. Most of what Schorsch has to say here is sailing over my head,
but I'm happy to help update the CMake build system to support whatever
ends up getting added and/or dropped here.
Same for testing; any tests for scons should probably be "ported" to CMake
and vice versa, assuming each testing framework has the the other's
ability...
On Wed, Mar 16, 2016 at 9:48 AM, Gregory J. Ward <[email protected]> > wrote:
Hi All,
It would be great if you guys could pool resources and decide which tool
to advance as the standard Radiance picture viewer for Windows. Then, we
could re-introduce it to the source tree and keep it up to date in future
releases. Likewise for rvu, which I would prefer to be a driver connected
using the existing call mechanism.
Cheers,
-Greg
> From: Georg Mischler <[email protected]>
> Subject: Re: [Radiance-dev] Winrview and Winimage sources
> Date: March 16, 2016 4:59:48 AM PDT
>
> Just shows that I've been away from Radiance for too long, and didn't
> follow closely enough what other people are doing.
> RadDisplay looks very nice and useful! That's the direction I wouldd
have
> liked to take the old viever in Rayfront (given the time I didn't have).
>
> But my ignorance was only a minor point in the current discussion.
> The real question was if it would be interesting to have a native viewer
> for Windows in the Radiance source repository and distribution.
> Everybody else has ximage, but Windows users need to find an external
> solution to even just look at a picture. This is about providing the
> most elementary basics, and not about competing with other people's
> more advanced tools.
>
> Winimage is very simple, and still needs fixing for robustness.
> It is designed to:
> * display hdr pictures
> * offer simple analysis (by calling falsecolor and friends)
> * store images in a small number of other formats
> After I tweaked the sources a bit to conform to the current C++
standards,
> it currently builds with both Visual Studio 2015 and SCons.
> It has no thirdparty dependencies at all.
>
> The only "basic" feature currently missing is displaying luminance
values
> by picking or hovering over the picture. I haven't checked yet how easy
> it would be to add this, but I expect someone would find a solution.
>
> -schorsch
>
>
> Am 2016-03-16 09:18, schrieb Marija Velickovic:
>> Hi,
>> There is our tool RadDisplay, which shows values when mousing over
>> image.
>> On site there is rather old version of tool, but still does basic
>> image exploration http://deluminaelab.com/en/raddisplay_details.html
>> [2]
>> We are preparing new version of web site, and have in some plan to
>> release newer version of RadDisplay soon.
>> Marija
>> On Tue, Mar 15, 2016 at 7:26 PM, Randolph M. Fritz >> >> <[email protected]> wrote:
>>> "I miss being able to get luminance/radiance values by mousing over
>>> the image, though."
>>> Sigh. "If we had..."
>
> --
> Georg Mischler -- simulations developer -- schorsch at schorsch com
> +schorsch.com+ -- lighting design tools -- http://www.schorsch.com/
>
_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev
_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev
Because it's so fuc*ing big.
···
On 3/16/16, 1:51 PM, "Randolph M. Fritz" <[email protected]<mailto:[email protected]>> wrote:
Why is Qt an especially onerous dependency? It's LGPL and pretty common.
Why is Qt an especially onerous dependency? It's LGPL and pretty common.
···
On 3/16/16, 1:51 PM, "Randolph M. Fritz" <[email protected]<mailto: [email protected]>> wrote:
On Wed, Mar 16, 2016 at 12:54 PM, Guglielmetti, Robert < [email protected]> wrote:
Because it's so fuc*ing big.
When 2 GB RAM is standard for a low-end system is that important?
Randolph
But the Radiance source is 3 MB, and Qt 5.6 for Windows is 836 MB. Radiance's dependency list is short and small excepting the Qt requirement for qtrvu. It's kinda nice. Maybe I'm making too much of this. I dunno.
···
On 3/16/16, 2:00 PM, "Randolph M. Fritz" <[email protected]<mailto:[email protected]>> wrote:
On 3/16/16, 1:51 PM, "Randolph M. Fritz" <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> wrote:
Why is Qt an especially onerous dependency? It's LGPL and pretty common.
On Wed, Mar 16, 2016 at 12:54 PM, Guglielmetti, Robert <[email protected]<mailto:[email protected]>> wrote:
Because it's so fuc*ing big.
When 2 GB RAM is standard for a low-end system is that important?
Randolph
I see three topics there:
Image viewer
Do we actually have another option for that on Windows?
What does OpenStudio use?
On a side note: The next Gimp version (3.10, currently in beta as
3.9.2) should be able to open HDR files. Though I suspect it will
not include the tonemapping algorithms or other analysis
functionality that we need here.
Second side note: I just saw that the NREL binary package still
has its image files as *.pic instead of *.hdr, is this deliberate?
Preview renderer
First I'll have to try and get Winrview running again...
Once we know it actually still works, I think Rob will be in the best
position to make a judgement on which one (or which combination) fits
the purpose best, and will be easier to grow more functionality with
in the future.
I never looked at that "driver/output device" mechanism very closely.
I think that in those cases where the "device" is actually a seperate
program, whichever rvu executable got invoked first with that option
will just hand over the job to its named sibling (that seems to be
how qtrview works on unix right now). Unless I'm missing some detail,
I don't think that will be a problem, even if there will probably be
only one device available on Windows for now.
Test suite unification
I think that one better goes into a seperate thread.
-schorsch
···
Am 2016-03-16 17:00, schrieb Rob Guglielmetti:
Agreed, this is awesome, even if it means turning away from qtrvu. Qt
is a rather onerous dependency, especially to support just one program
in all of Radiance. Most of what Schorsch has to say here is sailing
over my head, but I'm happy to help update the CMake build system to
support whatever ends up getting added and/or dropped here.
Same for testing; any tests for scons should probably be "ported" to
CMake and vice versa, assuming each testing framework has the the
other's ability...
On Wed, Mar 16, 2016 at 9:48 AM, Gregory J. Ward > <[email protected]> wrote:
Hi All,
It would be great if you guys could pool resources and decide which
tool to advance as the standard Radiance picture viewer for Windows.
Then, we could re-introduce it to the source tree and keep it up to
date in future releases. Likewise for rvu, which I would prefer to
be a driver connected using the existing call mechanism.
Cheers,
-Greg
From: Georg Mischler <[email protected]>
Subject: Re: [Radiance-dev] Winrview and Winimage sources
Date: March 16, 2016 4:59:48 AM PDT
Just shows that I've been away from Radiance for too long, and
didn't
follow closely enough what other people are doing.
RadDisplay looks very nice and useful! That's the direction I
wouldd have
liked to take the old viever in Rayfront (given the time I didn't
have).
But my ignorance was only a minor point in the current discussion.
The real question was if it would be interesting to have a native
viewer
for Windows in the Radiance source repository and distribution.
Everybody else has ximage, but Windows users need to find an
external
solution to even just look at a picture. This is about providing
the
most elementary basics, and not about competing with other
people's
more advanced tools.
Winimage is very simple, and still needs fixing for robustness.
It is designed to:
* display hdr pictures
* offer simple analysis (by calling falsecolor and friends)
* store images in a small number of other formats
After I tweaked the sources a bit to conform to the current C++
standards,
it currently builds with both Visual Studio 2015 and SCons.
It has no thirdparty dependencies at all.
The only "basic" feature currently missing is displaying luminance
values
by picking or hovering over the picture. I haven't checked yet how
easy
it would be to add this, but I expect someone would find a
solution.
-schorsch
Am 2016-03-16 09:18, schrieb Marija Velickovic:
Hi,
There is our tool RadDisplay, which shows values when mousing
over
image.
On site there is rather old version of tool, but still does basic
image exploration
http://deluminaelab.com/en/raddisplay_details.html [1]
[2]
We are preparing new version of web site, and have in some plan
to
release newer version of RadDisplay soon.
Marija
On Tue, Mar 15, 2016 at 7:26 PM, Randolph M. Fritz >>>> <[email protected]> wrote:
"I miss being able to get luminance/radiance values by mousing
over
the image, though."
Sigh. "If we had..."
--
Georg Mischler -- simulations developer -- schorsch at
schorsch com
+schorsch.com [2]+ -- lighting design tools --
http://www.schorsch.com/ [3]
_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev [4]
Links:
------
[1] http://deluminaelab.com/en/raddisplay_details.html
[2] http://schorsch.com
[3] http://www.schorsch.com/
[4] http://www.radiance-online.org/mailman/listinfo/radiance-dev
_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev
--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/
I see what you mean. Even as binaries those are a hefty dependency.
*Any* dependency is "onerous", if it can be avoided with reasonable effort.
It doesn't necessarily matter for the end user, if they are provided
with an installer including everything. But when developing and maintaining
code, any small thing you need to include from external sources is like
a ball and chain. Even something small and simple like the tifflib has
caused a surprising amount of headaches for Radiance.
The standard trade-off for GUIs is OS dependency vs. toolkit dependency.
Since we already have a working solution for all other sytems, we can
focus on Windows here. Of course it would be *nice* to have something
platform-independent. But with our limited resources, the added maintenance
headaches may not be worth it in this specific case.
-schorsch
···
Am 2016-03-16 21:00, schrieb Randolph M. Fritz:
On 3/16/16, 1:51 PM, "Randolph M. Fritz" > <[email protected]<mailto:[email protected]>> wrote:
Why is Qt an especially onerous dependency? It's LGPL and pretty
common.
On Wed, Mar 16, 2016 at 12:54 PM, Guglielmetti, Robert > <[email protected]> wrote:
Because it's so fuc*ing big.
When 2 GB RAM is standard for a low-end system is that important?
--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/
While rvu can (and historically has) executed a driver as an independent process, it is supposed to communicate with that driver via a couple of pipes. I didn't realize that it handed over execution to qtrvu. There is a "slave mode" that reverses operation, permitting the display driver to call rvu as the parent process -- is that what qtrvu is doing, or does it copy all the sources for rendering or call the raycalls.c? I guess I should familiarize myself with that source tree, but I've just been ignoring it up until now...
-Greg
···
From: Georg Mischler <[email protected]>
Subject: Re: [Radiance-dev] Winrview and Winimage sources
Date: March 16, 2016 1:10:33 PM PDT
I see three topics there:
Image viewer
Do we actually have another option for that on Windows?
What does OpenStudio use?
On a side note: The next Gimp version (3.10, currently in beta as
3.9.2) should be able to open HDR files. Though I suspect it will
not include the tonemapping algorithms or other analysis
functionality that we need here.
Second side note: I just saw that the NREL binary package still
has its image files as *.pic instead of *.hdr, is this deliberate?
Preview renderer
First I'll have to try and get Winrview running again...
Once we know it actually still works, I think Rob will be in the best
position to make a judgement on which one (or which combination) fits
the purpose best, and will be easier to grow more functionality with
in the future.
I never looked at that "driver/output device" mechanism very closely.
I think that in those cases where the "device" is actually a seperate
program, whichever rvu executable got invoked first with that option
will just hand over the job to its named sibling (that seems to be
how qtrview works on unix right now). Unless I'm missing some detail,
I don't think that will be a problem, even if there will probably be
only one device available on Windows for now.
Test suite unification
I think that one better goes into a seperate thread.
-schorsch
I think the pipe approach is a good one. A separation of UI and
computational functions is probably a good way to organize the code, when
it is possible.
I don't think I'm gonna touch (or even try to understand) that driver
business. On Windows, preview renderers have traditionally always been
native reimplementations of rvu. Rob is free to change that, of course...
-schorsch
···
Am 2016-03-16 21:43, schrieb Gregory J. Ward:
While rvu can (and historically has) executed a driver as an
independent process, it is supposed to communicate with that driver
via a couple of pipes. I didn't realize that it handed over execution
to qtrvu. There is a "slave mode" that reverses operation, permitting
the display driver to call rvu as the parent process -- is that what
qtrvu is doing, or does it copy all the sources for rendering or call
the raycalls.c? I guess I should familiarize myself with that source
tree, but I've just been ignoring it up until now...
-Greg
From: Georg Mischler <[email protected]>
Subject: Re: [Radiance-dev] Winrview and Winimage sources
Date: March 16, 2016 1:10:33 PM PDT
I see three topics there:
Image viewer
Do we actually have another option for that on Windows?
What does OpenStudio use?
On a side note: The next Gimp version (3.10, currently in beta as
3.9.2) should be able to open HDR files. Though I suspect it will
not include the tonemapping algorithms or other analysis
functionality that we need here.
Second side note: I just saw that the NREL binary package still
has its image files as *.pic instead of *.hdr, is this deliberate?
Preview renderer
First I'll have to try and get Winrview running again...
Once we know it actually still works, I think Rob will be in the best
position to make a judgement on which one (or which combination) fits
the purpose best, and will be easier to grow more functionality with
in the future.
I never looked at that "driver/output device" mechanism very closely.
I think that in those cases where the "device" is actually a seperate
program, whichever rvu executable got invoked first with that option
will just hand over the job to its named sibling (that seems to be
how qtrview works on unix right now). Unless I'm missing some detail,
I don't think that will be a problem, even if there will probably be
only one device available on Windows for now.
Test suite unification
I think that one better goes into a seperate thread.
-schorsch
_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev
--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/
