Can I use mixpict based off the image transparency value?

radiance-general
1

If I want to mix two materials together based on an image, I currently do it this way:

void mixpict decal
7 foo bar grey mask.hdr . frac(Lu) frac(Lv)
0
0

In this case, mask.hdr is a black and white mask. The “grey” function, according to the refman, takes three arguments, RGB, and in this case uses the greyscale value of the mask.hdr to figure out whether to show foo or bar.

Is it possible to use another function in place of grey that reads transparency values of the pixels in the hdr? From my understanding of the sentence in the refman, this is not possible as only RGB is taken as inputs, but I thought I’d ask. This would save me the time to create another dedicated greyscale mask, and be very useful when creating materials for “decal” patterns.

Thanks in advance :slight_smile:

2

Hi Dion,

the Radiance HDR format does not define transparency. You have three
double-precision floating point “channels”, and by default these are
assigned to RGB. If you want to map a color image with transparency, you
could set one channel to a known value and use this to decide. Of
course, this requires that the chosen values is not occuring somewhere a
luminance/radiance.

If you are working with grayscale images, you actually have two channels
for any additional information. So you may pack your values into the
first ®, your transparency into the second (G), and still have the
third. You would than need a cal-file that evaluates R, G, B all
identically to the first channel.

I have never done it, but it should be possible as long as you do apply
tools assuming the RGB-mapping to these slightly manipulated HDR files :wink:

Cheers, Lars.

3

Before you go too far down the path of treating HDR RGB values independently, they share a common exponent, so in general you lose accuracy if any component goes below maybe a tenth of the maximum of the three channels. Furthermore, they are not double-precision or even single-precision floats. The HDR pixels have roughly a 1% precision corresponding to a 1-byte mantissa.
I should add that the mixdata type is available if this precision is inadequate to your task.

4

I see. Thanks for the response! I was misled as The GIMP is able to save a “HDR” image format, and somehow I can reopen this format in The GIMP and it will maintain transparency information as well as the RGB. Maybe this HDR format is not quite the same as Radiance’s, I’m not sure.

5

I had not heard of this before. I wasn’t able to find any information online about transparency layers in GIMP HDR files. Can you open them using Photosphere or convert them using ra_bmp or any of the other Radiance tools? Just curious. They may in fact be EXR or some other format that supports alpha channels natively.

6

Interesting. Here are the symptoms I observe. I don’t have Windows or Photosphere, so I can’t test BMP or Photosphere:

  1. If I convert a .png with transparency to .hdr with mogrify -format hdr foo.png, the resultant .hdr will not have transparency, and replace transparent regions with black.
  2. If I save a .png with transparency to .hdr using The GIMP, the resultant .hdr viewed with ximage will not have transparency, and will show black. If I reopen the image with The GIMP, I can see transparent regions, and so somehow transparency is still preserved.
  3. If I convert one of these special .hdr files which is saved with The GIMP and somehow have transparency preserved with ra_gif foo.hdr foo.gif, reopening the gif will show a gif with no transparency, and transparent regions replaced with black.

Maybe The GIMP is doing something unique that it can read back in saving a hdr.

7

If transparency is binary (1 or 0, nothing in between) then it could be a simple flag set in the header so that GIMP interprets all black pixels as invisible rather than black. What does getinfo yield from a GIMP-saved HDR with transparency?

8

Hmm, I understand what you are saying, but I’m not sure what value here could be causing it. Here’s the result of getinfo:

leaf1.hdr:
        #?RADIANCE
        GAMMA=1
        PRIMARIES=0 0 0 0 0 0 0 0
        FORMAT=32-bit_rle_rgbe

You can try download an example from here: https://gitlab.com/dionmoult/living-room-radiance-demo/raw/master/lib/crassula-multicava/tex/leaf1.hdr?inline=false and see if you can spot anything strange with it.

9

Well, the primaries are suspiciously wrong. It could also be that any zero area is just treated as transparent. Is it just the area outside the leaf, because those are indeed all zeros (binary bytes 0 0 0 0).

10

Just an update to this thread - yes, the transparency is indeed just outside the leaf. I have posted a bug report on the GIMP’s bugtracker just now, so hopefully they can help shed some light!