Hi!
I'm trying to put image as pict from photoshop in houdini>pic but it doesn't work even it puts flat color not an image or just don't read the format when the picture as texture is applied. What I do wrong, what I should do?
Thank you.

Hi Bosco, the pict/pic format that you are saving from Photoshop is not the same as Houdini's native .pic format. Why not save your texture to one of the more common formats such as tga, png, bmp, or jpg?

Thank you I'll try now

I did in tga the image snaps but the resolution is not good, which are the formats for best resolution?

Hey again Bosco. To be honest I'm not sure what you mean. Saving to a different format will not change the resolution of your texture. If your texture is not detailed enough when you render your object then you need to start off with a higher resolution texture to begin with.

If that's not what you mean, could you maybe upload a picture to show the problem?

I personally prefer .tiff's.

Tiff's are starting to go on my blacklist. So many issues with the headers between platforms and applications. For instance, here we go nuts because if we made the cardinal sin of outputting to tiff and someone on a Mac wants to import it, Houdini's header craps it out. Won't work. We can output to tga, but then there's a charming bug(IMHO) with Discreet products that causes unimaginable time slowdowns with decompression that mean a vid-res image will take 3-4 seconds to grab. Grrr.

Still haven't decided on the “perfect” format yet. “rla/rlb” seems to be dropping from favour in a lot of programs, tiff has compatibility problems, but if it weren't for that Discreet problem, tga would be my choice. Patiently waiting for the day when OEXR is the de facto standard, plain and simple.

Anyway, sorry to hijack…

It's possible Bosco has a vector import in Photoshop too - that isn't pixel-resolution dependant. But yup, I think you need to do a little reading-up Bosco - formats don't affect quality unless you're using a lossy compression, scheme, like jpeg.

Cheers,

J.C.

I'm starting to become a fan of PNGs.

They aren't as flexible as tiffs, but as a result its easier to support.

The compression is lossless, and it can compress smaller than the different tiff compression schemes.

PNGs support 4 channel (RGBA) in either 8bit or 16bits per channel. (Sadly no floating point.)

PNGs are kinda of a meeting area between gifs, jpeg, and tiffs.

There's no excuse for not properly supporting tiff files. There's public specs out there with a very good free platform independent implementation (libtiff) that has active community support. Someone even from Adobe is on the developer mailing list to help resolve issues. This is the first time I've heard of tiff header compatibility problems. The usual problem is that someone is still using a very old copy of libtiff that doesn't recognize the official AdobeDeflate codec type. In those cases, you can tell Houdini to output to a different codec. I would complain to your software vendor.

I think the problems are more prevalent than you think, Edward. There was a discussion about this on the 3dPro list a while back, lots of people are starting to get pissed with the tiff support out there. Too much politics, too many flavours. The default tiff output from Houdini does not load in Final Cut Pro. I can turn compression off, but that's a pain - slower network performance.

Cheers,

J.C.

The ability to define new, specific tags was actually one of the major features when tiff was introduced. It's a good feature to have for any format as long as vendors don't start saving required data in the tags. 3D Camera info is fine, a custom LUT to apply on read isn't. As soon as a vendor does this, the whole idea of the "Tagged interchangable file format" goes up in smoke.

TIFF is also gone through a ton of versions (I believe we support 6). This also causes problems since vendors usually have to play catch-up. The AdobeDeflate compression is one of those new features, as is LZW. Have you tried setting the default compression in Houdini to something other than AdobeDeflate in the FBoptions file? Might help compatibility to use ‘Standard Deflate’ or PackBits.

So yeah JC, I tend to agree TIFF's nice within a single package, but carries a lot of baggage when moving to another.

Agree, I've never had good luck loading a .tif from Houdini into anything else. Except uncompressed, but what's the point?

Now, if Houdini's .pic format was published, well documented and easily made into, say, a Photoshop plugin, well, we'd be set )

Cheers,

Peter B

I talked to Apple about the .pic format - they shrugged. Hopefully the smiley indicated you were just being silly. I think there's too *many* formats out there, everyone has “improvements” over everybody else. The only one I've seen that has any hope of becoming a standard for VFX is OExr, which is why I'm always on about it.

As end users, I think we need to scream and whine and yell whenever an application implements the sort of “forced option” that Mark was talking about. If we make enough noise maybe, just maybe, we might actually have a “midi for images”.

Cheers,

J.C.

The one thing I don't like about OpenEXR is the lack of support for simple 8bit images. The smallest data format it handles is 16bit FP, which is twice the size. There are times when 8bit is useful, especially for compact files. They support 32bit int images, so why not 8? But for this industry, I must say it's a minor complaint. The rest of the format is very well thought out. The API… well… that's a different story. :wink:

I would be very surprised if anyone adopted .pic into their software, outside of our client studios. As you mention, there are too many formats already. However, we will continue to use .pic as the native Houdini format since we have 100% control over it, and that enables us to do some fairly cool intergration things with it. Plus it doesn't get watermarked for apprentice users, which is important.