Re: [Blender to RenderMan:366] Re: Get Blender Image Map To Show Up In Aqsis Render via Mosaic?

[Chris Foster-5]

(Cc'd to the aqsis-development list; the rest of this thread may be found on
the blender to renderman mailing list archives at
http://groups.google.com/group/blendertorenderman?pli=1  )

On Tue, Aug 11, 2009 at 5:55 AM,

>WHiTeRaBBiT<<whiterabbit@...> wrote:
> Sounds like valid points to me, also having a wider support for image
> formats would help Aqsis stand out in the RenderMan crowd. Maybe if
> the developers are interested, and the current round of more critical
> bug fixes and release is done, someone will take it on? One potential
> headache I can image for the developers though is how well different
> formats could actually be supported, I know I've run into real
> headaches dealing with compatibility between my current favorite apps
> (gimp, cinepaint, inkscape, blender).
>
> Anyway it may also be a good idea to log this in as an official
> feature request so they don't forget about it later ;)
> http://sourceforge.net/tracker/?group_id=25264&atid=383973
>
> Eric
>
> On Aug 10, 3:37 pm, Atom <atomicpercept...@...> wrote:
>> I apologize if I come off sounding too crass. I am just offering up my
>> end-user-experience with Aqsis.
>>
>> The main reason I don't want to convert all my image maps is because I
>> am using other render systems and I already have other scenes linked
>> to those image maps in my library. File space is also a concern (as
>> always). So in a perfect place, yes, I could convert everything, but
>> in my realistic space, I really don't want to re-link all those other
>> scenes.

Fair enough, I think this is quite a good reason to want arbitrary texture
support - I can imagine how much of a pain it would be to relink all your
existing scenes, and I presume it's not easily scriptable at all.

Luckily, I've just thought of a way to provide arbitrary texture loading which
might actually be quite easy for us.  So easy in fact that I could probably
implement it today :-)  How about this:

When a texture file is opened, we first attmpt to open it with the native
image loading interface.  At the moment we only support TIFF, OpenEXR, and the
aqsis zfile format natively.  If we can open the image, all is well.  OTOH,
when the image format is unrecognised, we call through to a user-defined
external application to convert the texture to TIFF.

I think this behaviour should be set to off by default for predictability and
safety.  To specify the external converter application, the user should set an
RiOption, something like:

Option "texture" "string converter" "<converter_executable_name> %I %O"

Where %I is the input file name, and %O is the output file name (possibly just
equal to %I with a .tif appended?) If I wanted to use the "convert" program
from the imagemagick tools, I'd just replace <converter_executable_name> with
"convert".

A remaining issue would be whether we just want this to work for
MakeTexture-like interface calls (and in teqser), or whether it should also
work for textures which are referenced by texture() calls in the shading
language.  I think that having it work only with MakeTexture would be
sufficient because people shouldn't really be using non-optimized textures in
the texture() function anyway.

Thoughts and opinions please :-)  Is this a good idea?  How about the
proposed interface - in particular the naming of the "texture" "converter"
option?  Note that this is more of a workaround than a permanent fix, but it
may be very useful to tide us over until we have better native image support
for common formats.  Furthermore, we're never going to be able to support
every format under the sun, so it will probably remain useful in the future.

~Chris.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Aqsis-development mailing list
Aqsis-development@...
https://lists.sourceforge.net/lists/listinfo/aqsis-development

[Jonathan Merritt-2]

Hi Chris,

On 11/08/2009, at 11:35 AM, Chris Foster wrote:
> (Cc'd to the aqsis-development list; the rest of this thread may be  
> found on
> the blender to renderman mailing list archives at
> http://groups.google.com/group/blendertorenderman?pli=1  )
>
<snip/>

> When a texture file is opened, we first attmpt to open it with the  
> native
> image loading interface.  At the moment we only support TIFF,  
> OpenEXR, and the
> aqsis zfile format natively.  If we can open the image, all is  
> well.  OTOH,
> when the image format is unrecognised, we call through to a user-
> defined
> external application to convert the texture to TIFF.
>
> I think this behaviour should be set to off by default for  
> predictability and
> safety.  To specify the external converter application, the user  
> should set an
> RiOption, something like:
>
> Option "texture" "string converter" "<converter_executable_name> %I  
> %O"
>
> Where %I is the input file name, and %O is the output file name  
> (possibly just
> equal to %I with a .tif appended?) If I wanted to use the "convert"  
> program
> from the imagemagick tools, I'd just replace  
> <converter_executable_name> with
> "convert".
>
> A remaining issue would be whether we just want this to work for
> MakeTexture-like interface calls (and in teqser), or whether it  
> should also
> work for textures which are referenced by texture() calls in the  
> shading
> language.  I think that having it work only with MakeTexture would be
> sufficient because people shouldn't really be using non-optimized  
> textures in
> the texture() function anyway.

I think this is a good solution.  The following advantages make it  
seem a great idea to me:
   1. The range of supported images immediately becomes arbitrarily  
large.
   2. It puts a minimum burden (in terms of functionality) on Aqsis  
itself.
   3. It will continue to work if native support for an image format  
is implemented, since the converter can then simply be ignored.  It  
will therefore be relatively future-proof.

The criticisms of the solution are those that go along with any  
dependency on an external program: we'll have path problems, cases  
where it works on some computers but not others (and Aqsis will take  
the blame for a missing imagemagick install or whatever), external  
programs may do stupid things in the format conversion, etc...  
However, I think those are relatively minor issues.

Are you still thinking of using OIIO eventually?  It has plugin  
support for a variety of image formats (and, we are told, "more to  
come"):
   http://openimageio.org/wiki/index.php?title=Main_Page

+1 for making it work only for MakeTexture et al... I can see a lot of  
advantages to having some kind of predictability in the images that  
are used while shading.

Jonathan Merritt.


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Aqsis-development mailing list
Aqsis-development@...
https://lists.sourceforge.net/lists/listinfo/aqsis-development

[Chris Foster-5]

On Tue, Aug 11, 2009 at 1:24 PM,

>WHiTeRaBBiT<<whiterabbit@...> wrote:
>
> Actually now that you mention it, this would be easiest just using a
> plain old shell script! Here's one that should work...
>
>
> #!/bin/bash
> #This script intercepts MOSAIC's texture optimizer call to Aqsis's
> teqser and autamatically converts input image to a tiff using
> imagemagick if necessary.
> #NOTE the imagemagick package is required to use this script!!
> #In MOSAIC go to "MOSAIC Setttings"->"Render Binary Preset Strings"-
>>"Tex Opt" and enter the following:  teqser_convert.sh <TEXIN>
> <TEXOUT> <WRAP>
> input=$1
> output=$2
> wrap=$3
> [[ !("$input" =~ ".tif") ]] && convert $input "convert.tif" &&
> input="convert.tif"
> teqser -wrap $wrap $input $output
>
>
> Just copy and save the above text as "teqser_convert.sh' and copy or
> link to your global binary folder (such as /usr/local/bin). Then
> follow the scripts comments above by entering the script into MOSAIC's
> "Tex Opt" binary string for the Aqsis preset. This will create a
> CUSTOM preset and save it to the registry. Any texture not a tif will
> automatically be converted to a tif before calling teqser. One huge
> problem however is this will only work in Linux, not sure how involved
> it would be to reproduce this in a dos batch? Another problem with
> this approach is some information could be lost depending on what
> format is being converted to a tif.

Good call Eric, this certainly solves the problem for use with Mosaic, and
it's renderer-independent to boot!

I'm wondering where that leaves my original suggestion - certainly I think
your script is better for use with MOSAIC, but maybe there's other
circumstances where my proposal would still make sense?  TBH I can't think of
any off the top of my head which would justify the extra complexity in the
aqsis code itself.

~Chris.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Aqsis-development mailing list
Aqsis-development@...
https://lists.sourceforge.net/lists/listinfo/aqsis-development

[Chris Foster-5]

On Tue, Aug 11, 2009 at 1:18 PM, Jonathan Merritt<merritt@...> wrote:

> Hi Chris,
>
> On 11/08/2009, at 11:35 AM, Chris Foster wrote:
>> [...]
>>
>> A remaining issue would be whether we just want this to work for
>> MakeTexture-like interface calls (and in teqser), or whether it
>> should also
>> work for textures which are referenced by texture() calls in the
>> shading
>> language.  I think that having it work only with MakeTexture would be
>> sufficient because people shouldn't really be using non-optimized
>> textures in
>> the texture() function anyway.
>
> I think this is a good solution.  The following advantages make it
> seem a great idea to me:
>   1. The range of supported images immediately becomes arbitrarily
> large.
>   2. It puts a minimum burden (in terms of functionality) on Aqsis
> itself.
>   3. It will continue to work if native support for an image format
> is implemented, since the converter can then simply be ignored.  It
> will therefore be relatively future-proof.
>
> The criticisms of the solution are those that go along with any
> dependency on an external program: we'll have path problems, cases
> where it works on some computers but not others (and Aqsis will take
> the blame for a missing imagemagick install or whatever), external
> programs may do stupid things in the format conversion, etc...

That's why I thought the default would be to have the feature off.  The user
could enable it if they knew what they were doing.

> However, I think those are relatively minor issues.
>
> Are you still thinking of using OIIO eventually?  It has plugin
> support for a variety of image formats (and, we are told, "more to
> come"):
>   http://openimageio.org/wiki/index.php?title=Main_Page

Definitely, I'm on the mailing list for OIIO, and am following the progress
closely.  In fact, I'm currently involved in the development in a minor way
(code reviews, design suggestions based on aqsistex experiances, and some
cmake build system code).

> +1 for making it work only for MakeTexture et al... I can see a lot of
> advantages to having some kind of predictability in the images that
> are used while shading.

Cool.  What do think about Eric's suggestion (forwarded) though?  It seems
like a wrapper around teqser may be a better option.

~Chris.

PS: I'm not sure what the etiquette for posting to multiple lists at once is.
I'm CC'ing all these posts to both lists so that everyone can follow the
conversation.  Apologies to the (hopefully few) people who are getting these
posts twice.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Aqsis-development mailing list
Aqsis-development@...
https://lists.sourceforge.net/lists/listinfo/aqsis-development