On Jun 12, 2012, at 9:37 AM, Stefan Stavrev wrote:
> Questions related to Over:
>
> 1. Can I assume the alpha channel has values only 0 to 1? I should not check
> that?
I think you should clamp alpha to 0-1, since outside of that are clearly
nonsensical. The other channels should not be clamped or adjusted.
> 2. Larry, from previous conversation, what does it mean for an ImageBuf to be
> uninitialized here?
>
> // Initialized Result -> use as allocated; Uninitialized Result -> size it to
> the union
> if (Result is uninitialized) {
> ImageSpec newspec = A.spec();
> newspec.{x,y,z,width,height,depth} = union of A's and B's pixel regions
> Result.reset ("over", newspec); // Resize it
> }
"Uninitialized" means it was default-constructed and never given a size or an
image to load, or at some point called clear(). So at such a point it has no
specific size, no pixels, no memory allocated, no reference to any image. You
can test whether it's an uninitialized ImageBuf with:
if (! m_spec_valid && ! m_pixels_valid) {
// it's uninitialized
}
and the methods that will initialize it (other than constructors) are
reset(name,imagecache) // refer to a file on disk (via the IC)
reset(name,spec) // allocate local mem based on spec
> 3. ImageBuf uses ROI and ROI uses ImageBuf. If I place ROI in ImageBuf.h I
> will need to forward declare it. But that makes ROI an incomplete type. This
> is a problem because ImageBuf class needs to use some methods of ROI, in the
> Iterator constructors. Any suggestions where to place ROI class? I found
> other places in the project where forward declarations are used, but it works
> because there are no definitions in the *.h file. The challenge here is that
> the iterator is defined in the .h file, that is in imagebuf.h.
One or the other can be a forward declaration. I think that imagebuf.h should
look like this:
class ImageBuf; // forward declaration
class ROI {
ROI (xbegin, xend, ...) { m_xbegin = ... inline for this is
advised... }
ROI (const ImageBuf &); // don't inline this, put it in
imagebuf.cpp
...
};
class ImageBuf {
// mostly as before
}
> 4. I see xend - xbegin used in many places and it suggests width of region,
> but isn't the width actually xend - xbegin + 1? I ask because I need to
> implement width() getter method for ROI class.
Just like for C++ STL, the begin/end are "asymmetric", so end actually points
to one past the last pixel. That means that width = end-begin. And I do
recommend adding methods to ROI like:
int width () const { return m_xend - m_xbegin; }
since those are often pretty handy.
> 5. Larry, again from previous conversation you said: "Working with arbitrary
> pixel data values, not assuming values are always on [0,1] (i.e., HDR
> imagery) except for operations where that clearly makes no sense."
>
> If I understand right, the input images have values in the range
> spec.quant_black to spec.quant_white.
Nope. The quant_* values are used in ImageOutput only, to determine how
floating point values are turned into integers.
Floating-point pixels (float, double, half) obviously encode their values
directly (0.25, 1.0, or 3.14) and have no quantization issues.
As an aside, integers do not have to map to their full range. You could have a
8 bit file in which you cleverly use quant_* to make a uint16 able to encode
certain negative or "super-positive" (>1) values. Again, that's only an output
thing.
> I need to map that range to 0-1 because the math is easier and apply the
> algorithm. Before writing to the result ImageBuf, map the result back to the
> range spec.quant_black - spec.quant_white. That is all, or am I missing
> something?
Forget quant; that's for output only, it's not even set by ImageInput.
If you have an ImageBuf::Iterator<BUFTYPE,float>, then *iterator will always be
float that you can just use.
> 6. From previous conversation "If spec.alpha_channel < 0, but it's a
> 4-channel image, assume that channel 3 is alpha."
>
> Not sure about this because for any other number of channels if alpha is not
> specified we assume it has value 1 everywhere. Should this be the only
> exception? I vote for not allowing this, because it is kinda messy to assume
> which channel is alpha if it is not specified. It will also break the general
> rule, which is: if alpha is specified use it, otherwise assume values 1
> everywhere.
No, that's not quite the rule. The rule is:
* A channel with a labeled alpha channel should be assumed to be correct, use
it (any number of non-alpha channels are ok, as long as they match between the
two input images).
* A 4-channel image without a labeled alpha channel is almost certainly RGBA,
so assume channel #3 is alpha.
* A 3-channel image without a labeled alpha channel is almost certainly RGB, so
assume alpha = 1.
* All other cases are ambiguous and probably a mistake, reject them.
I have a feeling that 4-channel RGBA that happens to be unlabeled for some
reason will be a common case for people. I think it's safer to assume it's
RGBA than to reject it.
--
Larry Gritz
[email protected]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
