Re: [otb-users] Re: Extended filename for band selection

[Guillaume Pasero]

Okay, so maybe we shouldn't advertise it as "Python-like" syntax. The idea is really to offer something easy to use and understand for the non-developers. Guillaume On 02/28/2017 07:17 AM, Julien Radoux wrote: I agree that starting at 1 is more consistent than starting at 0, because OTB is based on GDAL and GDAL starts at 1 and some applications already start at 1 (BandMath) . What I meant is that IF you announce a Python-like syntax, THEN it must be consitent with Python Le lundi 27 février 2017 11:33:38 UTC+1, Poughon Victor a écrit : My two cents on this: Start at 0 or 1: While there are strong arguments to start indexing at zero (https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html), I vote for starting at 1 because: - OTB is used by non programmers - QGIS and GDAL are 1 based - Most sensors are 1 based (http://gis.stackexchange.com/questions/219886/is-it-convention-to-index-a-raster-band-from-1?atw=1) End-point inclusion I think I prefer the end point to be excluded because then: - A:B has B-A elements in it - It's possible to express the empty range (A:A) (perhaps that's not a good thing?) just my 2 cents Victor Poughon De : otb-...@googlegroups.com [otb-...@googlegroups.com] de la part de Guillaume Pasero [guillaum...@c-s.fr] Envoyé : lundi 27 février 2017 10:51 À : otb-...@googlegroups.com Objet : Re: [otb-users] Re: Extended filename for band selection Dear Julien, Thanks for your feedback. It is true that current syntax is somewhere in-between different standards. About the use of "band[]" as general syntax, it would not be consistent with other extended filenames : we always use "keyword=value". So, it should be something like "band=[]". Regards, Guillaume On 02/25/2017 10:41 AM, Julien Radoux wrote: Dear Guillaume, This would be usefull, thanks. I don't care about band or bands. for the syntax, Python-like is nice, but then it is confusing not to start with band 0 for the first band. maybe using [] would also make things clear. To be more "pythonic", I would rather use bands[] with the python indices but this is probably more difficult to parse. Also, in python, [2:4] would mean bands with index 2 and 3 (not the 4), so this is not consistent. To conclude, Python-like is fine, but it would be very confusing if there are too many differences. In your example, it makes me think of Matlab indexing, which is fine but should be stated as such in the help (then use "end" instead of -1 for the last band) For the last question, I do have some home made scripts that could benefit from band selection in the extended filename. One application with a standard filter would be the use of Meanshift segmentation where you only want the smoothed mean value for one of the output bands (e.g. a NDVI band) but you want to use more than one band as input for the mean shift segmentation. Le vendredi 24 février 2017 17:25:37 UTC+1, Guillaume Pasero a écrit : Dear users, A new feature is in development to provide an extended filename for input band selection (see extended_band). A simple use-case is when you have a multi-channel image, and you want to process only the second band of this image using an OTB Application. With this feature you could do it like this : otbcli_MyApplication -in  "my_image.tif?band=2"  -out output.tif The current syntax (inspired by Python syntax) has already been implemented : band=r1,r2,...,rn     where each 'ri' is a generic range A generic range can be : A single band index : '1' is the first band, for negative numbers the numbering is backward ( '-1' is the last band) A range of bands, using the character ':' between optional start and end indexes : '3:' means the 3rd band until the last one ':-2' means the first band until the second to last '2:4' means bands 2, 3 and 4 We would like to have your feedback on several points : We will likely change the keyword "band" to plural "bands", no objection ? Is the syntax clear / convenient / confusing ? There can be a debate between 0-based and 1-based indexing for band numbers. At the moment, it is not uniform in OTB but we think that 1-based indexing should be the convention exposed to the user. It is also possible to implement it on image writers, would it help ? What would be your use-cases ? Thanks for your feedback, Guillaume -- Guillaume PASERO Responsable technique Business Unit ESPACE & GeoInformation - Département Payload Data & Applications CS Systèmes d'Information Parc de la Grande Plaine - 5, Rue Brindejonc des Moulinais - BP 15872 31506 Toulouse Cedex 05 - FRANCE +33 561 17 64 21 - guillaum...@c-s.fr -- -- 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. -- Guillaume PASERO Responsable technique Business Unit ESPACE & GeoInformation - Département Payload Data & Applications CS Systèmes d'Information Parc de la Grande Plaine - 5, Rue Brindejonc des Moulinais - BP 15872 31506 Toulouse Cedex 05 - FRANCE +33 561 17 64 21 - guillau...@c-s.fr -- -- 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. -- -- 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-users@googlegroups.com To unsubscribe from this group, send email to otb-users+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Guillaume PASERO Responsable technique Business Unit ESPACE & GeoInformation - Département Payload Data & Applications CS Systèmes d'Information Parc de la Grande Plaine - 5, Rue Brindejonc des Moulinais - BP 15872 31506 Toulouse Cedex 05 - FRANCE +33 561 17 64 21 - guillaume.pas...@c-s.fr -- -- 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-users@googlegroups.com To unsubscribe from this group, send email to otb-users+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.