otb issueshttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues2018-05-31T15:46:02Zhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/5can not read unsigned char three channels data into otb::Image<unsigned char,...2018-05-31T15:46:02ZSébastien Dinotcan not read unsigned char three channels data into otb::Image<unsigned char,2> properly_[Mantis Issue 5](https://bugs.orfeo-toolbox.org//view.php?id=5), reported by jmichel, assigned to gpasero, created: 2008-09-11_
When reading an unsigned char three channels data into otb::Image<unsigned char,2> , the output make no sen..._[Mantis Issue 5](https://bugs.orfeo-toolbox.org//view.php?id=5), reported by jmichel, assigned to gpasero, created: 2008-09-11_
When reading an unsigned char three channels data into otb::Image<unsigned char,2> , the output make no sense at all..
This is not hapenning with otb::Image<double,2>, so there might be a problem with the use of ITK buffer conversion tools, maybe with the precision used to compute the luminance value from the 3 input channels.
*1276873422 - aurelien*The issue is due to itk::ConvertPixelBuffer::ConvertRGBAToGray that converts an otbVectorImage<unsigned char, 2> to an otbImage<unsigned char, 2> using the formula:
((2125.0 * static_cast<double>Chanel_R +
7154.0 * static_cast<double>Chanel_G +
0721.0 * static_cast<double>Chanel_B) / 1000.0)
* static_cast<double>Chanel_A
According to the fact that default value for a A chanel pixel is 255 , the resulting value is not reasonably castable into an unsigned char.
This bug will be transmitted to ITK dev team asap.
*1291292276 - aurelien*This bug has been fixed by ITK:
http://public.kitware.com/Bug/view.php?id=10917
*1291481328 - christop*We should cherry-pick the fix to include it in OTB, no?
*1291622517 - aurelien*OTB does not use ITK IO to read/write png anymore.
*1291654834 - christop*http://itk.org/gitweb?p=ITK.git;a=commit;h=54e364b981f351a3acbbbcaa0eec332a5218b119
the issue look like it is in the itk::ConvertPixelBuffer.
There might be other placeshttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/10otbSegmentationApplication: Wrong segment location2018-01-31T16:47:45ZSébastien DinototbSegmentationApplication: Wrong segment location_[Mantis Issue 10](https://bugs.orfeo-toolbox.org//view.php?id=10), reported by jmichel, assigned to echristophe, created: 2008-09-12_
Changing the selected region with a segmentation workshop open result in wrong location for the segme..._[Mantis Issue 10](https://bugs.orfeo-toolbox.org//view.php?id=10), reported by jmichel, assigned to echristophe, created: 2008-09-12_
Changing the selected region with a segmentation workshop open result in wrong location for the segmentation result of this workshop.
The best fix would be to prevent the user from selecting a new region while a workshop is open.
*1221207799 - julien*Bug fix commited.
*1221207825 - julien*Fix suggestion implemented.
Bug fix commited.
*1223345256 - christop*Bug fix prevents user from selecting a new area to segment.
*1223349336 - christop*Adding cancel callback to windowhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/11SegmentationApplicationViewGUI::RefreshViewer() when changing the filename to...2018-01-31T16:45:55ZSébastien DinotSegmentationApplicationViewGUI::RefreshViewer() when changing the filename to open_[Mantis Issue 11](https://bugs.orfeo-toolbox.org//view.php?id=11), reported by echristophe, assigned to gborrut, created: 2008-10-07_
In the Segmentation application, when opening a second image, the viewer is not refreshed.
This come..._[Mantis Issue 11](https://bugs.orfeo-toolbox.org//view.php?id=11), reported by echristophe, assigned to gborrut, created: 2008-10-07_
In the Segmentation application, when opening a second image, the viewer is not refreshed.
This comes from the condition checking in SegmentationApplicationViewGUI::RefreshViewer() (otbSegmentationApplicationViewGUI.cxx:84):
if(m_Viewer.IsNull())
The test should also consider cases where the filename has changed and the viewer need to be refreshed. A solution might be to add a boolean in the otb::ImageViewerBase class to indicate a change or to take advantage of the pipeline notification to detect a need for refresh.
*1231493278 - Guillaume*Corrected.
*1231513533 - Guillaume*Corrected.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/12Viewer segfault when displaying 2 bands image as RGB composition2018-01-31T16:45:55ZSébastien DinotViewer segfault when displaying 2 bands image as RGB composition_[Mantis Issue 12](https://bugs.orfeo-toolbox.org//view.php?id=12), reported by echristophe, assigned to echristophe, created: 2008-10-21_
Example with the viewer manager:
Load a 2 bands image, click on viewer setup, change to RGB, set ..._[Mantis Issue 12](https://bugs.orfeo-toolbox.org//view.php?id=12), reported by echristophe, assigned to echristophe, created: 2008-10-21_
Example with the viewer manager:
Load a 2 bands image, click on viewer setup, change to RGB, set 1 for Red, 2 for Green and 2 for Blue, validate (the scroll is fine), click on show -> segfault.
Apparently, this happend when displaying the histogram:
#6 0x00000000004e01f6 in otb::ImageViewerBase<double, double>::Show (this=0x1531070) at /home/christop/OTB/trunk/OTB/Code/Visu/otbImageViewerBase.txx:439
439 m_GreenHistogramWidget->show();
(gdb) list
434 {
435 m_RedHistogramWidget->show();
436
437 if(this->GetViewModel()== ScrollWidgetType::RGB)
438 {
439 m_GreenHistogramWidget->show();
440 m_BlueHistogramWidget->show();
441 }
442 }
*1228194402 - christop*Does not seems to fail anymore after changeset 73165a654580
http://hg.orfeo-toolbox.org/OTB/rev/73165a654580https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/13otbPireo crashes when no parameter is set2018-01-31T16:45:55ZSébastien DinototbPireo crashes when no parameter is set_[Mantis Issue 13](https://bugs.orfeo-toolbox.org//view.php?id=13), reported by jinglada, assigned to cvalladeau, created: 2008-10-21_
After launching otbPireo, select 2 images, select display metric values, run registration (without se..._[Mantis Issue 13](https://bugs.orfeo-toolbox.org//view.php?id=13), reported by jinglada, assigned to cvalladeau, created: 2008-10-21_
After launching otbPireo, select 2 images, select display metric values, run registration (without setting registration parameters): segfault
Initial Transform Parameters
[]
ExceptionObject caught !
itk::ExceptionObject (0x8797af8)
Location: "void itk::MultiResolutionImageRegistrationMethod<TFixedImage, TMovingImage>::PreparePyramids() [with TFixedImage = otb::Image<double, 2u>, TMovingImage = otb::Image<double, 2u>]"
File: /opt/stok/src/OTB/Utilities/ITK/Code/Algorithms/itkMultiResolutionImageRegistrationMethod.txx
Line: 198
Description: itk::ERROR: MultiResolutionImageRegistrationMethod(0x875cd80): Transform is not present
Final Transform Parameters
[0]
[1] 25420 segmentation fault ./bin/otbPireo
*1231773227 - C Valladeau*Add a control of the parameters list. Launch registration only if param size!=0 else, display a message on the terminal.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/14Progress bar not appearing in otbLandCoverMapApplication2018-01-31T16:45:55ZSébastien DinotProgress bar not appearing in otbLandCoverMapApplication_[Mantis Issue 14](https://bugs.orfeo-toolbox.org//view.php?id=14), reported by jinglada, assigned to abricier, created: 2008-10-27_
The progress bar appears at the end of the processing. During the processing the GUI is frozen.
*12756..._[Mantis Issue 14](https://bugs.orfeo-toolbox.org//view.php?id=14), reported by jinglada, assigned to abricier, created: 2008-10-27_
The progress bar appears at the end of the processing. During the processing the GUI is frozen.
*1275649182 - aurelien*Unable to reproduce the bug, can you be more specific? Both the "Generating Output..." and "Denerating Overlay Quicklook..." progress bars seem to work properly.
*1317283755 - C Valladeau*Bug opened in 2008.
OK now.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/15Filter watchers not working with writers2018-01-31T16:45:55ZSébastien DinotFilter watchers not working with writers_[Mantis Issue 15](https://bugs.orfeo-toolbox.org//view.php?id=15), reported by jinglada, assigned to jmichel, created: 2008-10-28_
The progress is not reported. It is only shown at the end of the processing. It works with filters.
Wit..._[Mantis Issue 15](https://bugs.orfeo-toolbox.org//view.php?id=15), reported by jinglada, assigned to jmichel, created: 2008-10-28_
The progress is not reported. It is only shown at the end of the processing. It works with filters.
With non streamed writers there is no information at the beginning of the processing and one gets:
ImageFileWriter "Writing"
Filter took 0.300398 seconds.
at the end. Note the absence of [***].
With streamed writers the output is:
1. at the beginning of the processing: "StreamingImageFileWriter "Writing"
2. At the end:
Processing progress:100% [**************************************************]
Filter took 98.7035 seconds.
With the watcher on a filter the behaviours is OK.
This was tested with a StandardFilterWatcher, but the behaviour is the same for the FltkFilterWatcher.
All application suffer from this. Only the watchers plugged on filters work: quick-look generation for the viewer, for instance.
*1225263433 - christop*Behaviour is similar with an itk::ImageFileWriter instead of the otb::ImageFileWriter
*1231515503 - julien*The new writer watcher fixes this bug.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/16How to deal with MW output extension .img2018-01-31T16:45:56ZSébastien DinotHow to deal with MW output extension .img_[Mantis Issue 16](https://bugs.orfeo-toolbox.org//view.php?id=16), reported by jinglada, assigned to cvalladeau, created: 2008-10-29_
Collision of image format extensions between ERDAS (Gdal) and MegaWave.
Eric Bughin has modified the..._[Mantis Issue 16](https://bugs.orfeo-toolbox.org//view.php?id=16), reported by jinglada, assigned to cvalladeau, created: 2008-10-29_
Collision of image format extensions between ERDAS (Gdal) and MegaWave.
Eric Bughin has modified the class in order to accept .img, .mw and no-extension files for read, but only .mw for write.
*1231834475 - julien*Same problem for pds data available here :
http://download.osgeo.org/gdal/data/pds/
*1231841781 - julien*Added four tests to hightlight this in Testing/Code/IO. The tests highlight that one of the two images available on gdal.org is properly read by gdal and otb::ImageFileReader, while the other is not : gdal can not read it, and that is probably why MWImageIO is trying to read it too.
It is important to note that gdalinfo is not able to read this image outside of the Orfeo ToolBox.
*1313594153 - C Valladeau*The 4 MWImageIO tests seems to pass now.
What's the status of the bug?
*1313637534 - christop*No test is checking if we can write megawave img (but is that something we want?)
*1321458250 - C Valladeau*HFAGeoreferenced.img => mg not from MW
QB_Toulouse_Ortho_PAN.img => from MW
I've made some tests :
The ioTuMWImageIOCanRead Tests applied to a .img from MW returns true.
The ioTuMWImageIOCanRead Tests applied to a .img not from MW returns false.
The ioTuMWImageIOhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/17otbLandCoverMapApplication does not load second image2018-01-31T16:45:56ZSébastien DinototbLandCoverMapApplication does not load second image_[Mantis Issue 17](https://bugs.orfeo-toolbox.org//view.php?id=17), reported by echristophe, assigned to cvalladeau, created: 2008-10-29_
How to reproduce:
- launch the otbLandCoverMapApplication
- open image
- load model
- process imag..._[Mantis Issue 17](https://bugs.orfeo-toolbox.org//view.php?id=17), reported by echristophe, assigned to cvalladeau, created: 2008-10-29_
How to reproduce:
- launch the otbLandCoverMapApplication
- open image
- load model
- process image
- open image
-> the first image is still displayed.
*1228380811 - C Valladeau*Same thing with the following script:
- Open Image
- Open another image
*1228786595 - christop*First point:
When reopening a new image, the overlay corresponding to the first image should not be displayed anymore:
- launch the otbLandCoverMapApplication
- open image
- load model
- process image
- open image
Second point:
The overlay in the scroll window is not the correct one (no subsampling)
*1231841291 - Guillaume*Corrected.
http://hg.orfeo-toolbox.org/OTB-Applications/rev/2ec3be683d53https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/18compare ascii accept test output to be longer that baseline2018-01-31T16:45:56ZSébastien Dinotcompare ascii accept test output to be longer that baseline_[Mantis Issue 18](https://bugs.orfeo-toolbox.org//view.php?id=18), reported by echristophe, assigned to echristophe, created: 2008-11-04_
compare ascii accept test output to be longer that baseline. Comparison shouldn't stop when end o..._[Mantis Issue 18](https://bugs.orfeo-toolbox.org//view.php?id=18), reported by echristophe, assigned to echristophe, created: 2008-11-04_
compare ascii accept test output to be longer that baseline. Comparison shouldn't stop when end of baseline is reached.
*1225778628 - christop*Corrected by commit:
4657a119f3fdhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/20Reading files containing several images (Modis HDF, Alos polarimetric data)2018-01-31T16:45:56ZSébastien DinotReading files containing several images (Modis HDF, Alos polarimetric data)_[Mantis Issue 20](https://bugs.orfeo-toolbox.org//view.php?id=20), reported by echristophe, assigned to msavinaud, created: 2008-11-07_
OTB can't read Modis HDF product.
This format is readable by gdal. The problem is that it contains..._[Mantis Issue 20](https://bugs.orfeo-toolbox.org//view.php?id=20), reported by echristophe, assigned to msavinaud, created: 2008-11-07_
OTB can't read Modis HDF product.
This format is readable by gdal. The problem is that it contains several subproduct (SUBDATASETS). The assumption implicitly made by the reader that 1 file= 1 otb::Image is wrong in this case.
It would be useful to be able to template the reader on otb::ObjectList<otb::Image<tbd,2> > for example.
A request such as papszMetadata = m_poDataset->GetMetadata("SUBDATASETS"); enable to get a list of subsets:
{'SUBDATASET_2_NAME': 'HDF4_SDS:UNKNOWN:"AM20080501_500m_bands.hdf":
1', 'SUBDATASET_5_NAME': 'HDF4_SDS:UNKNOWN:"AM20080501_500m_bands.hdf":
4', 'SUBDATASET_1_DESC': '[8000x8000] EV_500_RefSB_b0 (16-bit unsigned
integer)', 'SUBDATASET_1_NAME':
'HDF4_SDS:UNKNOWN:"AM20080501_500m_bands.hdf":0', 'SUBDATASET_4_DESC':
'[8000x8000] EV_500_RefSB_b3 (16-bit unsigned integer)',
'SUBDATASET_4_NAME': 'HDF4_SDS:UNKNOWN:"AM20080501_500m_bands.hdf":3',
'SUBDATASET_5_DESC': '[8000x8000] EV_500_RefSB_b4 (16-bit unsigned
integer)', 'SUBDATASET_3_NAME':
'HDF4_SDS:UNKNOWN:"AM20080501_500m_bands.hdf":2', 'SUBDATASET_2_DESC':
'[8000x8000] EV_500_RefSB_b1 (16-bit unsigned integer)',
'SUBDATASET_3_DESC': '[8000x8000] EV_500_RefSB_b2 (16-bit unsigned
integer)'}
for example.
Passing a name corresponding to the subset to gdal (eg: 'HDF4_SDS:UNKNOWN:"AM20080501_500m_bands.hdf":1') will enable it to read the product.
*1232420773 - christop*The same problem occurs for Also polarimetric data.
The same VOL-ALPSRPXXXXXXXXX-H1.1__A file should open two:
IMG-HH-ALPSRPXXXXXXXXX-H1.1__A
IMG-HV-ALPSRPXXXXXXXXX-H1.1__A
Only one is opened (don't know which one).
At a gdal level, everything seems correct.
*1232440134 - christop*Correction:
For Alos/Palsar polarimetric product, using:
typedef std::complex<float> PixelType;
typedef otb::VectorImage<PixelType,2> ImageType;
seems to be able to read the data.
*1266767206 - whatnick*The JAXA-PALSAR CEOS driver was written by me and is maitained by philv. You should contact him for updates. The data is read as however many complex channels can be identified. Using vector images solves this, the data is actually not subdatasets, but vectorimages with same dimensions. Have you tried Cosmo HDF files ? This will be great addition. I will run a test with some we have if you make a reader implementation/mosaicing system with the subdatasets.
*1303391276 - mickael*This probhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/21otbFeatureExtractionApplication crashes for Mean with radius 12018-01-31T16:44:15ZSébastien DinototbFeatureExtractionApplication crashes for Mean with radius 1_[Mantis Issue 21](https://bugs.orfeo-toolbox.org//view.php?id=21), reported by jinglada, assigned to ghost, created: 2008-11-07_
otbFeatureExtractionApplication crashes for Mean with radius 1
The bug does not manifest anymore.
*12278..._[Mantis Issue 21](https://bugs.orfeo-toolbox.org//view.php?id=21), reported by jinglada, assigned to ghost, created: 2008-11-07_
otbFeatureExtractionApplication crashes for Mean with radius 1
The bug does not manifest anymore.
*1227863645 - C Valladeau*No reproduce the problem.
Try with poupees.tif, poupees.png and romania.
With RadiusX = 1, RadiusY = 1;
RadiusX = 2, RadiusY = 1;
RadiusX = 1, RadiusY = 2;
*1227864524 - christop*Confirm that the bug does not seem to appear for me either.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/22Possibility to output original image in otbFeatureExtractionApplication2018-01-31T16:44:09ZSébastien DinotPossibility to output original image in otbFeatureExtractionApplication_[Mantis Issue 22](https://bugs.orfeo-toolbox.org//view.php?id=22), reported by echristophe, assigned to echristophe, created: 2008-11-24_
When creating a feature image with otbFeatureExtractionApplication.
It would be good to be able t..._[Mantis Issue 22](https://bugs.orfeo-toolbox.org//view.php?id=22), reported by echristophe, assigned to echristophe, created: 2008-11-24_
When creating a feature image with otbFeatureExtractionApplication.
It would be good to be able to output the original bands as well as the intensity together with the features produced.
*1227683542 - christop*Solved by commit 0eb450cf81f6https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/23otbSupervisedClassificationApplication can't import/export vector roi properly2018-01-31T16:44:15ZSébastien DinototbSupervisedClassificationApplication can't import/export vector roi properly_[Mantis Issue 23](https://bugs.orfeo-toolbox.org//view.php?id=23), reported by echristophe, assigned to ghost, created: 2008-11-24_
otbSupervisedClassificationApplication don't save the classes ROI properly when choosing to save all.
..._[Mantis Issue 23](https://bugs.orfeo-toolbox.org//view.php?id=23), reported by echristophe, assigned to ghost, created: 2008-11-24_
otbSupervisedClassificationApplication don't save the classes ROI properly when choosing to save all.
In many cases, even when saving the ROI classes one by one, the shapefile output is empty.
*1313676928 - C Valladeau*Application moved in Monteverdi.
Can't reproduce with Monteverdi.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/24otbSegmentationApplication does not clear polygon list2018-01-31T16:44:09ZSébastien DinototbSegmentationApplication does not clear polygon list_[Mantis Issue 24](https://bugs.orfeo-toolbox.org//view.php?id=24), reported by echristophe, assigned to echristophe, created: 2008-11-25_
When using the otbSegmentationApplication, the polygon list is not cleared between extraction ses..._[Mantis Issue 24](https://bugs.orfeo-toolbox.org//view.php?id=24), reported by echristophe, assigned to echristophe, created: 2008-11-25_
When using the otbSegmentationApplication, the polygon list is not cleared between extraction sessions (area) or change of parameter making the application unpractical to extract more than one region.
To reproduce:
- start application
- open image
- segment one area (ex region growing)
- go to another area
- open segmentation and go to label vectorization: it already full of polygons.
*1227688107 - christop*Fixed by commit 22e36285f581.
Some improvement is still required to make the correction more global.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/25DEMToImageGenerator results inconsistent between platforms2018-01-31T16:44:15ZSébastien DinotDEMToImageGenerator results inconsistent between platforms_[Mantis Issue 25](https://bugs.orfeo-toolbox.org//view.php?id=25), reported by echristophe, assigned to echristophe, created: 2008-11-28_
The related test
ioTvossimElevManagerTest
also produce different results.
This problem has to be..._[Mantis Issue 25](https://bugs.orfeo-toolbox.org//view.php?id=25), reported by echristophe, assigned to echristophe, created: 2008-11-28_
The related test
ioTvossimElevManagerTest
also produce different results.
This problem has to be traced down to ossim code. Might be a difference in rounding during the interpolation.
*1232430126 - christop*Added test ioTvossimElevManagerTest2
Value
[6.7, 44.5] -> 2902
should appear as 2868 or 2902 depending on platform.
*1250039353 - christop*The SRTM tiles in used were inconsistent: the common line between two adjacent tiles didn't have the same value. Due to the ossim process, depending on the computer, one or the other tile could be used for these pixels, leading to differences in the output.
SRTM tiles replaces with V3.
*1251863863 - christop*Tests are now finehttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/26NeighborhoodIterators6Test produces different results between plateforms2018-01-31T16:44:15ZSébastien DinotNeighborhoodIterators6Test produces different results between plateforms_[Mantis Issue 26](https://bugs.orfeo-toolbox.org//view.php?id=26), reported by echristophe, assigned to echristophe, created: 2008-11-28_
This is coming from difference in the randomImageSource.
Need to either repair the randomImageSou..._[Mantis Issue 26](https://bugs.orfeo-toolbox.org//view.php?id=26), reported by echristophe, assigned to echristophe, created: 2008-11-28_
This is coming from difference in the randomImageSource.
Need to either repair the randomImageSource or to modify the test to start with a fixed image.
*1229648702 - christop*Added extra baseline: differences are coming from the random generator.
http://hg.orfeo-toolbox.org/OTB-Data/rev/e761fadf9ff4https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/27Prolate segfault2018-01-31T16:44:15ZSébastien DinotProlate segfault_[Mantis Issue 27](https://bugs.orfeo-toolbox.org//view.php?id=27), reported by echristophe, assigned to echristophe, created: 2008-11-28_
bfTvProlateInterpolateImageFunction
and sometimes:
bfTvProlateValidationTest
cause segfaults.
*..._[Mantis Issue 27](https://bugs.orfeo-toolbox.org//view.php?id=27), reported by echristophe, assigned to echristophe, created: 2008-11-28_
bfTvProlateInterpolateImageFunction
and sometimes:
bfTvProlateValidationTest
cause segfaults.
*1228381077 - christop*Confirmed by test:
bfTvProlateInterpolateImageFunction
bfTvProlateValidationTest
*1228497218 - C Valladeau*Correction made (add of a constructor with radius init for the functor).
Wait to see the impact.
*1237347242 - christop*Fixed by:
http://hg.orfeo-toolbox.org/OTB/rev/8d986e704fe5
(multithreading problem)https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/28OTB_GL_USE_ACCEL and external OTB programs2018-01-31T16:44:16ZSébastien DinotOTB_GL_USE_ACCEL and external OTB programs_[Mantis Issue 28](https://bugs.orfeo-toolbox.org//view.php?id=28), reported by echristophe, assigned to echristophe, created: 2008-11-28_
The solution introduced at:
http://hg.orfeo-toolbox.org/OTB/rev/7fd18e37aa99
is not fully satisfa..._[Mantis Issue 28](https://bugs.orfeo-toolbox.org//view.php?id=28), reported by echristophe, assigned to echristophe, created: 2008-11-28_
The solution introduced at:
http://hg.orfeo-toolbox.org/OTB/rev/7fd18e37aa99
is not fully satisfactory.
when compiling an external OTb program, internal OTB variables are not defined, thus resulting in the wrong configuration.
It would be better to find a more global solution (which works for all machines).
Possibilities includes:
- replacing the GL_QUADS by something simplier (and keeping the texture)
- replacing the glPixelZoom by some modification on glOrtho (and keeping the glDrawPixels)
*1228296574 - julien*To find a proper solution to this bug, we would need to know the following things:
- What was the aim of the solution http://hg.orfeo-toolbox.org/OTB/rev/7fd18e37aa99 ?
- Does this solution fix the problem ?
- What is wrong with glPixelZoom ?
*1228297868 - christop*glPixelZoom (it's supposedly coming from that) is causing a problem with ati driver: dark stripes appear and change size when resizing the window.
The problem seems to be linked with the fact that the y zoom factor is negative (no problem if it is positive -> but the image is flipped). Couldn't find more information about this on the internet, but the problem appears also on pc-christophe when the ati driver is loaded.
Besides, glDrawPixels seems to be a slow solution and apparently using textures is recommended.
*1228298691 - julien*Ok. I understand that texture rendering is faster than raw pixels drawing. Was it noticeable when using the old viewer version ?
If the problem comes from the negative zoom factorhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/29otbSupervisedClassificationApplication does not handle class removal properly2018-01-31T16:44:16ZSébastien DinototbSupervisedClassificationApplication does not handle class removal properly_[Mantis Issue 29](https://bugs.orfeo-toolbox.org//view.php?id=29), reported by echristophe, assigned to cvalladeau, created: 2008-11-28_
Open the image
Create 4 classes with polygons
Remove the second one
try to Learn.
Error message ..._[Mantis Issue 29](https://bugs.orfeo-toolbox.org//view.php?id=29), reported by echristophe, assigned to cvalladeau, created: 2008-11-28_
Open the image
Create 4 classes with polygons
Remove the second one
try to Learn.
Error message + segfault
*1313677202 - C Valladeau*Bug move in Monteverdi : http://bugs.orfeo-toolbox.org/view.php?id=405.