otb issueshttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues2018-03-28T07:07:24Zhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/104JPEG 2000 write support2018-03-28T07:07:24ZSébastien DinotJPEG 2000 write support_[Mantis Issue 104](https://bugs.orfeo-toolbox.org//view.php?id=104), reported by echristophe, assigned to msavinaud, created: 2009-05-26_
Writing in JPEG 2000 format is currently not supported:
illustrated by ioTuJPEG2000ImageIOCanWrit..._[Mantis Issue 104](https://bugs.orfeo-toolbox.org//view.php?id=104), reported by echristophe, assigned to msavinaud, created: 2009-05-26_
Writing in JPEG 2000 format is currently not supported:
illustrated by ioTuJPEG2000ImageIOCanWrite currently desactivated.
*1304071699 - mickael*Feature move to the wiki: http://wiki.orfeo-toolbox.org/index.php/Feature_Requests
*1401182533 - mickael*this new functionality will be offer through the GDALImageIO which use a GDAL with JPEG2000 driver. See the work done into http://scrum.orfeo-toolbox.org/jira/browse/OTB-297https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/103Not reading support for indexed png2018-01-31T16:36:53ZSébastien DinotNot reading support for indexed png_[Mantis Issue 103](https://bugs.orfeo-toolbox.org//view.php?id=103), reported by echristophe, assigned to echristophe, created: 2009-05-26_
Indexed PNG are not read properly and appear in grey level.
Illustrated by test ioTvCheckReadPN..._[Mantis Issue 103](https://bugs.orfeo-toolbox.org//view.php?id=103), reported by echristophe, assigned to echristophe, created: 2009-05-26_
Indexed PNG are not read properly and appear in grey level.
Illustrated by test ioTvCheckReadPNGIndexee currently desactivated.
*1269167037 - christop*fix by http://hg.orfeo-toolbox.org/OTB/rev/b2f77bebb635
*1317282518 - C Valladeau*Resolved in 03/2010.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/102Segfault on FeatureExtractionApplication2018-01-31T16:36:53ZSébastien DinotSegfault on FeatureExtractionApplication_[Mantis Issue 102](https://bugs.orfeo-toolbox.org//view.php?id=102), reported by gborrut, assigned to ghost, created: 2009-04-22_
First select a feature and press "add".
Select one of the line into the list of results.
Then press "..._[Mantis Issue 102](https://bugs.orfeo-toolbox.org//view.php?id=102), reported by gborrut, assigned to ghost, created: 2009-04-22_
First select a feature and press "add".
Select one of the line into the list of results.
Then press "Clear list" and try to clic into the scroll view.
The third view is not properlu unset and if we move into the scroll the application crashes.
*1240415552 - C Valladeau*Miss a result viewer initialization when ClearAll.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/101OTB gets only one band from a color bmp image2018-01-31T16:36:53ZSébastien DinotOTB gets only one band from a color bmp image_[Mantis Issue 101](https://bugs.orfeo-toolbox.org//view.php?id=101), reported by echristophe, assigned to echristophe, created: 2009-03-30_
OTB gets only one band from a color bmp image. (eg: open with viewer => grey level image).
Mig..._[Mantis Issue 101](https://bugs.orfeo-toolbox.org//view.php?id=101), reported by echristophe, assigned to echristophe, created: 2009-03-30_
OTB gets only one band from a color bmp image. (eg: open with viewer => grey level image).
Might be related to
http://bugs.orfeo-toolbox.org/view.php?id=95
*1269166965 - christop*fix by http://hg.orfeo-toolbox.org/OTB/rev/b2f77bebb635
*1317282373 - C Valladeau*Resolved in 03/2010...https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/100On several applications, clicking on cancel on the file chooser leads to segm...2018-01-31T16:36:52ZSébastien DinotOn several applications, clicking on cancel on the file chooser leads to segmentation fault_[Mantis Issue 100](https://bugs.orfeo-toolbox.org//view.php?id=100), reported by jmichel, assigned to cvalladeau, created: 2009-03-25_
launch the otbInteractiveChangeDetectionApplication,
click on File -> Open Left Image
click on canc..._[Mantis Issue 100](https://bugs.orfeo-toolbox.org//view.php?id=100), reported by jmichel, assigned to cvalladeau, created: 2009-03-25_
launch the otbInteractiveChangeDetectionApplication,
click on File -> Open Left Image
click on cancel
The return value of the fl_file_chooser function might not be entirely tested.
*1241709606 - thomas*Correction for otbInteractiveChangeDetectionAppli and otbSupervisedClassificationAppli applciations.
*1304066780 - julien*I think this bug is really outdated. Shall I close it ?
*1304191288 - christop*I think we can...
*1304329505 - C Valladeau*I check all fl_file_chooser in Appli and monterverdi, it should OK now.
PS : The application doesn't exist anymore (moved in Monteverdi).https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/99Vector data comparison for test2018-01-31T16:36:52ZSébastien DinotVector data comparison for test_[Mantis Issue 99](https://bugs.orfeo-toolbox.org//view.php?id=99), reported by echristophe, assigned to cvalladeau, created: 2009-03-24_
The binary comparison used now for comparison with vector data baselines is not sufficient (and t..._[Mantis Issue 99](https://bugs.orfeo-toolbox.org//view.php?id=99), reported by echristophe, assigned to cvalladeau, created: 2009-03-24_
The binary comparison used now for comparison with vector data baselines is not sufficient (and too restrictive).
An adaptation of the method ReportOnLayer() from the source code of ogrinfo (cf ogrinfo.cpp) would enable to produce an ascii output more developer friendly.
*1250049063 - christop*The comparison for KML is also not sufficient
feTvImageToLineSegmentVectorData
For example:
http://www.orfeo-toolbox.org/Dashboard/testDetails.php?test=701535&build=10638
Order of the points is just rotated.
*1300809774 - mickael*This bug is fixed by the ignore order option of compare ascii ?
I think, it could be closed.
Mickaëlhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/98OTB fail to compile with the option OTB_USE_EXTERNAL_EXPAT ON2018-01-31T16:36:51ZSébastien DinotOTB fail to compile with the option OTB_USE_EXTERNAL_EXPAT ON_[Mantis Issue 98](https://bugs.orfeo-toolbox.org//view.php?id=98), reported by echristophe, assigned to echristophe, created: 2009-03-24_
OTB fail to compile with the option OTB_USE_EXTERNAL_EXPAT is set to ON.
[ 26%] Building CXX obj..._[Mantis Issue 98](https://bugs.orfeo-toolbox.org//view.php?id=98), reported by echristophe, assigned to echristophe, created: 2009-03-24_
OTB fail to compile with the option OTB_USE_EXTERNAL_EXPAT is set to ON.
[ 26%] Building CXX object Utilities/otbkml/CMakeFiles/otbkml.dir/src/kml/dom/kml_handler.o
In file included from /home/christop/OTB/trunk/OTB/Utilities/otbkml/src/kml/dom/kml_handler.cc:35:
/home/christop/OTB/trunk/OTB/Utilities/otbkml/src/kml/dom/kml_handler.h:42:35: error: otb_expat.h: No such file or directory
In file included from /home/christop/OTB/trunk/OTB/Utilities/otbkml/src/kml/dom/kml_handler.h:45,
from /home/christop/OTB/trunk/OTB/Utilities/otbkml/src/kml/dom/kml_handler.cc:35:
*1243317268 - christop*Clean up the expat strategy:
- otbexpat returns to the original name.
- internal itk uses the otbexpat or the system expat
http://hg.orfeo-toolbox.org/OTB/rev/59cc3de88035
*1251863822 - christop*iron now running its nightly with OTB_USE_EXTERNAL_EXPAT ONhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/97Spot 5 orthorectification2018-01-31T16:36:51ZSébastien DinotSpot 5 orthorectification_[Mantis Issue 97](https://bugs.orfeo-toolbox.org//view.php?id=97), reported by echristophe, assigned to jmichel, created: 2009-03-18_
Seems to be some improvement needed with the orthorectification of SPOT5.
Take the otbOrthoRectifApp..._[Mantis Issue 97](https://bugs.orfeo-toolbox.org//view.php?id=97), reported by echristophe, assigned to jmichel, created: 2009-03-18_
Seems to be some improvement needed with the orthorectification of SPOT5.
Take the otbOrthoRectifApplication
Open the OTB-Data/LargeInput/SPOT5_SCENE01/IMAGERY.TIF
Keep the parameter by default and orthorectify (without DEM)
Few hours later (profiling needed! use RPC model instead?), you can see the result: towards the bottom of the image, there is a black line running near the edge. (same on the right edge)
It should not be the case.
I assume it's a confusion with pixel coordinates from the center or the top left corner of the pixel.
*1306339492 - christop*Might be related to the nan from the sensor model outside the image.
*1306403023 - julienm*NaN problem shown in http://hg.orfeo-toolbox.org/OTB/rev/14dd7a3a9b2e
and fixed in http://hg.orfeo-toolbox.org/OTB/rev/648f6b0266e2
*1306423940 - julienm*Attached are the result of orthorectification of a part of the Teheran Spot5,
showing the effect of the "NaN fix".
The artefact is less visible, but there is still a problem.
The artefact are there whether we use a DEM or not
*1306424375 - julienm*Another note. nothing better on the Arcachon Spot 5 in the LargeInput : we still can't orthorectify it as some metadata are wrong or badly interpreted (NaN as corner coordinates)
*1306432597 - julienm*Using the new output of http://hg.orfeo-toolbox.org/OTB/rev/0420230cc2ff,
I attached two graph showing a big discontinuity in the sensor model when crossing the image border.
generation :
- take two points on the two side of the border (in the center, at the bottom)
- tranhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/96RationalQuotientResampleImageFilter2018-01-31T16:36:50ZSébastien DinotRationalQuotientResampleImageFilter_[Mantis Issue 96](https://bugs.orfeo-toolbox.org//view.php?id=96), reported by echristophe, assigned to echristophe, created: 2009-03-18_
Two tests failed since the update of ITK to 3.12.0 (Exception: Requested region is (at least part..._[Mantis Issue 96](https://bugs.orfeo-toolbox.org//view.php?id=96), reported by echristophe, assigned to echristophe, created: 2009-03-18_
Two tests failed since the update of ITK to 3.12.0 (Exception: Requested region is (at least partially) outside the largest possible region):
bfTvRationalQuotientResampleImageFilter
RationalQuotientResampleImageFilterTest
Precisely since this commit: http://www.orfeo-toolbox.org/Dashboard/viewUpdate.php?buildid=3930 (ITK update).
The method EnlargeOutputRequestedRegion() has been removed from the itkShrinkImageFilter (http://hg.orfeo-toolbox.org/OTB/diff/eb58a9705467//Utilities/ITK/Code/BasicFilters/itkShrinkImageFilter.h and http://hg.orfeo-toolbox.org/OTB/diff/eb58a9705467//Utilities/ITK/Code/BasicFilters/itkShrinkImageFilter.txx)
Probably need to adapt the region computation within the RationalQuotientResampleImageFilter.
*1237863913 - christop*Classe removed as unused.
In case it's needed in the future:
hg backout 009a992ffd8chttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/95Read Indexed PNG image file format with GDAL2018-01-31T16:36:49ZSébastien DinotRead Indexed PNG image file format with GDAL_[Mantis Issue 95](https://bugs.orfeo-toolbox.org//view.php?id=95), reported by tfeuvrier, assigned to echristophe, created: 2009-03-02_
The GDAL library can't read an indexed PNG image file (The ITK PNG driver can do it). The color tab..._[Mantis Issue 95](https://bugs.orfeo-toolbox.org//view.php?id=95), reported by tfeuvrier, assigned to echristophe, created: 2009-03-02_
The GDAL library can't read an indexed PNG image file (The ITK PNG driver can do it). The color table is not used to check and use the image as a RGB file format.
The podataseet->GetCount() return 1 channel when we open the sbuv_index.png file. The ioTvCheckReadPNGIndexee test show this problem.
*1269166998 - christop*fix by http://hg.orfeo-toolbox.org/OTB/rev/b2f77bebb635https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/94otb::ImageToEdgePathFilter does not work properly2018-01-31T16:36:49ZSébastien Dinototb::ImageToEdgePathFilter does not work properly_[Mantis Issue 94](https://bugs.orfeo-toolbox.org//view.php?id=94), reported by echristophe, assigned to jmichel, created: 2009-02-26_
The vectorization algorithm used in otb::ImageToEdgePathFilter (and subsequently used in otb::Persist..._[Mantis Issue 94](https://bugs.orfeo-toolbox.org//view.php?id=94), reported by echristophe, assigned to jmichel, created: 2009-02-26_
The vectorization algorithm used in otb::ImageToEdgePathFilter (and subsequently used in otb::PersistentVectorizationImageFilter and all applications) does not work properly.
It can return polygons with one vertex only:
polygon 35 nPoints=1 surface=0 length=0 region size=[18446744073709551565, 18446744073709551440] region nb pixel=8976
[51, 176] -
"Flat" polygons:
polygon 36 nPoints=4 surface=0 length=8 region size=[0, 2] region nb pixel=0
[57, 176.5] - [57, 178.5] - [57, 176.5] - [57, 178.5] -
And all extracted regions are biaised towards the upper-left corner of the image.
Vectorization algorithm needs to be reviewed and may work with coordinates between pixels when extracting polygons.
Test PolygonsVectorization is added in Testing/FA (http://hg.orfeo-toolbox.org/OTB/rev/b858c70e029d).
*1243317171 - christop*Test:
FA-0000094-fe-PolygonsVectorization
is desactivated until somebody is working on it (long term issue).
*1329319127 - C Valladeau*Test still failing. I've activated it to be sure it will be handle...
What do we expect from this filter?
Should we remove single point? Should we remove lines?
*1429260056 - julien*We now have a vectorization filter based on gdal_polygonize API.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/93Opacity is not updated when the Display button is pressed2018-01-31T16:36:48ZSébastien DinotOpacity is not updated when the Display button is pressed_[Mantis Issue 93](https://bugs.orfeo-toolbox.org//view.php?id=93), reported by gborrut, assigned to gborrut, created: 2009-02-16_
The resultViewer Opacity is not correctly updated when the "Display" button is pressed. A default value ..._[Mantis Issue 93](https://bugs.orfeo-toolbox.org//view.php?id=93), reported by gborrut, assigned to gborrut, created: 2009-02-16_
The resultViewer Opacity is not correctly updated when the "Display" button is pressed. A default value is used to display the result while we would like to use the given user value.
*1234799564 - Guillaume*Now, it is possible to activate and deactivate the Diplsay button to observe the result. Indeed the opacity and the chosen channels are correctly displayed.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/92FeatureExtractionApplication: Add button has no effect on textures2018-01-31T16:36:48ZSébastien DinotFeatureExtractionApplication: Add button has no effect on textures_[Mantis Issue 92](https://bugs.orfeo-toolbox.org//view.php?id=92), reported by jinglada, assigned to abricier, created: 2009-02-16_
When selecting a texture feature in the FeatureExtractionApplication, the "Add" button does not add the..._[Mantis Issue 92](https://bugs.orfeo-toolbox.org//view.php?id=92), reported by jinglada, assigned to abricier, created: 2009-02-16_
When selecting a texture feature in the FeatureExtractionApplication, the "Add" button does not add the feature to the list of features to be computed.
*1275664146 - aurelien*All texture features have been tested and added successfully to the list of features to be computed. Unable to reproduce the bug.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/91FeatureExtraction crashes on spectral angle on mono-channel image2018-01-31T16:36:47ZSébastien DinotFeatureExtraction crashes on spectral angle on mono-channel image_[Mantis Issue 91](https://bugs.orfeo-toolbox.org//view.php?id=91), reported by jinglada, assigned to cvalladeau, created: 2009-02-16_
terminate called after throwing an instance of 'itk::ExceptionObject'
what(): /opt/stok/src/OTB/Co..._[Mantis Issue 91](https://bugs.orfeo-toolbox.org//view.php?id=91), reported by jinglada, assigned to cvalladeau, created: 2009-02-16_
terminate called after throwing an instance of 'itk::ExceptionObject'
what(): /opt/stok/src/OTB/Code/BasicFilters/otbSpectralAngleDistanceImageFilter.txx:47:
itk::ERROR: SpectralAngleDistanceImageFilter(0x835a368): Not valid input image : mono channel image not supported.
*1251708915 - C Valladeau*Spectral Angle gives a 0 image with a monochannel image (acos(1)).
Change the error message into : Not valid input image : mono channel gives a null image.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/90Supervised Classification: changing the class color force to relearn2018-01-31T16:36:47ZSébastien DinotSupervised Classification: changing the class color force to relearn_[Mantis Issue 90](https://bugs.orfeo-toolbox.org//view.php?id=90), reported by echristophe, assigned to cvalladeau, created: 2009-02-13_
After learning, any modification to the classes, including the color force to relearn.
Presentatio..._[Mantis Issue 90](https://bugs.orfeo-toolbox.org//view.php?id=90), reported by echristophe, assigned to cvalladeau, created: 2009-02-13_
After learning, any modification to the classes, including the color force to relearn.
Presentation of the results should be separated from the parameters.
*1329312539 - C Valladeau*Issue moved from OTB-Applications to Monteverdi.
Problem still there.
*1329317262 - C Valladeau*Fixed here : http://hg.orfeo-toolbox.org/Monteverdi/rev/5e4c3832742ahttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/89Ascii comparison for test is unreliable2018-01-31T16:36:47ZSébastien DinotAscii comparison for test is unreliable_[Mantis Issue 89](https://bugs.orfeo-toolbox.org//view.php?id=89), reported by echristophe, assigned to cvalladeau, created: 2009-02-07_
The ascii comparison does not compare the end of the ascii file if the baseline is shorter than th..._[Mantis Issue 89](https://bugs.orfeo-toolbox.org//view.php?id=89), reported by echristophe, assigned to cvalladeau, created: 2009-02-07_
The ascii comparison does not compare the end of the ascii file if the baseline is shorter than the test output. See for example the test: coTuPolygon (which should be named coTvPolygon)
*1253952999 - christop*Still unreliable:
http://dash.orfeo-toolbox.org/testDetails.php?test=818503&build=12863
lines are incorrectly identified as different when they are not.
*1300815243 - mickael*The test coTvPolygon seems to be ok now with all platform: http://dash.orfeo-toolbox.org/testSummary.php?project=3&name=coTvPolygon&date=2011-03-22
However feTvImageToFastSIFTKeyPointSetFilterSceneOutputDescriptorAscii (http://dash.orfeo-toolbox.org/testSummary.php?project=3&name=feTvImageToFastSIFTKeyPointSetFilterSceneOutputDescriptorAscii&date=2011-03-22) seems failed on windows platform with release static config.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/88otb::DrawLineSpatialObjectFilter and otb::DrawLineSpatialObjectListFilter are...2018-01-31T16:36:46ZSébastien Dinototb::DrawLineSpatialObjectFilter and otb::DrawLineSpatialObjectListFilter are inneficient_[Mantis Issue 88](https://bugs.orfeo-toolbox.org//view.php?id=88), reported by jmichel, assigned to ghost, created: 2009-02-06_
otb::DrawLineSpatialObjectFilter should take advantage of the itk::LineIterator using the Bresenham algorit..._[Mantis Issue 88](https://bugs.orfeo-toolbox.org//view.php?id=88), reported by jmichel, assigned to ghost, created: 2009-02-06_
otb::DrawLineSpatialObjectFilter should take advantage of the itk::LineIterator using the Bresenham algorithm (already used in DrawPathListFilter).
Memory alocation at the beginning of GenerateData() breaks the streaming (allocation of the largest possible region).
in otb::DrawLineSpatialObjectListFilter, the following code snippet is really problematic :
103 while ( itList != list->end() )
104 {
105
106 m_DrawLineFilter->SetInputImage( this->GetOutput() );
107 m_DrawLineFilter->SetInputLine( *itList );
108 m_DrawLineFilter->Update();
109
110 ++itList;
111
112 }
As the DrawLineSpatialObject copies the input image and draw one single line, this means that if the DrawLineSpatialObjectListFilter has to drawn 10.000 lines, it will copy the whole image 10.000 and draw a single line at each step.
Besides, this is breaking streaming.
*1304066354 - julien*Are these filters deprecated by the new rasterization filters ?
*1324032906 - julien*I do not think we should deprecate the filters since they handle a different kind of data than the rasterization ones.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/87Viewer manager segfault when trying to display complex composition with 1 ban...2018-01-31T16:36:46ZSébastien DinotViewer manager segfault when trying to display complex composition with 1 band image_[Mantis Issue 87](https://bugs.orfeo-toolbox.org//view.php?id=87), reported by echristophe, assigned to jmichel, created: 2009-02-06_
Step to reproduce:
- open single band image
- go to viewer setup
- choose complex composition
=> seg..._[Mantis Issue 87](https://bugs.orfeo-toolbox.org//view.php?id=87), reported by echristophe, assigned to jmichel, created: 2009-02-06_
Step to reproduce:
- open single band image
- go to viewer setup
- choose complex composition
=> segfault
The following access it not controlled:
OTB/Code/Visu/otbImageViewerBase.txx:124
124 double im = static_cast<double>(pixel[m_GreenChannelIndex])
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fb035353770 (LWP 1561)]
0x0000000000512cca in otb::ImageViewerBase<double, double>::ComputeNormalizationFactors (this=0x18201d0)
at /home/christop/OTB/trunk/OTB/Code/Visu/otbImageViewerBase.txx:124
124 double im = static_cast<double>(pixel[m_GreenChannelIndex]);
(gdb) bt
#0 0x0000000000512cca in otb::ImageViewerBase<double, double>::ComputeNormalizationFactors (this=0x18201d0)
at /home/christop/OTB/trunk/OTB/Code/Visu/otbImageViewerBase.txx:124
#1 0x00000000004b5f9a in otb::ImageViewerBase<double, double>::SetViewModel (this=0x18201d0,
viewModel=otb::ImageWidgetBase<double>::COMPLEX_MODULUS)
at /home/christop/OTB/trunk/OTB/Code/Visu/otbImageViewerBase.txx:1155
#2 0x00000000004c5984 in otb::ImageViewerManager<double>::ViewerSetupOk (this=0x180bc20)
at /home/christop/OTB/trunk/OTB-Applications/ViewerManager/otbImageViewerManager.txx:657
#3 0x0000000000517b5e in ImageViewerManagerGUI::cb_guiViewerSetupOk_i (this=0x180bd08)
at /home/christop/OTB/OTB-Binary-Applications-Debug/ViewerManager/otbImageViewerManagerGUI.cxx:90
#4 0x0000000000517b91 in ImageViewerManagerGUI::cb_guiViewerSetupOk (o=0x1812120, v=0x0)
at /home/christop/OTB/OTB-Binary-Applications-Debug/ViewerManager/otbImageViewerManagerGUI.cxx:93
#5 0x000000000051b23e in Fl_Widget::do_callback (this=0x1812120) at /usr/include/FL/Fl_Widget.H:187
#6 0x00007fb030a71594 in Fl_Button::handle () from /usr/bin/../lib/libfltk.so.1.1
#7 0x00007fb030a6a38e in ?? () from /usr/bin/../lib/libfltk.so.1.1
#8 0x00007fb030a6b4bc in Fl::handle () from /usr/bin/../lib/libfltk.so.1.1
#9 0x00007fb030ab2897 in fl_handle () from /usr/bin/../lib/libfltk.so.1.1
#10 0x00007fb030ab3b24 in ?? () from /usr/bin/../lib/libfltk.so.1.1
#11 0x00007fb030ab4374 in fl_wait () from /usr/bin/../lib/libfltk.so.1.1
#12 0x00007fb030a6bf58 in Fl::wait () from /usr/bin/../lib/libfltk.so.1.1
#13 0x00007fb030a6c07d in Fl::run () from /usr/bin/../lib/libfltk.so.1.1
#14 0x000000000047f388 in main (argc=4, argv=0x7fff3d52c548)
at /home/christop/OTB/trunk/OTB-Applications/ViewerManager/otbImageViewerManager.cxx:44
*1233930896 - julien*This also occurs when selecting RGB composition mode, except the ViewerManager does not crash but returns with an uncaught exception. The fields to select channels in the viewer setup interface are left blank in both cases.
The fix should both control and throw exception before accessing to data in otb::ViewerBase, and fill the fields with possible value and catch possible exception in the ViewerManager.
*1233937159 - julien*Added more control and exceptions in otbImageViewerBase.txx and otbImageWidgetBase.txx:
http://hg.orfeo-toolbox.org/OTB/rev/e8797595d5f6
Added automatic fill of the channel fields with available values in otbImageViewerManager as well as fl_alert exception reporting in case the user forces wrong channel indices:
http://hg.orfeo-toolbox.org/OTB-Applications/rev/03f8f0b1091a
*1234175745 - julien*Fixed.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/86Conflict between gdal > 1.5.2 and tiff/geotiff on Debian platforms2018-01-31T16:36:45ZSébastien DinotConflict between gdal > 1.5.2 and tiff/geotiff on Debian platforms_[Mantis Issue 86](https://bugs.orfeo-toolbox.org//view.php?id=86), reported by vschut, assigned to jmichel, created: 2009-02-05_
OTB and -Applications cannot open geotiff files when linked to a gdal library version > 1.5.2. Current gda..._[Mantis Issue 86](https://bugs.orfeo-toolbox.org//view.php?id=86), reported by vschut, assigned to jmichel, created: 2009-02-05_
OTB and -Applications cannot open geotiff files when linked to a gdal library version > 1.5.2. Current gdal official stable version however is 1.6.0, and this version contains some major improvements (notably bigtiff support).
For more information, see the mailing list thread with subject "crash
with any otb-app reading tiff image" starting October 23, 2008.
OTB and -Apps compile OK against a newer gdal, however when trying to read a tiff file, I get the following backtrace:
otbImageViewer -in ~/data/modis/moyd09aq1_angcor_compositeHiNDBI10_Borneo250_2003_001.tif
*** glibc detected *** otbImageViewer: munmap_chunk(): invalid pointer: 0x00000000010c0000 ***
======= Backtrace: =========
/lib/libc.so.6[0x7fd809d718b8]
/usr/local/lib/libgdal.so.1(VSIFree+0x1c)[0x7fd811d9d767]
/usr/local/lib/libgdal.so.1(_TIFFfree+0x15)[0x7fd811d191c0]
/usr/local/lib/libgdal.so.1(TIFFCleanup+0x54)[0x7fd811cc8538]
/usr/local/lib/libgdal.so.1(TIFFClose+0x33)[0x7fd811cc8782]
/usr/local/lib/libgdal.so.1(XTIFFClose+0x15)[0x7fd811d3e27b]
/usr/local/lib/otb/libotbossim.so(_ZN12ossimGeoTiffD1Ev+0x3b)[0x7fd810d4d309]
/usr/local/lib/otb/libotbossim.so(_ZNK26ossimTiffProjectionFactory16createProjectionERK13ossimFilenamej+0x1b5)[0x7fd810dc4399]
/usr/local/lib/otb/libotbossim.so(_ZNK30ossimProjectionFactoryRegistry16createProjectionERK13ossimFilenamej+0x65)[0x7fd810e44663]
/usr/local/lib/otb/libotbossim.so(_ZN17ossimImageHandler16getImageGeometryER16ossimKeywordlistPKc+0x66d)[0x7fd8112427df]
otbImageViewer(_ZN3otb15ImageFileReaderINS_11VectorImageIdLj2EEEE25GenerateOutputInformationEv+0xda9)[0x51a1fd]
/usr/local/lib/otb/libITKCommon.so.3.10(_ZN3itk13ProcessObject23UpdateOutputInformationEv+0x1b9)[0x7fd80d7a8637]
otbImageViewer(main+0x14d4)[0x47e720]
/lib/libc.so.6(__libc_start_main+0xe6)[0x7fd809d1d546]
otbImageViewer[0x47d119]
======= Memory map: ========
00400000-00560000 r-xp 00000000 fe:03 439251 /usr/local/bin/otbImageViewer
0075f000-00761000 rw-p 0015f000 fe:03 439251 /usr/local/bin/otbImageViewer
00f45000-01217000 rw-p 00f45000 00:00 0 [heap]
41f12000-41f14000 rwxp 00000000 00:0d 1581 /dev/zero
7fd8046ed000-7fd8047cf000 rw-p 7fd8046ed000 00:00 0
7fd8047cf000-7fd8047d4000 r-xp 00000000 fe:01 454746 /usr/lib/libXdmcp.so.6.0.0
7fd8047d4000-7fd8048d3000 ---p 00005000 fe:01 454746 /usr/lib/libXdmcp.so.6.0.0
7fd8048d3000-7fd8048d4000 rw-p 00004000 fe:01 454746 /usr/lib/libXdmcp.so.6.0.0
7fd8048d4000-7fd8048dc000 r-xp 00000000 fe:01 683146 /lib/libcrypt-2.9.so
7fd8048dc000-7fd804adc000 ---p 00008000 fe:01 683146 /lib/libcrypt-2.9.so
7fd804adc000-7fd804add000 r--p 00008000 fe:01 683146 /lib/libcrypt-2.9.so
7fd804add000-7fd804ade000 rw-p 00009000 fe:01 683146 /lib/libcrypt-2.9.so
7fd804ade000-7fd804b0c000 rw-p 7fd804ade000 00:00 0
7fd804b0c000-7fd804c46000 r-xp 00000000 fe:01 453631 /usr/lib/libgeos-3.0.0.so
7fd804c46000-7fd804e45000 ---p 0013a000 fe:01 453631 /usr/lib/libgeos-3.0.0.so
7fd804e45000-7fd804e4f000 rw-p 00139000 fe:01 453631 /usr/lib/libgeos-3.0.0.so
7fd804e4f000-7fd804e51000 r-xp 00000000 fe:01 451918 /usr/lib/libXau.so.6.0.0
7fd804e51000-7fd805050000 ---p 00002000 fe:01 451918 /usr/lib/libXau.so.6.0.0
7fd805050000-7fd805051000 rw-p 00001000 fe:01 451918 /usr/lib/libXau.so.6.0.0
7fd805051000-7fd80506c000 r-xp 00000000 fe:01 450857 /usr/lib/libxcb.so.1.0.0
7fd80506c000-7fd80526c000 ---p 0001b000 fe:01 450857 /usr/lib/libxcb.so.1.0.0
7fd80526c000-7fd80526d000 rw-p 0001b000 fe:01 450857 /usr/lib/libxcb.so.1.0.0
7fd80526d000-7fd80526e000 r-xp 00000000 fe:01 450913 /usr/lib/libxcb-xlib.so.0.0.0
7fd80526e000-7fd80546d000 ---p 00001000 fe:01 450913 /usr/lib/libxcb-xlib.so.0.0.0
7fd80546d000-7fd80546e000 rw-p 00000000 fe:01 450913 /usr/lib/libxcb-xlib.so.0.0.0
7fd80546e000-7fd80546f000 r-xp 00000000 fe:01 450823 /usr/lib/libnvidia-tls.so.180.27
7fd80546f000-7fd80556f000 ---p 00001000 fe:01 450823 /usr/lib/libnvidia-tls.so.180.27
7fd80556f000-7fd805570000 rw-p 00001000 fe:01 450823 /usr/lib/libnvidia-tls.so.180.27
7fd805570000-7fd80630e000 r-xp 00000000 fe:01 450972 /usr/lib/libGLcore.so.180.27
7fd80630e000-7fd80640e000 ---p 00d9e000 fe:01 450972 /usr/lib/libGLcore.so.180.27
7fd80640e000-7fd806845000 rwxp 00d9e000 fe:01 450972 /usr/lib/libGLcore.so.180.27
7fd806845000-7fd806857000 rwxp 7fd806845000 00:00 0
7fd806857000-7fd806870000 r-xp 00000000 fe:03 885113 /usr/local/lib/libfltk_zlib.so
7fd806870000-7fd806a6f000 ---p 00019000 fe:03 885113 /usr/local/lib/libfltk_zlib.so
7fd806a6f000-7fd806a70000 rw-p 00018000 fe:03 885113 /usr/local/lib/libfltk_zlib.so
7fd806a70000-7fd806a9b000 r-xp 00000000 fe:03 885114 /usr/local/lib/libfltk_jpeg.so
7fd806a9b000-7fd806c9b000 ---p 0002b000 fe:03 885114 /usr/local/lib/libfltk_jpeg.so
7fd806c9b000-7fd806c9c000 rw-p 0002b000 fe:03 885114 /usr/local/lib/libfltk_jpeg.so
7fd806c9c000-7fd806cd2000 r-xp 00Aborted
*1233899531 - christop*Tried successfully to use gdal 1.6.0 on linux 32 bit and linux 64 bits plateforms.
What I did:
- build gdal 1.6.0 from the source keeping the default options (just the --prefix option)
- build OTB, setting the GDAL_INCLUDE_DIRS and GDAL_LIBRARY_DIRS to the newly installed gdal (not changing the other options)
- build OTB-Applications
open a Tiff file with the otbViewerManager. I assume the files were geotiff: qb_roadextract.tif and a Quickbird image from digital globe.
ldd shows that the viewer I used is correctly linked with the new gdal
ldd ./otbImageViewerManager | grep gdal
libgdal.so.1 => /home/christop/slash/lib/libgdal.so.1 (0x00007f50c1eab000)
*1233913625 - Vincent Schut*I've been rethinking my previous (oct 2008) experiences with this, and I think the issue is not so much gdal, as wel the used libtiff and/or libgeotiff versions. According to gdal's web pages (http://www.gdal.org/frmt_gtiff.html), bigtiff support is included since gdal 1.5.0, *when gdal is comhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/85Adding libossim in the TARGET_LINK_LIBRARIES may make your test fail2018-01-31T16:36:44ZSébastien DinotAdding libossim in the TARGET_LINK_LIBRARIES may make your test fail_[Mantis Issue 85](https://bugs.orfeo-toolbox.org//view.php?id=85), reported by gborrut, assigned to echristophe, created: 2009-01-21_
One test coded in the BasicFilter part failed, and the same test coded in the IO part, passed.
The di..._[Mantis Issue 85](https://bugs.orfeo-toolbox.org//view.php?id=85), reported by gborrut, assigned to echristophe, created: 2009-01-21_
One test coded in the BasicFilter part failed, and the same test coded in the IO part, passed.
The difference was in the TARGET_LINK_LIBRARIES of the CMakeList.txt, where otbossim was linked with the failing test, but was unnecessary.
Finaly, no more libossim, no more segfault.
*1233834384 - christop*Is it possible to commit a test to illustrate this bug ?
*1237344614 - christop*Probably coming from the ossim library which was not recompiled (see change 3a78d9ad7df6 done one day before)