[polynurb]

Hi All,

i have noticed this before, but in this project this is actually giving me trouble..

when i open (in PS) a .png and a .hdr export from mxcl, and compare them, they do not match each other.

actually the .png will match what is being displayed in the mxcl window,
the hdr will always be "brighter"

I have noticed that this added brightness also leads to stronger aliasing artefacts in highlight areas, if the hdr is compared to the .png output.
(eg. corner hit by sun bordering background sky)

what i don't understand is how to adjust the hdr to match the highlight situation i adjusted the render to, using mxcl controls.
below an example:

I adjusted the background (material w. texture) to create a special gradient going from 1% black to 30% with a certain fade.

using hdr output, a white band appears at top.. and the bottom gets to bright.



can this be avoided, or is there any "standard conversion/adjustment" (like gamma/exposure) that can be applied via an PS action, to compress the highlights to match what is seen in the mxcl window, but still keep 32 bit color depth?

thanks,

p

[JorisMX]

Hey Poly,

I've experienced similar things esp with gradients on surfaces.

What happens is pretty much the same as with you, however if you save a 8 and 16 bit png and map them onto planes setting up the cam for orthographic view and rendering both gradients side by side plane 1 being 8 bit png and plane two with 16 bit png. They do match up in studios texture view, in mxcl they are like 2 different gradients though.

Either these are software or workflow problems. Whatever it is, its costing me time and makes alot of stuff I need to do for print very painfull

plz next limit do something!

[polynurb]

hi Joris,

thanks for your input....i see what you mean.. i think what i pointed to is still a little different...

i was refering to rendered output not texture format of the gradient texture.

in the image i posted both gradients are the same render put next to each other in PS.
one was saved as .png the other one as .hdr both directly from mxcl window.
i converted the hdr to 8bit and put it next to the png.

i figured for a similar image i have to adjust exposure -0,18 and gamma to 0,90 to make them match.. but these values seem only valid for a single camera setup (Fstop/iso/exposure)....

[Mihai]

I guess it depends how PS interprets the HDR. You could adjust the gradient with Image>Adjustments>Exposure.

Joris, for fine gradients it's better to use 16bit. Make a gradient in PS using 16b and 8bit, they won't look the same. The 8bit one will have more banding.

[JorisMX]

Poly, I understand the issue that youre having AFTER rendering with different ouput formats giving different looking results.

The reason I chimed in and went a little off path with my post is that I feel that it might be the same thing causing this error/misunderstanding.

Mihai, about the 8 and 16 bit gradients this is exactly my point.
I will make a proper thread with screenshots and examples to make it easier....

But let me try now to explain it fast and simple.

1. Creating a gradient map in PS making 2 new documents one 16 bit and one 8 bit.
2. Make a prefixed gradient with a gradient-layer.

RESULT: You get 2 gradients that look ALMOST exactly the same. As you said they do have difference in banding. The first and the last value as well as the translation in the gradient are the same.

3. Save both gradients as PNG and apply the map to 2 exact planes in MXST
(they still look the same)
4. Render it out with an orthographic set cam

RESULT: You will get a render with 2 gradients next to each other. One looking washed out (the 16 bit one) with alot LESS color information than the 8 bit png.

And this is where its similar to polys problem. the first and last values of black (0-256) do not match and they look like 2 completely different gradients.

This is the case in mxcl as well as saved out as png OR hdr.

I will provide the maps and some screenies if needed.

Sorry if this comes off like a thread hijacking. I think though that we're on to something here!

[polynurb]

Sorry if this comes off like a thread hijacking. I think though that we're on to something here!

...not at all.. very welcome actually... because i did use 32bit texture at start, but switched to 16 bit later, because it is a limitation of the rhino plug in, that atm it can not display 32bit files in viewport that are assigned via material texture slot. (i rendera all from rhino)

that shouldn't be the cause of the problem i posted about, but i am having a little problem elsewhere ( matching gradients in axo and top view) ...

now that you mention the strange look of 16bit files ... i have to see how switching textures affected my setup...

thnx,
p.