[otb-users] otb-mosaic ram estimation

[Gus]

Hello everyone.

I don't clearly understand the process followed by the remote module
"mosaic". The memory occupied during some phase after distance maps
calculation for large blending with lab color space harmonization grows a
lot, so I obtain a huge page file and my computer reboots. I checked the
paper and peeked into the code a bit, but I'm not familiar with the
libraries. Is there any way of estimating the ram needed for the process?
Is there a way of overcoming this issue? (probably I will process it in
chunks anyway but that would simplify things quite a lot).

Cheers

Gus
--
--
Check the OTB FAQ at
http://www.orfeo-toolbox.org/FAQ.html

You received this message because you are subscribed to the Google
Groups "otb-users" group.
To post to this group, send email to otb-***@googlegroups.com
To unsubscribe from this group, send email to
otb-users+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/otb-users?hl=en
---
You received this message because you are subscribed to the Google Groups "otb-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to otb-users+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[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 compositing pipeline, just for
feathering) is not a streamable process. Meaning that, for each input image
to mosaic, the distance map will theoretically require the full image in
memory to be processed. That's why there is the distancemap.sr (sampling
ratio) parameter. This enables the subsampling of the input image, to
compute the distance map with a smaller footprint. See README.md, section
"Performance tuning: Distance map images sampling ratio".
This is a current limitation of the application, I will add this explicitly
in the application description.

Your problem could also come from the fact that your input images have not
the same projection reference (and leading to a near infinite image, e.g.
if you mix degrees and meters units, or with wrong coordinate reference
system), check this.

Hope that helps,

Rémi

Post by Gus
Hello everyone.
I don't clearly understand the process followed by the remote module
"mosaic". The memory occupied during some phase after distance maps
calculation for large blending with lab color space harmonization grows a
lot, so I obtain a huge page file and my computer reboots. I checked the
paper and peeked into the code a bit, but I'm not familiar with the
libraries. Is there any way of estimating the ram needed for the process?
Is there a way of overcoming this issue? (probably I will process it in
chunks anyway but that would simplify things quite a lot).
Cheers
Gus

--
--
Check the OTB FAQ at
http://www.orfeo-toolbox.org/FAQ.html

You received this message because you are subscribed to the Google
Groups "otb-users" group.
To post to this group, send email to otb-***@googlegroups.com
To unsubscribe from this group, send email to
otb-users+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/otb-users?hl=en
---
You received this message because you are subscribed to the Google Groups "otb-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to otb-users+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Gus]

Thanks, Rémi

Your method works fairly well, the results are really good and visually
pleasant. In fact, I was able to use you app (from gui) for small subsets
of my data, which is a set of aerial pictures of the sea surface from which
the sunglint has been removed.

[image: 2dc4d9d7-25da-4254-9cb5-31536801f461.jpg] <about:invalid#zClosurez>[image:
54ed0802-e492-438f-9f4d-8dea3593a2b6.jpg] <about:invalid#zClosurez>

But, when I feed your program with the complete set (about 2500 pictures,
30 Mb each approximately, 8 bit colour) it fails. Last thing I can check is
that the temporary distance maps have been correctly written, and that's
the last console output. while if Iskip the large feathering step, it seems
to work ok, as in next image using slim blending mode, but as for large
blending, it fails...

[image: sea_1PNG.PNG]

Post by 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 compositing pipeline, just for
feathering) is not a streamable process. Meaning that, for each input image
to mosaic, the distance map will theoretically require the full image in
memory to be processed. That's why there is the distancemap.sr (sampling
ratio) parameter. This enables the subsampling of the input image, to
compute the distance map with a smaller footprint. See README.md, section
"Performance tuning: Distance map images sampling ratio".
This is a current limitation of the application, I will add this
explicitly in the application description.
Your problem could also come from the fact that your input images have not
the same projection reference (and leading to a near infinite image, e.g.
if you mix degrees and meters units, or with wrong coordinate reference
system), check this.
Hope that helps,
Rémi

Post by Gus
Hello everyone.
I don't clearly understand the process followed by the remote module
"mosaic". The memory occupied during some phase after distance maps
calculation for large blending with lab color space harmonization grows a
lot, so I obtain a huge page file and my computer reboots. I checked the
paper and peeked into the code a bit, but I'm not familiar with the
libraries. Is there any way of estimating the ram needed for the process?
Is there a way of overcoming this issue? (probably I will process it in
chunks anyway but that would simplify things quite a lot).
Cheers
Gus

--
--
Check the OTB FAQ at
http://www.orfeo-toolbox.org/FAQ.html

You received this message because you are subscribed to the Google
Groups "otb-users" group.
To post to this group, send email to otb-***@googlegroups.com
To unsubscribe from this group, send email to
otb-users+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/otb-users?hl=en
---
You received this message because you are subscribed to the Google Groups "otb-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to otb-users+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[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

Post by Gus
Thanks, Rémi
Your method works fairly well, the results are really good and visually
pleasant. In fact, I was able to use you app (from gui) for small subsets
of my data, which is a set of aerial pictures of the sea surface from which
the sunglint has been removed.
54ed0802-e492-438f-9f4d-8dea3593a2b6.jpg]
But, when I feed your program with the complete set (about 2500 pictures,
30 Mb each approximately, 8 bit colour) it fails. Last thing I can check is
that the temporary distance maps have been correctly written, and that's
the last console output. while if Iskip the large feathering step, it seems
to work ok, as in next image using slim blending mode, but as for large
blending, it fails...
[image: sea_1PNG.PNG]

Post by 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 compositing pipeline, just for
feathering) is not a streamable process. Meaning that, for each input image
to mosaic, the distance map will theoretically require the full image in
memory to be processed. That's why there is the distancemap.sr (sampling
ratio) parameter. This enables the subsampling of the input image, to
compute the distance map with a smaller footprint. See README.md, section
"Performance tuning: Distance map images sampling ratio".
This is a current limitation of the application, I will add this
explicitly in the application description.
Your problem could also come from the fact that your input images have
not the same projection reference (and leading to a near infinite image,
e.g. if you mix degrees and meters units, or with wrong coordinate
reference system), check this.
Hope that helps,
Rémi

Post by Gus
Hello everyone.
I don't clearly understand the process followed by the remote module
"mosaic". The memory occupied during some phase after distance maps
calculation for large blending with lab color space harmonization grows a
lot, so I obtain a huge page file and my computer reboots. I checked the
paper and peeked into the code a bit, but I'm not familiar with the
libraries. Is there any way of estimating the ram needed for the process?
Is there a way of overcoming this issue? (probably I will process it in
chunks anyway but that would simplify things quite a lot).
Cheers
Gus

--
--
Check the OTB FAQ at
http://www.orfeo-toolbox.org/FAQ.html

You received this message because you are subscribed to the Google
Groups "otb-users" group.
To post to this group, send email to otb-***@googlegroups.com
To unsubscribe from this group, send email to
otb-users+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/otb-users?hl=en
---
You received this message because you are subscribed to the Google Groups "otb-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to otb-users+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[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.

Post by Rémi
Hello Gus,
-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

Post by Gus
Thanks, Rémi
Your method works fairly well, the results are really good and visually
pleasant. In fact, I was able to use you app (from gui) for small subsets
of my data, which is a set of aerial pictures of the sea surface from which
the sunglint has been removed.
54ed0802-e492-438f-9f4d-8dea3593a2b6.jpg]
But, when I feed your program with the complete set (about 2500 pictures,
30 Mb each approximately, 8 bit colour) it fails. Last thing I can check is
that the temporary distance maps have been correctly written, and that's
the last console output. while if Iskip the large feathering step, it seems
to work ok, as in next image using slim blending mode, but as for large
blending, it fails...
[image: sea_1PNG.PNG]

Post by 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 compositing pipeline, just for
feathering) is not a streamable process. Meaning that, for each input image
to mosaic, the distance map will theoretically require the full image in
memory to be processed. That's why there is the distancemap.sr
(sampling ratio) parameter. This enables the subsampling of the input
image, to compute the distance map with a smaller footprint. See README.md,
section "Performance tuning: Distance map images sampling ratio".
This is a current limitation of the application, I will add this
explicitly in the application description.
Your problem could also come from the fact that your input images have
not the same projection reference (and leading to a near infinite image,
e.g. if you mix degrees and meters units, or with wrong coordinate
reference system), check this.
Hope that helps,
Rémi

Post by Gus
Hello everyone.
I don't clearly understand the process followed by the remote module
"mosaic". The memory occupied during some phase after distance maps
calculation for large blending with lab color space harmonization grows a
lot, so I obtain a huge page file and my computer reboots. I checked the
paper and peeked into the code a bit, but I'm not familiar with the
libraries. Is there any way of estimating the ram needed for the process?
Is there a way of overcoming this issue? (probably I will process it in
chunks anyway but that would simplify things quite a lot).
Cheers
Gus

--
--
Check the OTB FAQ at
http://www.orfeo-toolbox.org/FAQ.html

You received this message because you are subscribed to the Google
Groups "otb-users" group.
To post to this group, send email to otb-***@googlegroups.com
To unsubscribe from this group, send email to
otb-users+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/otb-users?hl=en
---
You received this message because you are subscribed to the Google Groups "otb-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to otb-users+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[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 -ram 128 -progress 1

Last lines of output:
2018-09-12 03:29:30 (INFO): Computing statistics in a decorrelated colors
space suitable for true-colors
2018-09-12 03:29:44 (INFO): Estimated memory for full processing:
3.15661e+06MB (avail.: 128 MB), optimal image partitioning: 24662 blocks
2018-09-12 03:29:44 (INFO): Estimation will be performed in 18639 blocks of
832x320 pixels

Anyway, after start, used RAM begins to slowly increase until it occupied
my swap space and froze the computer during the night.

[image: Screenshot at 2018-09-12 03-30-10.png]

Post by Rémi
Hello Gus,
-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

Post by Gus
Thanks, Rémi
Your method works fairly well, the results are really good and visually
pleasant. In fact, I was able to use you app (from gui) for small subsets
of my data, which is a set of aerial pictures of the sea surface from which
the sunglint has been removed.
54ed0802-e492-438f-9f4d-8dea3593a2b6.jpg]
But, when I feed your program with the complete set (about 2500 pictures,
30 Mb each approximately, 8 bit colour) it fails. Last thing I can check is
that the temporary distance maps have been correctly written, and that's
the last console output. while if Iskip the large feathering step, it seems
to work ok, as in next image using slim blending mode, but as for large
blending, it fails...
[image: sea_1PNG.PNG]

Post by 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 compositing pipeline, just for
feathering) is not a streamable process. Meaning that, for each input image
to mosaic, the distance map will theoretically require the full image in
memory to be processed. That's why there is the distancemap.sr
(sampling ratio) parameter. This enables the subsampling of the input
image, to compute the distance map with a smaller footprint. See README.md,
section "Performance tuning: Distance map images sampling ratio".
This is a current limitation of the application, I will add this
explicitly in the application description.
Your problem could also come from the fact that your input images have
not the same projection reference (and leading to a near infinite image,
e.g. if you mix degrees and meters units, or with wrong coordinate
reference system), check this.
Hope that helps,
Rémi

Post by Gus
Hello everyone.
I don't clearly understand the process followed by the remote module
"mosaic". The memory occupied during some phase after distance maps
calculation for large blending with lab color space harmonization grows a
lot, so I obtain a huge page file and my computer reboots. I checked the
paper and peeked into the code a bit, but I'm not familiar with the
libraries. Is there any way of estimating the ram needed for the process?
Is there a way of overcoming this issue? (probably I will process it in
chunks anyway but that would simplify things quite a lot).
Cheers
Gus

--
--
Check the OTB FAQ at
http://www.orfeo-toolbox.org/FAQ.html

You received this message because you are subscribed to the Google
Groups "otb-users" group.
To post to this group, send email to otb-***@googlegroups.com
To unsubscribe from this group, send email to
otb-users+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/otb-users?hl=en
---
You received this message because you are subscribed to the Google Groups "otb-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to otb-users+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[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 -ram 128
- otbcli_Mosaic -il /media/gus/Gus/seagrass/3_band/* -comp.feather large
-out /media/gus/Gus/seagrass/processed_data/r2_feather_noharmo.tif uint8
-tmpdir /media/gus/Gus/seagrass/processed_data/temp -ram 128

And can you please tell me if these commands are successful or not:

- otbcli_Mosaic -il /media/gus/Gus/seagrass/3_band/* -harmo.method band
-harmo.cost musig -out
/media/gus/Gus/seagrass/processed_data/r2_harmo-band.tif uint8 -ram 128
- otbcli_Mosaic -il /media/gus/Gus/seagrass/3_band/* -harmo.method rgb
-harmo.cost musig -out
/media/gus/Gus/seagrass/processed_data/r2_harmo-rgb.tif uint8 -ram 128

Now, you can try to set a very small RAM value and tell me what's
happening. Set -ram 1 for instance...

Post by 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 -ram 128 -progress 1
2018-09-12 03:29:30 (INFO): Computing statistics in a decorrelated colors
space suitable for true-colors
3.15661e+06MB (avail.: 128 MB), optimal image partitioning: 24662 blocks
2018-09-12 03:29:44 (INFO): Estimation will be performed in 18639 blocks
of 832x320 pixels
Anyway, after start, used RAM begins to slowly increase until it occupied
my swap space and froze the computer during the night.
[image: Screenshot at 2018-09-12 03-30-10.png]

Post by Rémi
Hello Gus,
-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

Post by Gus
Thanks, Rémi
Your method works fairly well, the results are really good and visually
pleasant. In fact, I was able to use you app (from gui) for small subsets
of my data, which is a set of aerial pictures of the sea surface from which
the sunglint has been removed.
54ed0802-e492-438f-9f4d-8dea3593a2b6.jpg]
But, when I feed your program with the complete set (about 2500
pictures, 30 Mb each approximately, 8 bit colour) it fails. Last thing I
can check is that the temporary distance maps have been correctly written,
and that's the last console output. while if Iskip the large feathering
step, it seems to work ok, as in next image using slim blending mode, but
as for large blending, it fails...
[image: sea_1PNG.PNG]

Post by 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 compositing pipeline, just for
feathering) is not a streamable process. Meaning that, for each input image
to mosaic, the distance map will theoretically require the full image in
memory to be processed. That's why there is the distancemap.sr
(sampling ratio) parameter. This enables the subsampling of the input
image, to compute the distance map with a smaller footprint. See README.md,
section "Performance tuning: Distance map images sampling ratio".
This is a current limitation of the application, I will add this
explicitly in the application description.
Your problem could also come from the fact that your input images have
not the same projection reference (and leading to a near infinite image,
e.g. if you mix degrees and meters units, or with wrong coordinate
reference system), check this.
Hope that helps,
Rémi

Post by Gus
Hello everyone.
I don't clearly understand the process followed by the remote module
"mosaic". The memory occupied during some phase after distance maps
calculation for large blending with lab color space harmonization grows a
lot, so I obtain a huge page file and my computer reboots. I checked the
paper and peeked into the code a bit, but I'm not familiar with the
libraries. Is there any way of estimating the ram needed for the process?
Is there a way of overcoming this issue? (probably I will process it in
chunks anyway but that would simplify things quite a lot).
Cheers
Gus

--
--
Check the OTB FAQ at
http://www.orfeo-toolbox.org/FAQ.html

You received this message because you are subscribed to the Google
Groups "otb-users" group.
To post to this group, send email to otb-***@googlegroups.com
To unsubscribe from this group, send email to
otb-users+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/otb-users?hl=en
---
You received this message because you are subscribed to the Google Groups "otb-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to otb-users+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Gus]

Trying to reduce the RAM value seems to have no effect on memory footprint.
If I set it to 1, it grows a lot at first, then the process seems to
progress very slowly. If I set it to 10, it gows a lot at first, then it
does progress increasingly ocuppying memory. It seems to be independent of
your colour space transform, whatever method you choose, band per band or
(I guess you use cieLab?). I'm testing the no harmonization options that
you told (that I had already tried in windows). It's writing the tiff and
seems to be ok but, although it probably will finish, it's taking a (while
slower) progressively increasing amount of ram.
I tested ram parameter in otbcli_HaralickTextureExtraction and it seems to
correctly make use of chunks within parameter.
Just in case, I'm using imagery of this kind, 8bit unsigned integer where I
use 0 as no value (it worked ok for small sets).

Post by 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
- otbcli_Mosaic -il /media/gus/Gus/seagrass/3_band/* -out
/media/gus/Gus/seagrass/processed_data/r2_simple_noharmo.tif uint8 -ram 128
- otbcli_Mosaic -il /media/gus/Gus/seagrass/3_band/* -comp.feather
large -out /media/gus/Gus/seagrass/processed_data/r2_feather_noharmo.tif
uint8 -tmpdir /media/gus/Gus/seagrass/processed_data/temp -ram 128
- otbcli_Mosaic -il /media/gus/Gus/seagrass/3_band/* -harmo.method
band -harmo.cost musig -out
/media/gus/Gus/seagrass/processed_data/r2_harmo-band.tif uint8 -ram 128
- otbcli_Mosaic -il /media/gus/Gus/seagrass/3_band/* -harmo.method rgb
-harmo.cost musig -out
/media/gus/Gus/seagrass/processed_data/r2_harmo-rgb.tif uint8 -ram 128
Now, you can try to set a very small RAM value and tell me what's
happening. Set -ram 1 for instance...

Post by 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 -ram 128 -progress 1
2018-09-12 03:29:30 (INFO): Computing statistics in a decorrelated colors
space suitable for true-colors
3.15661e+06MB (avail.: 128 MB), optimal image partitioning: 24662 blocks
2018-09-12 03:29:44 (INFO): Estimation will be performed in 18639 blocks
of 832x320 pixels
Anyway, after start, used RAM begins to slowly increase until it occupied
my swap space and froze the computer during the night.
[image: Screenshot at 2018-09-12 03-30-10.png]

Post by Rémi
Hello Gus,
-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

Post by Gus
Thanks, Rémi
Your method works fairly well, the results are really good and visually
pleasant. In fact, I was able to use you app (from gui) for small subsets
of my data, which is a set of aerial pictures of the sea surface from which
the sunglint has been removed.
54ed0802-e492-438f-9f4d-8dea3593a2b6.jpg]
But, when I feed your program with the complete set (about 2500
pictures, 30 Mb each approximately, 8 bit colour) it fails. Last thing I
can check is that the temporary distance maps have been correctly written,
and that's the last console output. while if Iskip the large feathering
step, it seems to work ok, as in next image using slim blending mode, but
as for large blending, it fails...
[image: sea_1PNG.PNG]

Post by 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 compositing pipeline, just for
feathering) is not a streamable process. Meaning that, for each input image
to mosaic, the distance map will theoretically require the full image in
memory to be processed. That's why there is the distancemap.sr
(sampling ratio) parameter. This enables the subsampling of the input
image, to compute the distance map with a smaller footprint. See README.md,
section "Performance tuning: Distance map images sampling ratio".
This is a current limitation of the application, I will add this
explicitly in the application description.
Your problem could also come from the fact that your input images have
not the same projection reference (and leading to a near infinite image,
e.g. if you mix degrees and meters units, or with wrong coordinate
reference system), check this.
Hope that helps,
Rémi

Post by Gus
Hello everyone.
I don't clearly understand the process followed by the remote module
"mosaic". The memory occupied during some phase after distance maps
calculation for large blending with lab color space harmonization grows a
lot, so I obtain a huge page file and my computer reboots. I checked the
paper and peeked into the code a bit, but I'm not familiar with the
libraries. Is there any way of estimating the ram needed for the process?
Is there a way of overcoming this issue? (probably I will process it in
chunks anyway but that would simplify things quite a lot).
Cheers
Gus

--
--
Check the OTB FAQ at
http://www.orfeo-toolbox.org/FAQ.html

You received this message because you are subscribed to the Google
Groups "otb-users" group.
To post to this group, send email to otb-***@googlegroups.com
To unsubscribe from this group, send email to
otb-users+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/otb-users?hl=en
---
You received this message because you are subscribed to the Google Groups "otb-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to otb-users+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[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 to modify
coordinates and stuff) it's just to check the image file format.
If I'm right, you can try to convert all your files in GeoTiff format
(using otbcli_Convert with an output file extension equal to ".tif", then
run the Mosaic application over the fresh .tif files and it will work fine

Rémi

Post by Gus
Trying to reduce the RAM value seems to have no effect on memory
footprint. If I set it to 1, it grows a lot at first, then the process
seems to progress very slowly. If I set it to 10, it gows a lot at first,
then it does progress increasingly ocuppying memory. It seems to be
independent of your colour space transform, whatever method you choose,
band per band or (I guess you use cieLab?). I'm testing the no
harmonization options that you told (that I had already tried in windows).
It's writing the tiff and seems to be ok but, although it probably will
finish, it's taking a (while slower) progressively increasing amount of ram.
I tested ram parameter in otbcli_HaralickTextureExtraction and it seems to
correctly make use of chunks within parameter.
Just in case, I'm using imagery of this kind, 8bit unsigned integer where
I use 0 as no value (it worked ok for small sets).

Post by 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
- otbcli_Mosaic -il /media/gus/Gus/seagrass/3_band/* -out
/media/gus/Gus/seagrass/processed_data/r2_simple_noharmo.tif uint8 -ram 128
- otbcli_Mosaic -il /media/gus/Gus/seagrass/3_band/* -comp.feather
large -out /media/gus/Gus/seagrass/processed_data/r2_feather_noharmo.tif
uint8 -tmpdir /media/gus/Gus/seagrass/processed_data/temp -ram 128
- otbcli_Mosaic -il /media/gus/Gus/seagrass/3_band/* -harmo.method
band -harmo.cost musig -out
/media/gus/Gus/seagrass/processed_data/r2_harmo-band.tif uint8 -ram 128
- otbcli_Mosaic -il /media/gus/Gus/seagrass/3_band/* -harmo.method
rgb -harmo.cost musig -out
/media/gus/Gus/seagrass/processed_data/r2_harmo-rgb.tif uint8 -ram 128
Now, you can try to set a very small RAM value and tell me what's
happening. Set -ram 1 for instance...

Post by 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 -ram 128 -progress 1
2018-09-12 03:29:30 (INFO): Computing statistics in a decorrelated
colors space suitable for true-colors
3.15661e+06MB (avail.: 128 MB), optimal image partitioning: 24662 blocks
2018-09-12 03:29:44 (INFO): Estimation will be performed in 18639 blocks
of 832x320 pixels
Anyway, after start, used RAM begins to slowly increase until it
occupied my swap space and froze the computer during the night.
[image: Screenshot at 2018-09-12 03-30-10.png]

Post by Rémi
Hello Gus,
-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

Post by Gus
Thanks, Rémi
Your method works fairly well, the results are really good and
visually pleasant. In fact, I was able to use you app (from gui) for small
subsets of my data, which is a set of aerial pictures of the sea surface
from which the sunglint has been removed.
54ed0802-e492-438f-9f4d-8dea3593a2b6.jpg]
But, when I feed your program with the complete set (about 2500
pictures, 30 Mb each approximately, 8 bit colour) it fails. Last thing I
can check is that the temporary distance maps have been correctly written,
and that's the last console output. while if Iskip the large feathering
step, it seems to work ok, as in next image using slim blending mode, but
as for large blending, it fails...
[image: sea_1PNG.PNG]

Post by 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 compositing pipeline, just
for feathering) is not a streamable process. Meaning that, for each input
image to mosaic, the distance map will theoretically require the full image
in memory to be processed. That's why there is the distancemap.sr
(sampling ratio) parameter. This enables the subsampling of the input
image, to compute the distance map with a smaller footprint. See README.md,
section "Performance tuning: Distance map images sampling ratio".
This is a current limitation of the application, I will add this
explicitly in the application description.
Your problem could also come from the fact that your input images
have not the same projection reference (and leading to a near infinite
image, e.g. if you mix degrees and meters units, or with wrong coordinate
reference system), check this.
Hope that helps,
Rémi

Post by Gus
Hello everyone.
I don't clearly understand the process followed by the remote module
"mosaic". The memory occupied during some phase after distance maps
calculation for large blending with lab color space harmonization grows a
lot, so I obtain a huge page file and my computer reboots. I checked the
paper and peeked into the code a bit, but I'm not familiar with the
libraries. Is there any way of estimating the ram needed for the process?
Is there a way of overcoming this issue? (probably I will process it in
chunks anyway but that would simplify things quite a lot).
Cheers
Gus

--
--
Check the OTB FAQ at
http://www.orfeo-toolbox.org/FAQ.html

You received this message because you are subscribed to the Google
Groups "otb-users" group.
To post to this group, send email to otb-***@googlegroups.com
To unsubscribe from this group, send email to
otb-users+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/otb-users?hl=en
---
You received this message because you are subscribed to the Google Groups "otb-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to otb-users+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[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"]],
PRIMEM["Greenwich",0,
AUTHORITY["EPSG","8901"]],
UNIT["degree",0.0174532925199433,
AUTHORITY["EPSG","9122"]],
AUTHORITY["EPSG","4326"]],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",0],
PARAMETER["central_meridian",141],
PARAMETER["scale_factor",0.9996],
PARAMETER["false_easting",500000],
PARAMETER["false_northing",10000000],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]],
AXIS["Easting",EAST],
AXIS["Northing",NORTH],
AUTHORITY["EPSG","32754"]]
Origin = (271914.159999999974389,6123214.030000000260770)
Pixel Size = (1.000000000000000,-1.000000000000000)
Metadata:
AREA_OR_POINT=Area
Image Structure Metadata:
COMPRESSION=PACKBITS
INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left ( 271914.160, 6123214.030) (138d30' 1.82"E, 35d 0'28.82"S)
Lower Left ( 271914.160, 6120025.030) (138d29'58.67"E, 35d 2'12.24"S)
Upper Right ( 276059.160, 6123214.030) (138d32'45.20"E, 35d 0'32.15"S)
Lower Right ( 276059.160, 6120025.030) (138d32'42.11"E, 35d 2'15.58"S)
Center ( 273986.660, 6121619.530) (138d31'21.95"E, 35d 1'22.21"S)
Band 1 Block=416x320 Type=Byte, ColorInterp=Cyan
Band 2 Block=416x320 Type=Byte, ColorInterp=Magenta
Band 3 Block=416x320 Type=Byte, ColorInterp=Yellow

Post by 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 to modify
coordinates and stuff) it's just to check the image file format.
If I'm right, you can try to convert all your files in GeoTiff format
(using otbcli_Convert with an output file extension equal to ".tif", then
run the Mosaic application over the fresh .tif files and it will work fine
Rémi

Post by Gus
Trying to reduce the RAM value seems to have no effect on memory
footprint. If I set it to 1, it grows a lot at first, then the process
seems to progress very slowly. If I set it to 10, it gows a lot at first,
then it does progress increasingly ocuppying memory. It seems to be
independent of your colour space transform, whatever method you choose,
band per band or (I guess you use cieLab?). I'm testing the no
harmonization options that you told (that I had already tried in windows).
It's writing the tiff and seems to be ok but, although it probably will
finish, it's taking a (while slower) progressively increasing amount of ram.
I tested ram parameter in otbcli_HaralickTextureExtraction and it seems
to correctly make use of chunks within parameter.
Just in case, I'm using imagery of this kind, 8bit unsigned integer where
I use 0 as no value (it worked ok for small sets).

Post by 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
- otbcli_Mosaic -il /media/gus/Gus/seagrass/3_band/* -out
/media/gus/Gus/seagrass/processed_data/r2_simple_noharmo.tif uint8 -ram 128
- otbcli_Mosaic -il /media/gus/Gus/seagrass/3_band/* -comp.feather
large -out /media/gus/Gus/seagrass/processed_data/r2_feather_noharmo.tif
uint8 -tmpdir /media/gus/Gus/seagrass/processed_data/temp -ram 128
- otbcli_Mosaic -il /media/gus/Gus/seagrass/3_band/* -harmo.method
band -harmo.cost musig -out
/media/gus/Gus/seagrass/processed_data/r2_harmo-band.tif uint8 -ram 128
- otbcli_Mosaic -il /media/gus/Gus/seagrass/3_band/* -harmo.method
rgb -harmo.cost musig -out
/media/gus/Gus/seagrass/processed_data/r2_harmo-rgb.tif uint8 -ram 128
Now, you can try to set a very small RAM value and tell me what's
happening. Set -ram 1 for instance...

Post by 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 -ram 128 -progress 1
2018-09-12 03:29:30 (INFO): Computing statistics in a decorrelated
colors space suitable for true-colors
3.15661e+06MB (avail.: 128 MB), optimal image partitioning: 24662 blocks
2018-09-12 03:29:44 (INFO): Estimation will be performed in 18639
blocks of 832x320 pixels
Anyway, after start, used RAM begins to slowly increase until it
occupied my swap space and froze the computer during the night.
[image: Screenshot at 2018-09-12 03-30-10.png]

Post by Rémi
Hello Gus,
-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

Post by Gus
Thanks, Rémi
Your method works fairly well, the results are really good and
visually pleasant. In fact, I was able to use you app (from gui) for small
subsets of my data, which is a set of aerial pictures of the sea surface
from which the sunglint has been removed.
54ed0802-e492-438f-9f4d-8dea3593a2b6.jpg]
But, when I feed your program with the complete set (about 2500
pictures, 30 Mb each approximately, 8 bit colour) it fails. Last thing I
can check is that the temporary distance maps have been correctly written,
and that's the last console output. while if Iskip the large feathering
step, it seems to work ok, as in next image using slim blending mode, but
as for large blending, it fails...
[image: sea_1PNG.PNG]

Post by 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 compositing pipeline, just
for feathering) is not a streamable process. Meaning that, for each input
image to mosaic, the distance map will theoretically require the full image
in memory to be processed. That's why there is the distancemap.sr
(sampling ratio) parameter. This enables the subsampling of the input
image, to compute the distance map with a smaller footprint. See README.md,
section "Performance tuning: Distance map images sampling ratio".
This is a current limitation of the application, I will add this
explicitly in the application description.
Your problem could also come from the fact that your input images
have not the same projection reference (and leading to a near infinite
image, e.g. if you mix degrees and meters units, or with wrong coordinate
reference system), check this.
Hope that helps,
Rémi

Post by Gus
Hello everyone.
I don't clearly understand the process followed by the remote
module "mosaic". The memory occupied during some phase after distance maps
calculation for large blending with lab color space harmonization grows a
lot, so I obtain a huge page file and my computer reboots. I checked the
paper and peeked into the code a bit, but I'm not familiar with the
libraries. Is there any way of estimating the ram needed for the process?
Is there a way of overcoming this issue? (probably I will process it in
chunks anyway but that would simplify things quite a lot).
Cheers
Gus

--
--
Check the OTB FAQ at
http://www.orfeo-toolbox.org/FAQ.html

You received this message because you are subscribed to the Google
Groups "otb-users" group.
To post to this group, send email to otb-***@googlegroups.com
To unsubscribe from this group, send email to
otb-users+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/otb-users?hl=en
---
You received this message because you are subscribed to the Google Groups "otb-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to otb-users+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[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 !

Post by Gus
Driver: GTiff/GeoTIFF
Files: p_731_a.tif
Size is 4145, 3189
PROJCS["WGS 84 / UTM zone 54S",
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563,
AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0,
AUTHORITY["EPSG","8901"]],
UNIT["degree",0.0174532925199433,
AUTHORITY["EPSG","9122"]],
AUTHORITY["EPSG","4326"]],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",0],
PARAMETER["central_meridian",141],
PARAMETER["scale_factor",0.9996],
PARAMETER["false_easting",500000],
PARAMETER["false_northing",10000000],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]],
AXIS["Easting",EAST],
AXIS["Northing",NORTH],
AUTHORITY["EPSG","32754"]]
Origin = (271914.159999999974389,6123214.030000000260770)
Pixel Size = (1.000000000000000,-1.000000000000000)
AREA_OR_POINT=Area
COMPRESSION=PACKBITS
INTERLEAVE=PIXEL
Upper Left ( 271914.160, 6123214.030) (138d30' 1.82"E, 35d 0'28.82"S)
Lower Left ( 271914.160, 6120025.030) (138d29'58.67"E, 35d 2'12.24"S)
Upper Right ( 276059.160, 6123214.030) (138d32'45.20"E, 35d 0'32.15"S)
Lower Right ( 276059.160, 6120025.030) (138d32'42.11"E, 35d 2'15.58"S)
Center ( 273986.660, 6121619.530) (138d31'21.95"E, 35d 1'22.21"S)
Band 1 Block=416x320 Type=Byte, ColorInterp=Cyan
Band 2 Block=416x320 Type=Byte, ColorInterp=Magenta
Band 3 Block=416x320 Type=Byte, ColorInterp=Yellow

Post by 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 to modify
coordinates and stuff) it's just to check the image file format.
If I'm right, you can try to convert all your files in GeoTiff format
(using otbcli_Convert with an output file extension equal to ".tif", then
run the Mosaic application over the fresh .tif files and it will work fine
Rémi

Post by Gus
Trying to reduce the RAM value seems to have no effect on memory
footprint. If I set it to 1, it grows a lot at first, then the process
seems to progress very slowly. If I set it to 10, it gows a lot at first,
then it does progress increasingly ocuppying memory. It seems to be
independent of your colour space transform, whatever method you choose,
band per band or (I guess you use cieLab?). I'm testing the no
harmonization options that you told (that I had already tried in windows).
It's writing the tiff and seems to be ok but, although it probably will
finish, it's taking a (while slower) progressively increasing amount of ram.
I tested ram parameter in otbcli_HaralickTextureExtraction and it seems
to correctly make use of chunks within parameter.
Just in case, I'm using imagery of this kind, 8bit unsigned integer
where I use 0 as no value (it worked ok for small sets).

Post by 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
- otbcli_Mosaic -il /media/gus/Gus/seagrass/3_band/* -out
/media/gus/Gus/seagrass/processed_data/r2_simple_noharmo.tif uint8 -ram 128
- otbcli_Mosaic -il /media/gus/Gus/seagrass/3_band/* -comp.feather
large -out /media/gus/Gus/seagrass/processed_data/r2_feather_noharmo.tif
uint8 -tmpdir /media/gus/Gus/seagrass/processed_data/temp -ram 128
- otbcli_Mosaic -il /media/gus/Gus/seagrass/3_band/* -harmo.method
band -harmo.cost musig -out
/media/gus/Gus/seagrass/processed_data/r2_harmo-band.tif uint8 -ram 128
- otbcli_Mosaic -il /media/gus/Gus/seagrass/3_band/* -harmo.method
rgb -harmo.cost musig -out
/media/gus/Gus/seagrass/processed_data/r2_harmo-rgb.tif uint8 -ram 128
Now, you can try to set a very small RAM value and tell me what's
happening. Set -ram 1 for instance...

Post by 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 -ram 128 -progress 1
2018-09-12 03:29:30 (INFO): Computing statistics in a decorrelated
colors space suitable for true-colors
3.15661e+06MB (avail.: 128 MB), optimal image partitioning: 24662 blocks
2018-09-12 03:29:44 (INFO): Estimation will be performed in 18639
blocks of 832x320 pixels
Anyway, after start, used RAM begins to slowly increase until it
occupied my swap space and froze the computer during the night.
[image: Screenshot at 2018-09-12 03-30-10.png]

Post by Rémi
Hello Gus,
-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

Post by Gus
Thanks, Rémi
Your method works fairly well, the results are really good and
visually pleasant. In fact, I was able to use you app (from gui) for small
subsets of my data, which is a set of aerial pictures of the sea surface
from which the sunglint has been removed.
54ed0802-e492-438f-9f4d-8dea3593a2b6.jpg]
But, when I feed your program with the complete set (about 2500
pictures, 30 Mb each approximately, 8 bit colour) it fails. Last thing I
can check is that the temporary distance maps have been correctly written,
and that's the last console output. while if Iskip the large feathering
step, it seems to work ok, as in next image using slim blending mode, but
as for large blending, it fails...
[image: sea_1PNG.PNG]

Post by 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 compositing pipeline, just
for feathering) is not a streamable process. Meaning that, for each input
image to mosaic, the distance map will theoretically require the full image
in memory to be processed. That's why there is the distancemap.sr
(sampling ratio) parameter. This enables the subsampling of the input
image, to compute the distance map with a smaller footprint. See README.md,
section "Performance tuning: Distance map images sampling ratio".
This is a current limitation of the application, I will add this
explicitly in the application description.
Your problem could also come from the fact that your input images
have not the same projection reference (and leading to a near infinite
image, e.g. if you mix degrees and meters units, or with wrong coordinate
reference system), check this.
Hope that helps,
Rémi

Post by Gus
Hello everyone.
I don't clearly understand the process followed by the remote
module "mosaic". The memory occupied during some phase after distance maps
calculation for large blending with lab color space harmonization grows a
lot, so I obtain a huge page file and my computer reboots. I checked the
paper and peeked into the code a bit, but I'm not familiar with the
libraries. Is there any way of estimating the ram needed for the process?
Is there a way of overcoming this issue? (probably I will process it in
chunks anyway but that would simplify things quite a lot).
Cheers
Gus

--
--
Check the OTB FAQ at
http://www.orfeo-toolbox.org/FAQ.html

You received this message because you are subscribed to the Google
Groups "otb-users" group.
To post to this group, send email to otb-***@googlegroups.com
To unsubscribe from this group, send email to
otb-users+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/otb-users?hl=en
---
You received this message because you are subscribed to the Google Groups "otb-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to otb-users+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[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?

Post by 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 !

Post by Gus
Driver: GTiff/GeoTIFF
Files: p_731_a.tif
Size is 4145, 3189
PROJCS["WGS 84 / UTM zone 54S",
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563,
AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0,
AUTHORITY["EPSG","8901"]],
UNIT["degree",0.0174532925199433,
AUTHORITY["EPSG","9122"]],
AUTHORITY["EPSG","4326"]],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",0],
PARAMETER["central_meridian",141],
PARAMETER["scale_factor",0.9996],
PARAMETER["false_easting",500000],
PARAMETER["false_northing",10000000],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]],
AXIS["Easting",EAST],
AXIS["Northing",NORTH],
AUTHORITY["EPSG","32754"]]
Origin = (271914.159999999974389,6123214.030000000260770)
Pixel Size = (1.000000000000000,-1.000000000000000)
AREA_OR_POINT=Area
COMPRESSION=PACKBITS
INTERLEAVE=PIXEL
Upper Left ( 271914.160, 6123214.030) (138d30' 1.82"E, 35d 0'28.82"S)
Lower Left ( 271914.160, 6120025.030) (138d29'58.67"E, 35d 2'12.24"S)
Upper Right ( 276059.160, 6123214.030) (138d32'45.20"E, 35d 0'32.15"S)
Lower Right ( 276059.160, 6120025.030) (138d32'42.11"E, 35d 2'15.58"S)
Center ( 273986.660, 6121619.530) (138d31'21.95"E, 35d 1'22.21"S)
Band 1 Block=416x320 Type=Byte, ColorInterp=Cyan
Band 2 Block=416x320 Type=Byte, ColorInterp=Magenta
Band 3 Block=416x320 Type=Byte, ColorInterp=Yellow

Post by 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 to modify
coordinates and stuff) it's just to check the image file format.
If I'm right, you can try to convert all your files in GeoTiff format
(using otbcli_Convert with an output file extension equal to ".tif", then
run the Mosaic application over the fresh .tif files and it will work fine
Rémi

Post by Gus
Trying to reduce the RAM value seems to have no effect on memory
footprint. If I set it to 1, it grows a lot at first, then the process
seems to progress very slowly. If I set it to 10, it gows a lot at first,
then it does progress increasingly ocuppying memory. It seems to be
independent of your colour space transform, whatever method you choose,
band per band or (I guess you use cieLab?). I'm testing the no
harmonization options that you told (that I had already tried in windows).
It's writing the tiff and seems to be ok but, although it probably will
finish, it's taking a (while slower) progressively increasing amount of ram.
I tested ram parameter in otbcli_HaralickTextureExtraction and it seems
to correctly make use of chunks within parameter.
Just in case, I'm using imagery of this kind, 8bit unsigned integer
where I use 0 as no value (it worked ok for small sets).

Post by 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
- otbcli_Mosaic -il /media/gus/Gus/seagrass/3_band/* -out
/media/gus/Gus/seagrass/processed_data/r2_simple_noharmo.tif uint8 -ram 128
- otbcli_Mosaic -il /media/gus/Gus/seagrass/3_band/* -comp.feather
large -out /media/gus/Gus/seagrass/processed_data/r2_feather_noharmo.tif
uint8 -tmpdir /media/gus/Gus/seagrass/processed_data/temp -ram 128
- otbcli_Mosaic -il /media/gus/Gus/seagrass/3_band/* -harmo.method
band -harmo.cost musig -out
/media/gus/Gus/seagrass/processed_data/r2_harmo-band.tif uint8 -ram 128
- otbcli_Mosaic -il /media/gus/Gus/seagrass/3_band/* -harmo.method
rgb -harmo.cost musig -out
/media/gus/Gus/seagrass/processed_data/r2_harmo-rgb.tif uint8 -ram 128
Now, you can try to set a very small RAM value and tell me what's
happening. Set -ram 1 for instance...

Post by 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 -ram 128 -progress 1
2018-09-12 03:29:30 (INFO): Computing statistics in a decorrelated
colors space suitable for true-colors
3.15661e+06MB (avail.: 128 MB), optimal image partitioning: 24662 blocks
2018-09-12 03:29:44 (INFO): Estimation will be performed in 18639
blocks of 832x320 pixels
Anyway, after start, used RAM begins to slowly increase until it
occupied my swap space and froze the computer during the night.
[image: Screenshot at 2018-09-12 03-30-10.png]

Post by Rémi
Hello Gus,
-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

Post by Gus
Thanks, Rémi
Your method works fairly well, the results are really good and
visually pleasant. In fact, I was able to use you app (from gui) for small
subsets of my data, which is a set of aerial pictures of the sea surface
from which the sunglint has been removed.
54ed0802-e492-438f-9f4d-8dea3593a2b6.jpg]
But, when I feed your program with the complete set (about 2500
pictures, 30 Mb each approximately, 8 bit colour) it fails. Last thing I
can check is that the temporary distance maps have been correctly written,
and that's the last console output. while if Iskip the large feathering
step, it seems to work ok, as in next image using slim blending mode, but
as for large blending, it fails...
[image: sea_1PNG.PNG]

Post by 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 compositing pipeline, just
for feathering) is not a streamable process. Meaning that, for each input
image to mosaic, the distance map will theoretically require the full image
in memory to be processed. That's why there is the distancemap.sr
(sampling ratio) parameter. This enables the subsampling of the input
image, to compute the distance map with a smaller footprint. See README.md,
section "Performance tuning: Distance map images sampling ratio".
This is a current limitation of the application, I will add this
explicitly in the application description.
Your problem could also come from the fact that your input images
have not the same projection reference (and leading to a near infinite
image, e.g. if you mix degrees and meters units, or with wrong coordinate
reference system), check this.
Hope that helps,
Rémi

Post by Gus
Hello everyone.
I don't clearly understand the process followed by the remote
module "mosaic". The memory occupied during some phase after distance maps
calculation for large blending with lab color space harmonization grows a
lot, so I obtain a huge page file and my computer reboots. I checked the
paper and peeked into the code a bit, but I'm not familiar with the
libraries. Is there any way of estimating the ram needed for the process?
Is there a way of overcoming this issue? (probably I will process it in
chunks anyway but that would simplify things quite a lot).
Cheers
Gus

--
--
Check the OTB FAQ at
http://www.orfeo-toolbox.org/FAQ.html

You received this message because you are subscribed to the Google
Groups "otb-users" group.
To post to this group, send email to otb-***@googlegroups.com
To unsubscribe from this group, send email to
otb-users+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/otb-users?hl=en
---
You received this message because you are subscribed to the Google Groups "otb-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to otb-users+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[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?
--
--
Check the OTB FAQ at
http://www.orfeo-toolbox.org/FAQ.html

You received this message because you are subscribed to the Google
Groups "otb-users" group.
To post to this group, send email to otb-***@googlegroups.com
To unsubscribe from this group, send email to
otb-users+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/otb-users?hl=en
---
You received this message because you are subscribed to the Google Groups "otb-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to otb-users+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[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?

do you mean that, for every single input image, I need to load an array

Post by Gus
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?

--
--
Check the OTB FAQ at
http://www.orfeo-toolbox.org/FAQ.html

You received this message because you are subscribed to the Google
Groups "otb-users" group.
To post to this group, send email to otb-***@googlegroups.com
To unsubscribe from this group, send email to
otb-users+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/otb-users?hl=en
---
You received this message because you are subscribed to the Google Groups "otb-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to otb-users+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[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 -ram 128

/media/gus/Gus/seagrass/noharmo.log 2>&1

otbcli_Mosaic -il /media/gus/Gus/seagrass/3_band/* -out
/media/gus/Gus/seagrass/processed_data/r2_simple_noharmo.tif uint8
-harmo.method band >/media/gus/Gus/seagrass/harmo.log 2>&1

(Then, you send me the logs)

Also, please copy/paste the gdalinfo command on your converted geotiff
(without PACKBITS compression)

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?

do you mean that, for every single input image, I need to load an array

Post by Gus
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?

--
--
Check the OTB FAQ at
http://www.orfeo-toolbox.org/FAQ.html

You received this message because you are subscribed to the Google
Groups "otb-users" group.
To post to this group, send email to otb-***@googlegroups.com
To unsubscribe from this group, send email to
otb-users+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/otb-users?hl=en
---
You received this message because you are subscribed to the Google Groups "otb-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to otb-users+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[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
stack and conda junk) but it will take a couple days. Thank you for your
patience.

Post by 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
otbcli_Mosaic -il /media/gus/Gus/seagrass/3_band/* -out
/media/gus/Gus/seagrass/processed_data/r2_simple_noharmo.tif uint8 -ram 128

/media/gus/Gus/seagrass/noharmo.log 2>&1

otbcli_Mosaic -il /media/gus/Gus/seagrass/3_band/* -out
/media/gus/Gus/seagrass/processed_data/r2_simple_noharmo.tif uint8
-harmo.method band >/media/gus/Gus/seagrass/harmo.log 2>&1
(Then, you send me the logs)
Also, please copy/paste the gdalinfo command on your converted geotiff
(without PACKBITS compression)

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?

do you mean that, for every single input image, I need to load an array

Post by Gus
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?

--
--
Check the OTB FAQ at
http://www.orfeo-toolbox.org/FAQ.html

You received this message because you are subscribed to the Google
Groups "otb-users" group.
To post to this group, send email to otb-***@googlegroups.com
To unsubscribe from this group, send email to
otb-users+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/otb-users?hl=en
---
You received this message because you are subscribed to the Google Groups "otb-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to otb-users+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Gus]

Ok. Here there are the logs and the output of gdalinfo on some random file
(all them were processed with gdal_translate).
The harmonization pipeline failed. During statistics evaluation it showed a
progressively increasing memory footprint. I add a capture when it failed.

[image: Screenshot at 2018-09-28 23-57-06.png]
Thanks
--
--
Check the OTB FAQ at
http://www.orfeo-toolbox.org/FAQ.html

You received this message because you are subscribed to the Google
Groups "otb-users" group.
To post to this group, send email to otb-***@googlegroups.com
To unsubscribe from this group, send email to
otb-users+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/otb-users?hl=en
---
You received this message because you are subscribed to the Google Groups "otb-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to otb-users+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[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 images in your case).
Each matrix holds something useful (e.g. pixel count, pixel sum, ...) for
each band.
In the end, all these matrices occupies a lot of memory! that's why the
Mosaic application consumes so much RAM when you enable stats computations.

You have different ways for solving this problem (alternatively to run on a
computer with more RAM!):
1. Give a try with a single thread. This will reduce the number of internal
accumulators for statistics (matrices) because each thread has its own. To
do that, set the ITK_GLOBAL_DEFAULT_NUMBER_OF_THREADS to 1 (type "export ITK_GLOBAL_DEFAULT_NUMBER_OF_THREADS=1"
in terminal before running the command). But... this will last 4 times
longer that your precedent try, something like 25 hours instead of 6 just
for the stats computation. But you should save about 6Gb (approx for 3k
images). However, let's hope that the later quadratic optimization step,
which also requires to allocate space for matrix, will not fail.

[image: path4668-3.png]
2. Split your dataset in two (or more, if two isn't enough) the right way.
You can theoretically obtain the exact same result as if you process the
whole dataset. For this, you need to split the dataset the right way to
make the quadratic optimization equivalent. This can be done in finding a
number of overlaping images that are connected only with one single image
(i.e. this image would have 2 overlap with the adjacent images, and those 2
adjacent images does not intersect). Then you process independently these
two split independently (using the same harmo/comp options) and later you
can process the mosicing of those two resulting mosaics (using the same
harmo/options as you did for each one). The harmonization should be
equivalent. See attached figure

Hope that helps !

Post by Gus
Ok. Here there are the logs and the output of gdalinfo on some random file
(all them were processed with gdal_translate).
The harmonization pipeline failed. During statistics evaluation it showed
a progressively increasing memory footprint. I add a capture when it failed.
[image: Screenshot at 2018-09-28 23-57-06.png]
Thanks

--
--
Check the OTB FAQ at
http://www.orfeo-toolbox.org/FAQ.html

You received this message because you are subscribed to the Google
Groups "otb-users" group.
To post to this group, send email to otb-***@googlegroups.com
To unsubscribe from this group, send email to
otb-users+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/otb-users?hl=en
---
You received this message because you are subscribed to the Google Groups "otb-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to otb-users+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[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.

Post by 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 images in your case).
Each matrix holds something useful (e.g. pixel count, pixel sum, ...) for
each band.
In the end, all these matrices occupies a lot of memory! that's why the
Mosaic application consumes so much RAM when you enable stats computations.
You have different ways for solving this problem (alternatively to run on
1. Give a try with a single thread. This will reduce the number of
internal accumulators for statistics (matrices) because each thread has its
own. To do that, set the ITK_GLOBAL_DEFAULT_NUMBER_OF_THREADS to 1 (type
"export ITK_GLOBAL_DEFAULT_NUMBER_OF_THREADS=1" in terminal before
running the command). But... this will last 4 times longer that your
precedent try, something like 25 hours instead of 6 just for the stats
computation. But you should save about 6Gb (approx for 3k images). However,
let's hope that the later quadratic optimization step, which also
requires to allocate space for matrix, will not fail.
[image: path4668-3.png]
2. Split your dataset in two (or more, if two isn't enough) the right way.
You can theoretically obtain the exact same result as if you process the
whole dataset. For this, you need to split the dataset the right way to
make the quadratic optimization equivalent. This can be done in finding a
number of overlaping images that are connected only with one single image
(i.e. this image would have 2 overlap with the adjacent images, and those 2
adjacent images does not intersect). Then you process independently these
two split independently (using the same harmo/comp options) and later you
can process the mosicing of those two resulting mosaics (using the same
harmo/options as you did for each one). The harmonization should be
equivalent. See attached figure
Hope that helps !

Post by Gus
Ok. Here there are the logs and the output of gdalinfo on some random
file (all them were processed with gdal_translate).
The harmonization pipeline failed. During statistics evaluation it showed
a progressively increasing memory footprint. I add a capture when it failed.
[image: Screenshot at 2018-09-28 23-57-06.png]
Thanks

--
--
Check the OTB FAQ at
http://www.orfeo-toolbox.org/FAQ.html

You received this message because you are subscribed to the Google
Groups "otb-users" group.
To post to this group, send email to otb-***@googlegroups.com
To unsubscribe from this group, send email to
otb-users+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/otb-users?hl=en
---
You received this message because you are subscribed to the Google Groups "otb-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to otb-users+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Gus]

At the end I didn't used the tone harmonization. There was some dominant
direction in lightness gradient in each image that led to very odd
solutions. Instead of that I (kind of) tried to correct it (making some
assumptions) before applying the feathering in your software and it worked
fine (the results are enough).

[image: 8.png]
This is for some colleagues of mine. I suggested to cite your paper and
also otb. Thank you very much.

Post by 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.

Post by 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 images in your case).
Each matrix holds something useful (e.g. pixel count, pixel sum, ...) for
each band.
In the end, all these matrices occupies a lot of memory! that's why the
Mosaic application consumes so much RAM when you enable stats computations.
You have different ways for solving this problem (alternatively to run on
1. Give a try with a single thread. This will reduce the number of
internal accumulators for statistics (matrices) because each thread has its
own. To do that, set the ITK_GLOBAL_DEFAULT_NUMBER_OF_THREADS to 1 (type
"export ITK_GLOBAL_DEFAULT_NUMBER_OF_THREADS=1" in terminal before
running the command). But... this will last 4 times longer that your
precedent try, something like 25 hours instead of 6 just for the stats
computation. But you should save about 6Gb (approx for 3k images). However,
let's hope that the later quadratic optimization step, which also
requires to allocate space for matrix, will not fail.
[image: path4668-3.png]
2. Split your dataset in two (or more, if two isn't enough) the right
way. You can theoretically obtain the exact same result as if you process
the whole dataset. For this, you need to split the dataset the right way to
make the quadratic optimization equivalent. This can be done in finding a
number of overlaping images that are connected only with one single image
(i.e. this image would have 2 overlap with the adjacent images, and those 2
adjacent images does not intersect). Then you process independently these
two split independently (using the same harmo/comp options) and later you
can process the mosicing of those two resulting mosaics (using the same
harmo/options as you did for each one). The harmonization should be
equivalent. See attached figure
Hope that helps !

Post by Gus
Ok. Here there are the logs and the output of gdalinfo on some random
file (all them were processed with gdal_translate).
The harmonization pipeline failed. During statistics evaluation it
showed a progressively increasing memory footprint. I add a capture when it
failed.
[image: Screenshot at 2018-09-28 23-57-06.png]
Thanks

--
--
Check the OTB FAQ at
http://www.orfeo-toolbox.org/FAQ.html

You received this message because you are subscribed to the Google
Groups "otb-users" group.
To post to this group, send email to otb-***@googlegroups.com
To unsubscribe from this group, send email to
otb-users+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/otb-users?hl=en
---
You received this message because you are subscribed to the Google Groups "otb-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to otb-users+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Gus]

At the end I didn't used the tone harmonization. There was some dominant
direction in lightness gradient in each image that led to very odd
solutions. Instead of that I (kind of) tried to correct it (making some
assumptions) before applying the feathering in your software and it worked
fine (the results are enough).

[image: test1.png]
This is for some colleagues of mine. I suggested to add citations to
otb-mosaic and otb itself. Thank you very much.

Post by 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 images in your case).
Each matrix holds something useful (e.g. pixel count, pixel sum, ...) for
each band.
In the end, all these matrices occupies a lot of memory! that's why the
Mosaic application consumes so much RAM when you enable stats computations.
You have different ways for solving this problem (alternatively to run on
1. Give a try with a single thread. This will reduce the number of
internal accumulators for statistics (matrices) because each thread has its
own. To do that, set the ITK_GLOBAL_DEFAULT_NUMBER_OF_THREADS to 1 (type
"export ITK_GLOBAL_DEFAULT_NUMBER_OF_THREADS=1" in terminal before
running the command). But... this will last 4 times longer that your
precedent try, something like 25 hours instead of 6 just for the stats
computation. But you should save about 6Gb (approx for 3k images). However,
let's hope that the later quadratic optimization step, which also
requires to allocate space for matrix, will not fail.
[image: path4668-3.png]
2. Split your dataset in two (or more, if two isn't enough) the right way.
You can theoretically obtain the exact same result as if you process the
whole dataset. For this, you need to split the dataset the right way to
make the quadratic optimization equivalent. This can be done in finding a
number of overlaping images that are connected only with one single image
(i.e. this image would have 2 overlap with the adjacent images, and those 2
adjacent images does not intersect). Then you process independently these
two split independently (using the same harmo/comp options) and later you
can process the mosicing of those two resulting mosaics (using the same
harmo/options as you did for each one). The harmonization should be
equivalent. See attached figure
Hope that helps !

Post by Gus
Ok. Here there are the logs and the output of gdalinfo on some random
file (all them were processed with gdal_translate).
The harmonization pipeline failed. During statistics evaluation it showed
a progressively increasing memory footprint. I add a capture when it failed.
[image: Screenshot at 2018-09-28 23-57-06.png]
Thanks

--
--
Check the OTB FAQ at
http://www.orfeo-toolbox.org/FAQ.html

You received this message because you are subscribed to the Google
Groups "otb-users" group.
To post to this group, send email to otb-***@googlegroups.com
To unsubscribe from this group, send email to
otb-users+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/otb-users?hl=en
---
You received this message because you are subscribed to the Google Groups "otb-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to otb-users+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.