While you can certainly use .pic for Softimage, .iff for Maya and so on, when you're in a large scale mixed application environment you'll have to constantly convert images from format to format to make them compatible for the end use case. That is what people want to avoid most as it's a time consuming hassle and duplication of data which leads to other ancillary issues such as asset dependencies going out of sync with the asset which references them.
As I said earlier, asset management, web tools, etc. often do not support .pic or .iff and other 3D application specific file formats. They stick to vanilla .tga, .jpg, .png, .bmp, and sometimes .tif. Users are tired of waiting for file format compatibility from each application or trying to find the happy medium in between. If the DCC application can accommodate those vanilla formats and still meet the project requirements, then users will do that as it's the path of lesser resistance. Personally, I would love to use .pic as it compresses very well (better than .jpg), but reality is it's not receiving any love. I looked at the .pic SDK in the past and remember seeing extensions in place for shadows, matte, and other channels, but it's all still 8-bit. I think there's a header section for defining new things like bit depth, but new routines would need to be written to support the changes. It could be done, but at that point you're practically writing a new file format. Matt From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Ponthieux, Joey Sent: Friday, November 16, 2012 2:32 PM To: softimage@listproc.autodesk.com Subject: Re: 16 bit tif from photoshop not working in softimage? But am i incorrect in the assumption that of all those formats Pic is the only format the Softimage developers have full control over? IE they have the ability to modify its structure at will? Doesn't that classify it as native to Softimage? I realize that when the image library .so was made available what...back in 99?...we were able to access other formats and that in XSI it really is more transparent than in SI3D. But the question really wasn't.... why did Softimage decide to label this very standard run length encoded rgb image which isn't all that much different than .rgb or .sgi as the Softimage default. The question is what advantages do these other formats, with all their risky "extras", provide the user to warrant the risk? So far I've gotten 16-bit support as a significant reason. Everything else is about ease of use in the browser, thumbnails etc, or photoshop hates pic. Those aren't compelling reasons to offset the risks. When PSD files first became available to use in Softimage I gave up trying to get these things to work reliably all the time. Same for tiff. Lzw or not lzw, that is the question. How does all that affect things if you plan on using mipmaps? There is too much extra stuff in these high order image formats. Does any of this extra "stuff" provide an advantage that outweighs the risk that an image might load, acts like its gonna work fine, but decides to crap out at 3am when just the right(or wrong) scene conditions occur. I can think of no time when pic ever failed me in Soft. Bear in mind this is a philosophy that I developed over decades from experiences on SGI and with other apps than just Softimage. I decided somewhere along the way that sleep was more important than the fact that I could use a PSD file. In Soft I only use pic. In Maya i use iff and converted to mipmaps, especially on large stuff. So granted I am working from a legacy mindset. However, I kinda would like to know has something changed dramatically enough to make this level of risk more worthwhile, even though I seriously doubt that stability from these non default formats has improved any. We wouldn't be having this conversation otherwise. Joey Ponthieux LaRC Information Technology Enhanced Services (LITES) Mymic Technical Services NASA Langley Research Center ____________________________________________________________ Opinions stated here-in are strictly those of the author and do not represent the opinions of NASA or any other party. On 11/16/2012 4:20 PM, Luc-Eric Rousseau wrote: XSI really doesn't have a "Native format", it just has a default value in the rendering ppg .pic is just a file format like the others; there is no additional conversion when using the other format in Softimage, or loss of meta-data. All the image file formats in softimage have the API. Plus, if you're rendering with mental ray.. .it's just one of the format mental ray supports. It was kind of native in Softimage|3D's renderer. In XSI, .pic is just the file format default due to inertia and fear of change. On Fri, Nov 16, 2012 at 3:25 PM, Ponthieux, Joey <j.ponthi...@nasa.gov<mailto:j.ponthi...@nasa.gov>> wrote: I guess what I am really curious about is why there is so much interest by folks in using these non-native formats which are filled with all sorts of extra stuff such as layers, channels, paths, metadata, and potentially incompatible compressions schemes. Do they provide seriously important value over the native formats(pic in Softimage, iff in Maya) to warrant the risks?
