[otb-users] Re: otb-mosaic ram estimation

2018-09-29 Thread Gus
Thanks, Remi. That's what I imagined. In fact, I processed them using two subsets and using two threads but the results were not satisfactory. Your splitting strategy makes much more sense of course. On Saturday, September 29, 2018 at 12:37:45 PM UTC+2, Rémi wrote: > > Hello Gus, > > The logs

[otb-users] Re: otb-mosaic ram estimation

2018-09-29 Thread Rémi
Hello Gus, The logs help, thanks. The application crashes when the statistics are summarized, because there is not enough memory to store the mutual statistics for your 3582 images. In short, the mutual statistics between couple of images (i,j) are stored in matrices of size NxN (N = 3582

[otb-users] Re: otb-mosaic ram estimation

2018-09-24 Thread Gus
Sorry about the delay. I used gdal_translate as you told and some gdalinfo output sample is now: https://pastebin.com/dzXLKQp4 I will leave this running the no harmonization pipeline and next one tomorrow. In case it fails, I will try again with a clean installation (half my hd is full of

[otb-users] Re: otb-mosaic ram estimation

2018-09-19 Thread Rémi
Hello Gus, I don't think so because the entire process is streamable. It's difficult for me to help you without the full log. Can you run on linux the following commands: otbcli_Mosaic -il /media/gus/Gus/seagrass/3_band/* -out /media/gus/Gus/seagrass/processed_data/r2_simple_noharmo.tif uint8

[otb-users] Re: otb-mosaic ram estimation

2018-09-18 Thread Gus
No, it didn't, but I separated two sets, one for each flight, and one of them did ran (I still didn't try the other). May it be related to some convergence during optimization process? On Tuesday, September 18, 2018 at 10:30:28 AM UTC+2, Rémi wrote: > > do you mean that, for every single input

[otb-users] Re: otb-mosaic ram estimation

2018-09-18 Thread Rémi
> > do you mean that, for every single input image, I need to load an array > with the full size of the output mosaic? > No. The application computes the distance map for each input image, one by one. Not for the entire mosaic. Did the change of image file format solve your issue? -- --

[otb-users] Re: otb-mosaic ram estimation

2018-09-15 Thread Gus
When you say that "Meaning that, for each input image to mosaic, the distance map will theoretically require the full image in memory to be processed." do you mean that, for every single input image, I need to load an array with the full size of the output mosaic? On Wednesday, September 12,

[otb-users] Re: otb-mosaic ram estimation

2018-09-12 Thread Rémi
Your GeoTiff is compressed (PACKBITS) and has rectangular blocks of 416x320. This problem could come from here has you have 2.5k images. I would give a try to unflate all your images. To do it, use gdal_translate -of "GTiff" -ot "Byte" input.tif output.tif then re-run Mosaic ! Le mercredi 12

[otb-users] Re: otb-mosaic ram estimation

2018-09-12 Thread Gus
Driver: GTiff/GeoTIFF Files: p_731_a.tif Size is 4145, 3189 Coordinate System is: PROJCS["WGS 84 / UTM zone 54S", GEOGCS["WGS 84", DATUM["WGS_1984", SPHEROID["WGS 84",6378137,298.257223563, AUTHORITY["EPSG","7030"]], AUTHORITY["EPSG","6326"]],

[otb-users] Re: otb-mosaic ram estimation

2018-09-12 Thread Rémi
The color space is l-alpha-beta but I don't think it's related to this strange behavior. I suspect that your images are in a non-streamable format. Meaning, you can't read them block by block, instead you are forced to read the entire file. Can you paste a gdalinfo of 1 of your file (feel free

[otb-users] Re: otb-mosaic ram estimation

2018-09-12 Thread Rémi
>From this log, it seems like the problem occurs during statistics computation. To be sure of this, can you please check that the following commands work fine: - otbcli_Mosaic -il /media/gus/Gus/seagrass/3_band/* -out /media/gus/Gus/seagrass/processed_data/r2_simple_noharmo.tif uint8

[otb-users] Re: otb-mosaic ram estimation

2018-09-12 Thread Gus
I tried again last night. OTB 6.6.0 packaged linux version. Command line: ./otbcli_Mosaic -il /media/gus/Gus/seagrass/3_band/* -comp.feather large -harmo.method rgb -harmo.cost musig -out /media/gus/Gus/seagrass/processed_data/r2.tif uint8 -tmpdir /media/gus/Gus/seagrass/processed_data/temp

[otb-users] Re: otb-mosaic ram estimation

2018-09-09 Thread Gus
64-bit windows orfeo toolbox 6.6.0. I launched it from GUI, not from command line. I will try tomorrow again and save a log, although I was thinking on trying to compile in linux. On Sunday, September 9, 2018 at 5:23:19 PM UTC+2, Rémi wrote: > > Hello Gus, > > To investigate a bit I would like

[otb-users] Re: otb-mosaic ram estimation

2018-09-09 Thread Rémi
Hello Gus, To investigate a bit I would like to know if you can copy/paste: -your command line -the full log (In a text file, or on pastebin) What version of OTB, and what OS do you have? Thanks, Rémi Le samedi 8 septembre 2018 18:07:56 UTC+2, Gus a écrit : > > Thanks, Rémi > > Your method

[otb-users] Re: otb-mosaic ram estimation

2018-09-08 Thread Rémi
Hello Gus, The RAM parameter deals only with the memory footprint during mosaic compositing and statistics computation, both streamable pipelines (no limitation on images size). However, the distance map calculation (which is a temporary file, then used as an input of the streamed mosaicing