## [Vxl-maintainers] RE: component type of vcl_complex<T>?

 [Vxl-maintainers] RE: component type of vcl_complex? From: Ian Scott - 2003-12-18 17:36:27 ```> -----Original Message----- > From: Amitha Perera [mailto:perera@...] > > > 1. Mathematically, complex is a scalar. We treat rgb > as a vector. > > (think conversion to HSV. complex converted to > (magnitude,argument) is still > > a complex) > > complex is not a scalar. That is, it is not a real number. I think > what you mean is that a complex represents something greater than > merely it's components. The same applies to rgb. However, that does > not mean that we should not treat either it as a vector of numbers > when it is useful to do so. I checked with a few mathematicians on this one before making the original decision, and they both said that complex number is more of a scalar than a vector. The hint was in the word "number". The argand plane is a vector "representation" of a complex number. > > 3. What are the two components of a complex? [re, im] is a rather > > arbitrary separation, and can be dangerous > > http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf p 11. > > That may be, but it is mandated by the C++ standard in a Technical > Corrigendum. Thus, the layout of complex is equivalent to > T[2]. Does the TC mandate the order and meaning of the components in complex->T[2]. If so, it rather undermines my previous arguments. If not, making any assumptions would still be dangerous. > For example, I should be able to reasonably expect > > vil_image_view< vcl_complex > im1 = ...; > vil_image_view< vcl_complex > im2 = > vil_convert_cast_to( float(), im1 ); Personally, I would expect to use vil_convert_cast_to( vcl_complex(), im1) > to work, provided we explicitly guarantee that vil generated views are > component ordered. (This is the case now, but I don't think it is > explicitly stated.) You can guarantee that vil_image_view< compound_pixel > is generated in component order. This is fundamental to the structure of vil_image_view. vil_image_view(ni, ni, 3) will produce a plane-ordered image. vil_image_view(ni, nj, 1, 3) will produce a component-ordered image. This is due to the behaviour of the constructor, and is guaranteed by documentation. Elsewhere, unless otherwise stated, vil makes no guarantee about the ordering of the images it generates. This includes whether the image is raster or column ordered. Making any sort of general guarantee would be expensive. > > I had thought the design was such that: > > a. For templated functions, the code will deal with > complex just as > > easily as it deals with rgb. No extra code needed except > in the rare case > > where you need to specialisations (e.g. vil_convert) > > b. For the non-templated vil_image_resource style functions > - if you don;t > > want to support complex pixels, then don't bother. > > All in all, it probably doesn't make big a difference either > way. Therefore, I'd prefer to have the conversion choice and reduce > the number of component types that vil knows about. If this is mostly to make it easier to rewrite vil_convert.h, then I don;t see that as a big enough reason to make the change. Neither is removing two entries from a small number of image_resource classes. If you have real users who are making the assumptions you describe, then that should beat most theoretical arguments. However if our mathematicians are correct, then it would be better to educate the users {a la "There is no vnl_matrix::invert()") Can you deal with the problems Fred's email describes? I'm not using complex images, but changing things might have an impact on other users. You would neel to poll vxl-users first. If you can deal with all these problems, and you still feel strongly about this, then I guess you can change it. Ian. ```

 [Vxl-maintainers] RE: component type of vcl_complex? From: Ian Scott - 2003-12-18 10:16:47 ```There are several good reasons for treating complex as a single scalar rather than a two component pixel of component type T. 1. Mathematically, complex is a scalar. We treat rgb as a vector. (think conversion to HSV. complex converted to (magnitude,argument) is still a complex) 2. Most functions that operate on multiplane images treat the two planes independently. This is not correct behaviour for complex. vil_convolve is a good example. 3. What are the two components of a complex? [re, im] is a rather arbitrary separation, and can be dangerous http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf p 11. 4. AFAIK, there is no requirement in C++ that sizeof(complex) = 2*sizeof(T), or that the data is stored as struct {T real; T imag;}. vil assumes that a two component pixel can be split like this. (Of course every real implmentation I have seen does look like this.) Of course there are reasons for treating image> as a two-component scalar and hence as a two plane image. 1. Its what most (non-mathematical) programmers expect. 2. It reduces the number of types. In partial answer to 2 We made complex and complex special cases, and there is no reason to see this as a "slippery slope" to adding any more fundamental pixel types. Amtiha: Are there cases where you are being forced to deal with image >, you would not otherwise need to? I had thought the design was such that: a. For templated functions, the code will deal with complex just as easily as it deals with rgb. No extra code needed except in the rare case where you need to specialisations (e.g. vil_convert) b. For the non-templated vil_image_resource style functions - if you don;t want to support complex pixels, then don't bother. If you have found this persuasive, by all means add any useful bits to the vil/notes.html. Ian. > -----Original Message----- > From: Amitha Perera [mailto:perera@...] > Sent: Wednesday, December 17, 2003 10:37 PM > To: Ian Scott; Fred Wheeler > Subject: component type of vcl_complex? > > > Ian, > > From the notes page of vil > > http://paine.wiau.man.ac.uk/pub/doc_vxl/core/vil/html/Design.html > > and from vil_pixel_format.h, the component type of vcl_complex is > vcl_complex, and not T. Why? > > Fred and I discussed this a bit, and couldn't really think of what > we'd lose by making the component type T. The advantage is that there > would be fewer possible component types overall. > > Do you remember why that decision was made? > > Thanks, > Amitha. > ```
 [Vxl-maintainers] Re: component type of vcl_complex? From: Amitha Perera - 2003-12-18 16:41:10 ```Ian Scott wrote: > Amtiha: > Are there cases where you are being forced to deal with image >, > you would not otherwise need to? No. It's a matter of consistency and generality. The basic theme of vil is that n-plane 1-component and 1-plane n-component is the same, and that it is cheap to convert between them. (Provided, of course, that the memory layout allows it.) > 1. Mathematically, complex is a scalar. We treat rgb as a vector. > (think conversion to HSV. complex converted to (magnitude,argument) is still > a complex) complex is not a scalar. That is, it is not a real number. I think what you mean is that a complex represents something greater than merely it's components. The same applies to rgb. However, that does not mean that we should not treat either it as a vector of numbers when it is useful to do so. > 2. Most functions that operate on multiplane images treat the two planes > independently. This is not correct behaviour for complex. vil_convolve is > a good example. This is often not correct behaviour for rgb either. The RGB values are not independent in terms of human colour vision. > 3. What are the two components of a complex? [re, im] is a rather > arbitrary separation, and can be dangerous > http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf p 11. That may be, but it is mandated by the C++ standard in a Technical Corrigendum. Thus, the layout of complex is equivalent to T[2]. (From my reading, the link you provided doesn't claim that representing complex as (r,i) is dangerous, merely potentially inefficient. It does claim that one has to be careful about floating point, and that the IEEE standard is there for a reason.) > 4. AFAIK, there is no requirement in C++ that sizeof(complex) = > 2*sizeof(T), or that the data is stored as struct {T real; T imag;}. vil > assumes that a two component pixel can be split like this. (Of course every > real implmentation I have seen does look like this.) As above. The layout is now mandated. When you take a n-plane view, you gain some generailty but sacrifice the (named) association between the components for assumed association between planes. The idea is that the assumptions can be documented, and hopefully the caller will adhere. Thus, vil_image_view convert_to_hsv( vil_image_view const& src ); will assume that plane 0 of src is the red component, plane 1 the green and plane 2 the blue. (Or it should document other layout assumptions.) It will also document the output plane format. In the same way, I should be able to view a 1-plane complex image as a 2-plane double image. Does it make sense to call vil_convert_stretch_range on a two plane double image, where the planes happen to represent the real and imaginary parts of complex numbers? Maybe. Should vil force that it cannot be done? Probably not. Given that the layout of complex permits a 2-plane view, the question is should vil restrict it. My answer is no. Whether it makes any sense is up to the caller. For example, I should be able to reasonably expect vil_image_view< vcl_complex > im1 = ...; vil_image_view< vcl_complex > im2 = vil_convert_cast_to( float(), im1 ); to work, provided we explicitly guarantee that vil generated views are component ordered. (This is the case now, but I don't think it is explicitly stated.) > I had thought the design was such that: > a. For templated functions, the code will deal with complex just as > easily as it deals with rgb. No extra code needed except in the rare case > where you need to specialisations (e.g. vil_convert) > b. For the non-templated vil_image_resource style functions - if you don;t > want to support complex pixels, then don't bother. All in all, it probably doesn't make big a difference either way. Therefore, I'd prefer to have the conversion choice and reduce the number of component types that vil knows about. Amitha. ```
 [Vxl-maintainers] RE: component type of vcl_complex? From: Ian Scott - 2003-12-18 17:36:27 ```> -----Original Message----- > From: Amitha Perera [mailto:perera@...] > > > 1. Mathematically, complex is a scalar. We treat rgb > as a vector. > > (think conversion to HSV. complex converted to > (magnitude,argument) is still > > a complex) > > complex is not a scalar. That is, it is not a real number. I think > what you mean is that a complex represents something greater than > merely it's components. The same applies to rgb. However, that does > not mean that we should not treat either it as a vector of numbers > when it is useful to do so. I checked with a few mathematicians on this one before making the original decision, and they both said that complex number is more of a scalar than a vector. The hint was in the word "number". The argand plane is a vector "representation" of a complex number. > > 3. What are the two components of a complex? [re, im] is a rather > > arbitrary separation, and can be dangerous > > http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf p 11. > > That may be, but it is mandated by the C++ standard in a Technical > Corrigendum. Thus, the layout of complex is equivalent to > T[2]. Does the TC mandate the order and meaning of the components in complex->T[2]. If so, it rather undermines my previous arguments. If not, making any assumptions would still be dangerous. > For example, I should be able to reasonably expect > > vil_image_view< vcl_complex > im1 = ...; > vil_image_view< vcl_complex > im2 = > vil_convert_cast_to( float(), im1 ); Personally, I would expect to use vil_convert_cast_to( vcl_complex(), im1) > to work, provided we explicitly guarantee that vil generated views are > component ordered. (This is the case now, but I don't think it is > explicitly stated.) You can guarantee that vil_image_view< compound_pixel > is generated in component order. This is fundamental to the structure of vil_image_view. vil_image_view(ni, ni, 3) will produce a plane-ordered image. vil_image_view(ni, nj, 1, 3) will produce a component-ordered image. This is due to the behaviour of the constructor, and is guaranteed by documentation. Elsewhere, unless otherwise stated, vil makes no guarantee about the ordering of the images it generates. This includes whether the image is raster or column ordered. Making any sort of general guarantee would be expensive. > > I had thought the design was such that: > > a. For templated functions, the code will deal with > complex just as > > easily as it deals with rgb. No extra code needed except > in the rare case > > where you need to specialisations (e.g. vil_convert) > > b. For the non-templated vil_image_resource style functions > - if you don;t > > want to support complex pixels, then don't bother. > > All in all, it probably doesn't make big a difference either > way. Therefore, I'd prefer to have the conversion choice and reduce > the number of component types that vil knows about. If this is mostly to make it easier to rewrite vil_convert.h, then I don;t see that as a big enough reason to make the change. Neither is removing two entries from a small number of image_resource classes. If you have real users who are making the assumptions you describe, then that should beat most theoretical arguments. However if our mathematicians are correct, then it would be better to educate the users {a la "There is no vnl_matrix::invert()") Can you deal with the problems Fred's email describes? I'm not using complex images, but changing things might have an impact on other users. You would neel to poll vxl-users first. If you can deal with all these problems, and you still feel strongly about this, then I guess you can change it. Ian. ```
 [Vxl-maintainers] Re: component type of vcl_complex? From: Amitha Perera - 2003-12-18 19:03:28 ```Ian Scott wrote: > I checked with a few mathematicians on this one before making the original > decision, and they both said that complex number is more of a scalar than a > vector. The hint was in the word "number". The argand plane is a vector > "representation" of a complex number. Okay. However, we need to be careful when trying to impose abstract relationships into a programming paradigm. For example, inheritance represents a is-a relationship. A square "is a" (type of) rectangle. But one should generally not inherit a square from a rectangle. My point is that many mathematical relationships cannot be captured in the representation; the relationships are only implied by what one does with the representation. > Does the TC mandate the order and meaning of the components in > complex->T[2]. If so, it rather undermines my previous arguments. If not, > making any assumptions would still be dangerous. The proposed resolution mandates the order of the components, and is seen as codifying existing practice for efficiency and compatibility. > Personally, I would expect to use > vil_convert_cast_to( vcl_complex(), im1) Yes. I agree my example is contrived. > If this is mostly to make it easier to rewrite vil_convert.h, then I don;t > see that as a big enough reason to make the change. Neither is removing two > entries from a small number of image_resource classes. It makes no difference to writing vil_convert.h. Supporting what I suggest implies an addition to the planes_from_components and component_from_planes magic in vil_image_view.txx. (Which may be a good enough reason to *not* to add this support.) > If you have real users who are making the assumptions you describe, then > that should beat most theoretical arguments. The only person I know that uses complex images is Fred Wheeler, and he's had no trouble using it with the existing vil. Mind you, he makes assumptions about the layout of vcl_complex (e.g. vil_view_real_part), but that okay because it's mandated by the Standard and verified in practice. > I'm not using complex images, but changing things might have an impact on > other users. You would neel to poll vxl-users first. What I suggest would not affect existing users of complex images, to the best of my knowledge and foresight. > If you can deal with all these problems, and you still feel strongly about > this, then I guess you can change it. Well, I don't see the problems. And I don't use complex images, and so have no strong desire to change. My position is that a multi-plane approach to component images is a generalization for efficiency. It allows for efficient views of other data (slices of 3d, decimation, etc). Single plane images with vil_rgb and vil_rgba components can be efficiently converted to a multi-plane image because we know the exact layout of those components. This allows us to write 3-plane or 4-plane functions knowing that these functions can be used with vil_rgb images because an efficient conversion exists. The multi-plane functions in vil either mandate some meaning for the values in each plane (e.g. convert using rgb) or treat each plane identically (e.g. convert using average). vil does not determine whether it makes sense to call a given multi-plane function with your multi-component image. The decision is left up to you. As it should be. To me, vcl_complex is no different in this regard that vil_rgb or vil_rgba. In all three cases: (1) there some relationship between the numbers in the components that represent each pixel, and this relationship is unknown to most functions in vil; (2) each pixel is represented as a contiguous vector of component values; (3) the image has a whole can be view as a single plane, multi-component or multi-plane, single-component; (4) for a planar view, some functions may assign meaning to the numbers in each plane; (5) there is value in sometimes viewing the image as planes, so that we can examine a single plane at a time. (Examples: vil_view_as_planes, vil_view_real_part.) That cheap conversion to a plane view exists for vil_rgb and vil_rgba if the users wants to view the image that way, but doesn't exist for vcl_complex, strikes me as inconsistent and somewhat arbitrary. Especially so because all three component types (vil_rgb, vil_rgba and vcl_complex) are supported directly in vil, and are not user-added types. That said, I don't care enough about the matter enough to pursue it further. The design of vil is good, and allows me to do what I want efficiently and correctly. Amitha. ```