From: Gehua Y. <yan...@gm...> - 2014-12-10 21:40:14
|
Hi Daniel, Sean, Amitha, Joe and all others, It took me a while, but I was able to convert the two headers to CMake's configure_file() style. Fortunately, all of the VXL's platform test cmake variables are available. So I took the advantage of those, only adding CMake tests to a few header files that was not included before. I also ported seven tests from tiff lib to vxl. These tests will become part of the dashboard tests if libtiff build is turned on. It is worth to note one of the test tiff_raw_decode failed with an assertion failure on my Windows 64-bit build. I tried to debug (see enclosed screen shot), and even found a similar bug discussion online ( https://trac.osgeo.org/gdal/ticket/2033), but couldn't figure out what is the fix. I ran into a similar bug in the previous version and would guess this is not a new bug. It seems this bug affects reading/writing of TIFF files using JPEG compression. I don't have such image files for test. Perhaps someone can give it a try. Meanwhile, I shall monitor the dashboard to see whether these tiff and vil tests succeed on platforms other than Windows. @Sean, if you could test this code on Mac OSX it will be greatly appreciated! Regards, Gehua On Tue, Dec 9, 2014 at 10:33 AM, Daniel Crispell <dan...@gm...> wrote: > Yes, that is a great idea. Unfortunately the failure we see is fairly > non-deterministic, but hopefully we can figure out a way to reliably > produce it (or at least detect that something has gone wrong) once we > understand whats happening a little bit better. > > -Dan > > > On Tue, Dec 9, 2014 at 10:29 AM, Gehua Yang <yan...@gm...> wrote: > >> Hi Daniel, >> >> Thank you for the information. By the way, is there an easy way for you >> to add a test case targeting this bug on geotiff? Then it will be much >> easier to monitor the failures on the dashboard. >> >> Gehua. >> >> >> >> On Tue, Dec 9, 2014 at 10:21 AM, Daniel Crispell <dan...@gm...> >> wrote: >> >>> 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 < >>> ami...@us...> 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 <yan...@gm...> 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 <yan...@gm...> >>>>> 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...@li... >>>>> 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...@li... >>>> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers >>>> >>>> >>> >> > |