Recently, I added a new feature to CMake that allows for auto-exporting
of symbols on Windows. You still need to mark up global data. I have a
pull request with the changes needed to build vxl with this feature.
https://github.com/vxl/vxl/pull/4
-Bill

Wow, that's quick! You folks are amazing! :)
I did manage to test it on a Mac laptop. It builds and runs tests
successfully with Daniel's fix!
After a little research on the format string for different types of
integers, I made (and pushed) a change on the format strings to eliminate
some of the warnings. I believe there is only one warning left when
building with Clang++ on Mac.
This looks good overall. I am quite pleased. Only the tiff_raw_decode test
failure on Windows is still bugging me. I wonder if someone can try a
Windows build and let me know if this test passes or not. (Wish we have a
Windows build on the dashboard).
Regards,
Gary
On Thu, Dec 11, 2014 at 5:38 PM, Sean McBride <sean@...>
wrote:
>
> On Thu, 11 Dec 2014 17:07:31 -0500, Daniel Crispell said:
>
> >I believe this is now fixed (just pushed). I can now get through a full
> >build on my linux machine (with some new warnings from within v3p/tiff).
>
> A basic cmake+make now builds for me too (with an unholy number of
> warnings).
>
> Still gotta figure out what's different about my dashboards tho...
>
> Cheers,
>
> --
> ____________________________________________________________
> Sean McBride, B. Eng sean@...
> Rogue Research http://www.rogue-research.com
> Mac Software Developer Montréal, Québec, Canada
>
>
>

On Thu, 11 Dec 2014 17:07:31 -0500, Daniel Crispell said:
>I believe this is now fixed (just pushed). I can now get through a full
>build on my linux machine (with some new warnings from within v3p/tiff).
A basic cmake+make now builds for me too (with an unholy number of warnings).
Still gotta figure out what's different about my dashboards tho...
Cheers,
--
____________________________________________________________
Sean McBride, B. Eng sean@...
Rogue Research http://www.rogue-research.com
Mac Software Developer Montréal, Québec, Canada

On Thu, 11 Dec 2014 14:45:10 -0500, Gehua Yang said:
>I just notice vxl dashboard has only a few nightly builds and no continuous
>builds. The number of builds shrink drastically even compared to last
>year.
Yes, it's in a sad state. And all of mine have been red for weeks.
No one out there able to add some dashboards? Especially a Windows bot, there are none now.
>Anyway, the dashboard is not quite useful for my purpose of monitoring
>libtiff upgrade. I will rely more on you guys instead. Please let me know
>if you have any problems with the HEAD of the master branch in
>vxl.sourceforge.net.
It probably would have been better to get the existing dashboards green before committing a major change like you did, but oh well...
I've tried building and it fails early on:
[ 6%] Building C object v3p/geotiff/CMakeFiles/geotiff.dir/geo_free.o
In file included from /Users/sean/external/vxl/v3p/geotiff/geo_free.c:15:
In file included from /Users/sean/external/vxl/v3p/geotiff/geo_tiffp.h:38:
In file included from /Users/sean/external/vxl/v3p/geotiff/xtiffio.h:10:
/Users/sean/external/vxl/v3p/tiff/tiffio.h:67:9: error: unknown type name 'size_t'
typedef TIFF_SSIZE_T tmsize_t;
^
/Users/sean/external/vxl-bin/v3p/tiff/tiffconf.h:35:22: note: expanded from macro 'TIFF_SSIZE_T'
#define TIFF_SSIZE_T size_t
^
Cheers,
--
____________________________________________________________
Sean McBride, B. Eng sean@...
Rogue Research http://www.rogue-research.com
Mac Software Developer Montréal, Québec, Canada

Dear Amitha,
Thanks for the comments. One thing I would like to point out is that we do
not have vcl wrappers for inttypes.h and stdint.h. I wonder if anyone in
the community could get a take on it.
Regards,
Gehua.
On Tue, Dec 9, 2014 at 1:11 AM, Amitha Perera <
amithaperera@...> wrote:
> Perhaps you can simply check in hard-coded config files for the three main
> platforms (Windows, Mac, Linux), and simply not build libtiff by default on
> the other platforms? On other platforms, we can say it's the user's
> responsibility to provide an external libtiff if one of the hard-coded ones
> don't work.
>
> I think it'd be fine to use the vcl versions of inttypes.h and stdint.h
> for the v3p version of libtiff. After all, the point of v3p/libtiff is to
> provide a tiff library that is geared for vxl. If a user wants a more
> general one, they can provide an external one.
>
> My 2c.
>
> Amitha.
>
> On Mon, Dec 8, 2014 at 1:48 PM, Gehua Yang <yanggehua@...> wrote:
>
>> Update:
>>
>> This more work than I expected. 4.0.2 uses macros such as TIFF_UINT64_T,
>> TIFF_INT32_T, or TIFF_UINT32_T to define appropriate types. These macros
>> are defined in the configure-type generated header files, tiffconf.h and
>> tif_config.h. The 4.0.2 library provides hard-coded header files for
>> Windows platform. In comparison, what we have in version 3.8.2 in v3p/tiff
>> are **hard-coded** versions of tiffconf.h and tif_config.h.
>>
>> It is difficult (perhaps impossible) to stay with the hard-coded static
>> header files. For instance, TIFF_UINT64_T is defined as "unsigned
>> __int64" on Windows, but something else, such as uint64_t, on other
>> platforms. I can see two potential solutions to this problem:
>>
>> 1) Use CMake magic similar to the generation of vxl_config.h. I wish I
>> can make use of vxl_config.h or the cmake variables behind it, but this is
>> in v3p and thus not in the scope of core. Anyway, perhaps straight-forward
>> copy and paste of the CMake magic will do here. The downside is that it
>> will slow down the configuration stage for it does the same checking twice
>> --- one in vxl/core and one here.
>>
>> 2) Use the standard inttypes.h and stdint.h. For Windows where these
>> two headers are unavailable, we can adopt the open version from
>> https://code.google.com/p/msinttypes/. By the way, it seems vcl shall
>> include these two header files. But this approach may be insufficient for
>> it only takes care of integer types. It may turn out header file checks
>> are still needed.
>>
>> Any suggestions on one way or the other?
>>
>> Regards,
>> Gehua
>>
>>
>> On Mon, Dec 8, 2014 at 11:06 AM, Gehua Yang <yanggehua@...> wrote:
>>
>>> Hi All,
>>>
>>> The libTiff we have in v3p is version 3.8.2, released in 2006. The
>>> current release is 4.0.2. I guess many in the community has taken
>>> advantage of the newer releases on Linux or Mac OSX. But Window's users
>>> have no such luck.
>>>
>>>
>>> I am in the process of upgrading libtiff to 4.0.2, mainly targeting the
>>> Window platform. I am sending this email for two purposes:
>>>
>>> 1. I don't want to duplicate the effort if somebody has done the
>>> upgrade.
>>> 2. Is there anyone who would like to collaborate the effort, especially
>>> checking builds/test on other platforms?
>>>
>>> Best regards,
>>> Gehua Yang
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Vxl-maintainers mailing list
>> Vxl-maintainers@...
>> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers
>>
>>
>

One other note: In our experience the geotiff library in v3p does not play
well (seg faults when reading metadata) with newer versions of libtiff on
linux systems. We have gotten around this by using the (older) version of
libtiff in v3p, so upgrading it may take that option away from us.
Obviously the correct solution is to figure out exactly what's going on and
fix the bug in the geotiff library (or how it's being used), which we're
looking into now. Using both system geotiff and system tiff libraries
also produces errors, so it is likely a bug in the vxl code, not a library
incompatibility issue. Still, in the short term v3p geotiff and v3p tiff
does seem to work - Just something to be aware of.
-Dan
On Tue, Dec 9, 2014 at 1:11 AM, Amitha Perera <
amithaperera@...> wrote:
> Perhaps you can simply check in hard-coded config files for the three main
> platforms (Windows, Mac, Linux), and simply not build libtiff by default on
> the other platforms? On other platforms, we can say it's the user's
> responsibility to provide an external libtiff if one of the hard-coded ones
> don't work.
>
> I think it'd be fine to use the vcl versions of inttypes.h and stdint.h
> for the v3p version of libtiff. After all, the point of v3p/libtiff is to
> provide a tiff library that is geared for vxl. If a user wants a more
> general one, they can provide an external one.
>
> My 2c.
>
> Amitha.
>
> On Mon, Dec 8, 2014 at 1:48 PM, Gehua Yang <yanggehua@...> wrote:
>
>> Update:
>>
>> This more work than I expected. 4.0.2 uses macros such as TIFF_UINT64_T,
>> TIFF_INT32_T, or TIFF_UINT32_T to define appropriate types. These macros
>> are defined in the configure-type generated header files, tiffconf.h and
>> tif_config.h. The 4.0.2 library provides hard-coded header files for
>> Windows platform. In comparison, what we have in version 3.8.2 in v3p/tiff
>> are **hard-coded** versions of tiffconf.h and tif_config.h.
>>
>> It is difficult (perhaps impossible) to stay with the hard-coded static
>> header files. For instance, TIFF_UINT64_T is defined as "unsigned
>> __int64" on Windows, but something else, such as uint64_t, on other
>> platforms. I can see two potential solutions to this problem:
>>
>> 1) Use CMake magic similar to the generation of vxl_config.h. I wish I
>> can make use of vxl_config.h or the cmake variables behind it, but this is
>> in v3p and thus not in the scope of core. Anyway, perhaps straight-forward
>> copy and paste of the CMake magic will do here. The downside is that it
>> will slow down the configuration stage for it does the same checking twice
>> --- one in vxl/core and one here.
>>
>> 2) Use the standard inttypes.h and stdint.h. For Windows where these
>> two headers are unavailable, we can adopt the open version from
>> https://code.google.com/p/msinttypes/. By the way, it seems vcl shall
>> include these two header files. But this approach may be insufficient for
>> it only takes care of integer types. It may turn out header file checks
>> are still needed.
>>
>> Any suggestions on one way or the other?
>>
>> Regards,
>> Gehua
>>
>>
>> On Mon, Dec 8, 2014 at 11:06 AM, Gehua Yang <yanggehua@...> wrote:
>>
>>> Hi All,
>>>
>>> The libTiff we have in v3p is version 3.8.2, released in 2006. The
>>> current release is 4.0.2. I guess many in the community has taken
>>> advantage of the newer releases on Linux or Mac OSX. But Window's users
>>> have no such luck.
>>>
>>>
>>> I am in the process of upgrading libtiff to 4.0.2, mainly targeting the
>>> Window platform. I am sending this email for two purposes:
>>>
>>> 1. I don't want to duplicate the effort if somebody has done the
>>> upgrade.
>>> 2. Is there anyone who would like to collaborate the effort, especially
>>> checking builds/test on other platforms?
>>>
>>> Best regards,
>>> Gehua Yang
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Vxl-maintainers mailing list
>> Vxl-maintainers@...
>> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers
>>
>>
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> Vxl-maintainers mailing list
> Vxl-maintainers@...
> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers
>
>

Perhaps you can simply check in hard-coded config files for the three main
platforms (Windows, Mac, Linux), and simply not build libtiff by default on
the other platforms? On other platforms, we can say it's the user's
responsibility to provide an external libtiff if one of the hard-coded ones
don't work.
I think it'd be fine to use the vcl versions of inttypes.h and stdint.h for
the v3p version of libtiff. After all, the point of v3p/libtiff is to
provide a tiff library that is geared for vxl. If a user wants a more
general one, they can provide an external one.
My 2c.
Amitha.
On Mon, Dec 8, 2014 at 1:48 PM, Gehua Yang <yanggehua@...> wrote:
> Update:
>
> This more work than I expected. 4.0.2 uses macros such as TIFF_UINT64_T,
> TIFF_INT32_T, or TIFF_UINT32_T to define appropriate types. These macros
> are defined in the configure-type generated header files, tiffconf.h and
> tif_config.h. The 4.0.2 library provides hard-coded header files for
> Windows platform. In comparison, what we have in version 3.8.2 in v3p/tiff
> are **hard-coded** versions of tiffconf.h and tif_config.h.
>
> It is difficult (perhaps impossible) to stay with the hard-coded static
> header files. For instance, TIFF_UINT64_T is defined as "unsigned
> __int64" on Windows, but something else, such as uint64_t, on other
> platforms. I can see two potential solutions to this problem:
>
> 1) Use CMake magic similar to the generation of vxl_config.h. I wish I
> can make use of vxl_config.h or the cmake variables behind it, but this is
> in v3p and thus not in the scope of core. Anyway, perhaps straight-forward
> copy and paste of the CMake magic will do here. The downside is that it
> will slow down the configuration stage for it does the same checking twice
> --- one in vxl/core and one here.
>
> 2) Use the standard inttypes.h and stdint.h. For Windows where these two
> headers are unavailable, we can adopt the open version from
> https://code.google.com/p/msinttypes/. By the way, it seems vcl shall
> include these two header files. But this approach may be insufficient for
> it only takes care of integer types. It may turn out header file checks
> are still needed.
>
> Any suggestions on one way or the other?
>
> Regards,
> Gehua
>
>
> On Mon, Dec 8, 2014 at 11:06 AM, Gehua Yang <yanggehua@...> wrote:
>
>> Hi All,
>>
>> The libTiff we have in v3p is version 3.8.2, released in 2006. The
>> current release is 4.0.2. I guess many in the community has taken
>> advantage of the newer releases on Linux or Mac OSX. But Window's users
>> have no such luck.
>>
>>
>> I am in the process of upgrading libtiff to 4.0.2, mainly targeting the
>> Window platform. I am sending this email for two purposes:
>>
>> 1. I don't want to duplicate the effort if somebody has done the
>> upgrade.
>> 2. Is there anyone who would like to collaborate the effort, especially
>> checking builds/test on other platforms?
>>
>> Best regards,
>> Gehua Yang
>>
>>
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> Vxl-maintainers mailing list
> Vxl-maintainers@...
> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers
>
>

Update:
This more work than I expected. 4.0.2 uses macros such as TIFF_UINT64_T,
TIFF_INT32_T, or TIFF_UINT32_T to define appropriate types. These macros
are defined in the configure-type generated header files, tiffconf.h and
tif_config.h. The 4.0.2 library provides hard-coded header files for
Windows platform. In comparison, what we have in version 3.8.2 in v3p/tiff
are **hard-coded** versions of tiffconf.h and tif_config.h.
It is difficult (perhaps impossible) to stay with the hard-coded static
header files. For instance, TIFF_UINT64_T is defined as "unsigned
__int64" on Windows, but something else, such as uint64_t, on other
platforms. I can see two potential solutions to this problem:
1) Use CMake magic similar to the generation of vxl_config.h. I wish I
can make use of vxl_config.h or the cmake variables behind it, but this is
in v3p and thus not in the scope of core. Anyway, perhaps straight-forward
copy and paste of the CMake magic will do here. The downside is that it
will slow down the configuration stage for it does the same checking twice
--- one in vxl/core and one here.
2) Use the standard inttypes.h and stdint.h. For Windows where these two
headers are unavailable, we can adopt the open version from
https://code.google.com/p/msinttypes/. By the way, it seems vcl shall
include these two header files. But this approach may be insufficient for
it only takes care of integer types. It may turn out header file checks
are still needed.
Any suggestions on one way or the other?
Regards,
Gehua
On Mon, Dec 8, 2014 at 11:06 AM, Gehua Yang <yanggehua@...> wrote:
> Hi All,
>
> The libTiff we have in v3p is version 3.8.2, released in 2006. The
> current release is 4.0.2. I guess many in the community has taken
> advantage of the newer releases on Linux or Mac OSX. But Window's users
> have no such luck.
>
>
> I am in the process of upgrading libtiff to 4.0.2, mainly targeting the
> Window platform. I am sending this email for two purposes:
>
> 1. I don't want to duplicate the effort if somebody has done the upgrade.
> 2. Is there anyone who would like to collaborate the effort, especially
> checking builds/test on other platforms?
>
> Best regards,
> Gehua Yang
>
>

Dear Joe,
This is great! I am currently working on the upgrade. I will post again
once I am ready to commit.
Regards,
Gehua (Gary)
On Mon, Dec 8, 2014 at 11:57 AM, Joseph Mundy <mundy@...> wrote:
> Gary,
>
> We use libtiff quite a bit so I am willing to help. I personally build on
> windows so I won't be much help there, but maybe one of the Linux/Mac
> people in Vision Systems will be willing to check builds.
>
> Joe
>
>
>
> *From:* Gehua Yang [mailto:yanggehua@...]
> *Sent:* Monday, December 08, 2014 11:06 AM
> *To:* Vxl-maintainers
> *Subject:* [Vxl-maintainers] v3p/tiff upgrade
>
>
>
> Hi All,
>
> The libTiff we have in v3p is version 3.8.2, released in 2006. The
> current release is 4.0.2. I guess many in the community has taken
> advantage of the newer releases on Linux or Mac OSX. But Window's users
> have no such luck.
>
> I am in the process of upgrading libtiff to 4.0.2, mainly targeting the
> Window platform. I am sending this email for two purposes:
>
> 1. I don't want to duplicate the effort if somebody has done the upgrade.
>
> 2. Is there anyone who would like to collaborate the effort, especially
> checking builds/test on other platforms?
>
> Best regards,
>
> Gehua Yang
>

Gary,
We use libtiff quite a bit so I am willing to help. I personally build on windows so I won't be much help there, but maybe one of the Linux/Mac people in Vision Systems will be willing to check builds.
Joe
From: Gehua Yang [mailto:yanggehua@...]
Sent: Monday, December 08, 2014 11:06 AM
To: Vxl-maintainers
Subject: [Vxl-maintainers] v3p/tiff upgrade
Hi All,
The libTiff we have in v3p is version 3.8.2, released in 2006. The current release is 4.0.2. I guess many in the community has taken advantage of the newer releases on Linux or Mac OSX. But Window's users have no such luck.
I am in the process of upgrading libtiff to 4.0.2, mainly targeting the Window platform. I am sending this email for two purposes:
1. I don't want to duplicate the effort if somebody has done the upgrade.
2. Is there anyone who would like to collaborate the effort, especially checking builds/test on other platforms?
Best regards,
Gehua Yang

Hi All,
The libTiff we have in v3p is version 3.8.2, released in 2006. The current
release is 4.0.2. I guess many in the community has taken advantage of the
newer releases on Linux or Mac OSX. But Window's users have no such luck.
I am in the process of upgrading libtiff to 4.0.2, mainly targeting the
Window platform. I am sending this email for two purposes:
1. I don't want to duplicate the effort if somebody has done the upgrade.
2. Is there anyone who would like to collaborate the effort, especially
checking builds/test on other platforms?
Best regards,
Gehua Yang

Peter,
This is a long standing issue with the design of vpgl_calibration_matrix. I’d be happy to see it corrected.
—Matt
On Jul 31, 2014, at 8:21 AM, Joseph Mundy <mundy@...> wrote:
> Sounds good to me!
> Joe
>
> From: Pete Carr [mailto:gpkcarr@...]
> Sent: Thursday, July 31, 2014 8:18 AM
> To: vxl-maintainers@...
> Subject: [Vxl-maintainers] Revise vpgl_calibration_matrix
>
> Hello Maintainers,
>
> The current implementation of vpgl_calibration_matrix has an unintuitive interface and often leads to spurious errors. For instance, the following test fails:
>
> vpgl_calibration_matrix<double> K1( 1000, vgl_point_2d<double>(320,240));
> vpgl_calibration_matrix<double> K2( K1.get_matrix() );
> TEST_NEAR( "Equiv Focal Length", K1.focal_length(), K2.focal_length(), 1e-2 );
>
> The reason for the failure is that vpgl_calibration_matrix is over parameterized: it has two scale parameters (one for the x direction, and a second for the y direction) instead of a single aspect ratio parameter. For these sorts of tests to pass, focal_length must be multiplied by either the x_scale or the y_scale before any comparisons are made. Since these parameters are not needed for square pixels, it's a rather cumbersome step which I (and presumably others) forget.
>
> I propose the following fix:
> 1. Replace x_scale and y_scale with a single aspect_ratio parameter.
> 2. Deprecate x_scale and y_scale methods, and internally compensate so that x_scale = 1.
> 3. Implement new aspect_ratio getter/setter and constructor.
>
> Thoughts?
>
> Peter
> ------------------------------------------------------------------------------
> Infragistics Professional
> Build stunning WinForms apps today!
> Reboot your WinForms applications with our WinForms controls.
> Build a bridge from your legacy apps to the future.
> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk_______________________________________________
> Vxl-maintainers mailing list
> Vxl-maintainers@...
> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers

Sounds good to me!
Joe
From: Pete Carr [mailto:gpkcarr@...]
Sent: Thursday, July 31, 2014 8:18 AM
To: vxl-maintainers@...
Subject: [Vxl-maintainers] Revise vpgl_calibration_matrix
Hello Maintainers,
The current implementation of vpgl_calibration_matrix has an unintuitive interface and often leads to spurious errors. For instance, the following test fails:
vpgl_calibration_matrix<double> K1( 1000, vgl_point_2d<double>(320,240));
vpgl_calibration_matrix<double> K2( K1.get_matrix() );
TEST_NEAR( "Equiv Focal Length", K1.focal_length(), K2.focal_length(), 1e-2 );
The reason for the failure is that vpgl_calibration_matrix is over parameterized: it has two scale parameters (one for the x direction, and a second for the y direction) instead of a single aspect ratio parameter. For these sorts of tests to pass, focal_length must be multiplied by either the x_scale or the y_scale before any comparisons are made. Since these parameters are not needed for square pixels, it's a rather cumbersome step which I (and presumably others) forget.
I propose the following fix:
1. Replace x_scale and y_scale with a single aspect_ratio parameter.
2. Deprecate x_scale and y_scale methods, and internally compensate so that x_scale = 1.
3. Implement new aspect_ratio getter/setter and constructor.
Thoughts?
Peter

Hello Maintainers,
The current implementation of vpgl_calibration_matrix has an unintuitive
interface and often leads to spurious errors. For instance, the following
test fails:
vpgl_calibration_matrix<double> K1( 1000, vgl_point_2d<double>(320,240));
vpgl_calibration_matrix<double> K2( K1.get_matrix() );
TEST_NEAR( "Equiv Focal Length", K1.focal_length(), K2.focal_length(), 1e-2
);
The reason for the failure is that vpgl_calibration_matrix is over
parameterized: it has two scale parameters (one for the x direction, and a
second for the y direction) instead of a single aspect ratio parameter. For
these sorts of tests to pass, focal_length must be multiplied by either the
x_scale or the y_scale before any comparisons are made. Since these
parameters are not needed for square pixels, it's a rather cumbersome step
which I (and presumably others) forget.
I propose the following fix:
1. Replace x_scale and y_scale with a single aspect_ratio parameter.
2. Deprecate x_scale and y_scale methods, and internally compensate so that
x_scale = 1.
3. Implement new aspect_ratio getter/setter and constructor.
Thoughts?
Peter

All,
I'm forwarding a request from a user to merge a bug fix patch that was
posted as a pull request on our GitHub site: https://github.com/vxl/vxl/.
This is a good way for outside users to contribute changes back to VXL.
If you still consider yourself an active VXL, I suggest you join the VXL
community on GitHub and "watch" the vxl project so that you are notified of
these requests. You can then comment on the code on the GitHub site, pull
in the changes to your local clone and push them back to our primary
repository on sourceforge.
This one looks like a simple fix and looks correct. I can merge it, but I
haven't worked on vnl_sparse_matrix before, so I'll give it a couple days
in case anyone else wants to look at the issue more carefully or make
comments.
Thanks,
Matt
---------- Forwarded message ----------
From: Daniel Perry <notifications@...>
Date: Mon, Jul 28, 2014 at 2:31 PM
Subject: [vxl] vnl_sparse_matrix::mult - size of q buffer should actually
be (this->rows())*pcols. (#1)
To: vxl/vxl <vxl@...>
I ran into a subtle bug in vnl_sparse_matrix::mult(), where the code
assumes the p and q buffers are the same size (prows*pcols). However the
size of q should really be (this->rows())*pcols.
ie, in matrix multiplication an (a,b) size matrix multiplied with a (b,c)
size matrix results in a (a,c) size matrix, not (b,c).
(I have a duplicate pull-request open with ITK, but thought you would
probably want the tiny fix too?)
------------------------------
You can merge this Pull Request by running
git pull https://github.com/daniel-perry/vxl master
Or view, comment on, or merge it at:
https://github.com/vxl/vxl/pull/1
Commit Summary
- size of q buffer should actually be (this->rows())*pcols.
File Changes
- *M* core/vnl/vnl_sparse_matrix.txx
<https://github.com/vxl/vxl/pull/1/files#diff-0&gt; (2)
Patch Links:
- https://github.com/vxl/vxl/pull/1.patch
- https://github.com/vxl/vxl/pull/1.diff
—
Reply to this email directly or view it on GitHub
<https://github.com/vxl/vxl/pull/1&gt;.

Sean, Matt,
I've got too much to do at the moment to adapt these changes from ITK to
VXL. However, if someone wants create a branch that applies the fix to
VXL, you can push the branch to GitHub (https://github.com/vxl/vxl) and I
will review and merge it into master.
--Matt
On Fri, Jul 25, 2014 at 9:06 AM, Sean McBride <sean@...>
wrote:
> On Tue, 22 Jul 2014 01:08:53 -0400, Matt McCormick said:
>
> >On the ITK dashboard, we have seen that vnl_test_na fails on OSX 10.9
> >due to a bug in libc++.
>
> Or rather a possible bug in libc++... I'm not a C++ language lawyer, but
> it seems that both on stackoverflow and in the llvm bug report that smart
> people don't even agree what the correct behaviour should be, and even if
> the C++ standard text is clear about it. :(
>
> >We have proposed to mask this known issue
> >from our dashboard as in this patch [1]. Is there any interest in
> >merging this upstream?
>
> The test fails on my 10.9 vxl dashboard too:
>
> <http://open.cdash.org/testDetails.php?test=219688273&build=3422091&gt;
>
> so it would sure to nice to merge into vxl itself!
>
> Cheers,
>
> --
> ____________________________________________________________
> Sean McBride, B. Eng sean@...
> Rogue Research http://www.rogue-research.com
> Mac Software Developer Montréal, Québec, Canada
>
>
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Vxl-maintainers mailing list
> Vxl-maintainers@...
> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers
>