[Qgis-developer] Raster visualization
Hi all. We recently noticed strange problems with the visualization of rasters. Transparencies are applied automatically, some layers are not displayed even if no custom color is selected, etc. We'll inspect this deeper tomorrow, but in the meantime: did anybody see the same? All the best. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster visualization
yes, i see strange behaviour of one raster. it is always above every layer even if it is the last onein the toc. (Versione di QGIS, 1.8.0-Lisboa, Revisione codice QGIS cdd683c) http://osgeo-org.1560.n6.nabble.com/file/n4978855/1.png 1.png http://osgeo-org.1560.n6.nabble.com/file/n4978855/2.png 2.png -- View this message in context: http://osgeo-org.1560.n6.nabble.com/Raster-visualization-tp4978783p4978855.html Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster visualization
Hi Stefano, On Mon, Jun 4, 2012 at 12:33 AM, skampus stefano.cam...@regione.piemonte.it wrote: it is always above every layer even if it is the last onein the toc. AFAICS the Control rendering order checkbox is not checked. Display the Layer order panel (View-Panel-Layer order) or tick the checkbox to control the rendering order of layers by their position in the TOC. Regards. (Versione di QGIS, 1.8.0-Lisboa, Revisione codice QGIS cdd683c) http://osgeo-org.1560.n6.nabble.com/file/n4978855/1.png 1.png http://osgeo-org.1560.n6.nabble.com/file/n4978855/2.png 2.png -- View this message in context: http://osgeo-org.1560.n6.nabble.com/Raster-visualization-tp4978783p4978855.html Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Giuseppe Sucameli - Faunalia ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster visualization
opsss...sorry... -- View this message in context: http://osgeo-org.1560.n6.nabble.com/Raster-visualization-tp4978783p4978857.html Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] raster visualization
Hi, Depending on the number of cells, dealing with 20 raster files requires a totally different approach. I agree. There are surely more than one approach type to the raster usage problem. Surely there is the user that need a thematic map and need a really good analysys . It need all the statistics to do and so it agree if the qgis to it by default. But there is also the user that need a base map for their work. This second kind of user is principally a vectorial user. An user that work principally on a vectorial dataset . It need a raster only as base map where apply their vectorial data. This user tipically is not a power-user for qgis, but instead it is a power-user for it dataset. It know all of its vectorial dataset , but instead is a poor user of rasters. The big difference is that the power-user for thematic raster is able to understand what it need for raster and so is able to open the porperties of qgis and set qgis to calculate the statistics. It open properties and set all he need to have. The power-user for a vectorial dataset is not always able to understand what mean usage a raster. So it is not so able to open qgis and remove the settings that slow the qgis. This is the main difference I guess should be pointed when plan the usability of the interface. Think that a user that don't know so well the raster theory cannot understand why qgis is so slowly to open a raster rather than other programs so it cannot resolve this slowness. Instead an user that know the raster theory is able to open qgis and set it to calculate all it need to know. Andrea. 2012/4/23 Agustin Lobo alobolis...@gmail.com Andrea, Depending on the number of cells, dealing with 20 raster files requires a totally different approach. Even for visualization, this is clearly a different problem than the common RGB or multi-spectral imagery. We cannot deal with 13000 raster layers in the same way as we do with a dozen. Have you tried rasterlite? Agus El día 22 de abril de 2012 21:37, aperi2007 aperi2...@gmail.com escribió: Hi Agus , thx for your informations. Opening the raster layers very fast but getting a bad visualization would not be a major waste of time? This is what currently happens to me: the initial display is always useless. I understand your point of view, but i guess is not a need for every users. Same users can't wait the 4+ minutes need for the elaboration of a raster. Again because an user could open usually more than 20 rasters for every session, I guess this elaboration should be absolutely optional to avoid a really big lost of time. If your raster layers have similar statistics and or you want to display them with the same stretching so that grey levels or colors are comparable (which is often my case also, with time series of ndvi for example), a common style file would be the best solution. Your solution seem good to me. We have more set of rasters of ortophoto type colors and grey. Eachset of colors photo is surely with comparable levels, instead I don't know for the gray photo sets. They are too older (1954 and so on). Instead for raster cell (grid data) from Lidar: Just now we begin to merge all our sets to have a full land-cover. So we are merging 1x1, 2x2 and 3x3 meters cells. I don't know if this could have some trouble with having a comparable set of values, but guess of no. Surely is not possible to find a unique style good for all the sets, but is possible to establish a good style for each set. ...Perhaps, in case a raster style is present, the by default procedure and calculations could be bypassed. Would this be a good solution in your case? You mean a file raster-style in the same folder of the raster set or of the catalog file ? I guess this could be a good compromise to help the use in situation like ours. Andrea. Il 22/04/2012 19:43, Agustin Lobo ha scritto: Andrea, Opening the raster layers very fast but getting a bad visualization would not be a major waste of time? This is what currently happens to me: the initial display is always useless. If your raster layers have similar statistics and or you want to display them with the same stretching so that grey levels or colors are comparable (which is often my case also, with time series of ndvi for example), a common style file would be the best solution. Perhaps, in case a raster style is present, the by default procedure and calculations could be bypassed. Would this be a good solution in your case? Agus El día 20 de abril de 2012 15:10, Andrea Periaperi2...@gmail.com escribió: - on initial load of a raster, generate a quicklook that is the larger of 1/4 screen resolution or 500x500 pixels by sampling every nth pixel - generate a histogram from the quicklook - calculate clipped 2% - 96% range min max for each band - apply a histogram stretch based on the
Re: [Qgis-developer] raster visualization
Andrea, Depending on the number of cells, dealing with 20 raster files requires a totally different approach. Even for visualization, this is clearly a different problem than the common RGB or multi-spectral imagery. We cannot deal with 13000 raster layers in the same way as we do with a dozen. Have you tried rasterlite? Agus El día 22 de abril de 2012 21:37, aperi2007 aperi2...@gmail.com escribió: Hi Agus , thx for your informations. Opening the raster layers very fast but getting a bad visualization would not be a major waste of time? This is what currently happens to me: the initial display is always useless. I understand your point of view, but i guess is not a need for every users. Same users can't wait the 4+ minutes need for the elaboration of a raster. Again because an user could open usually more than 20 rasters for every session, I guess this elaboration should be absolutely optional to avoid a really big lost of time. If your raster layers have similar statistics and or you want to display them with the same stretching so that grey levels or colors are comparable (which is often my case also, with time series of ndvi for example), a common style file would be the best solution. Your solution seem good to me. We have more set of rasters of ortophoto type colors and grey. Eachset of colors photo is surely with comparable levels, instead I don't know for the gray photo sets. They are too older (1954 and so on). Instead for raster cell (grid data) from Lidar: Just now we begin to merge all our sets to have a full land-cover. So we are merging 1x1, 2x2 and 3x3 meters cells. I don't know if this could have some trouble with having a comparable set of values, but guess of no. Surely is not possible to find a unique style good for all the sets, but is possible to establish a good style for each set. ...Perhaps, in case a raster style is present, the by default procedure and calculations could be bypassed. Would this be a good solution in your case? You mean a file raster-style in the same folder of the raster set or of the catalog file ? I guess this could be a good compromise to help the use in situation like ours. Andrea. Il 22/04/2012 19:43, Agustin Lobo ha scritto: Andrea, Opening the raster layers very fast but getting a bad visualization would not be a major waste of time? This is what currently happens to me: the initial display is always useless. If your raster layers have similar statistics and or you want to display them with the same stretching so that grey levels or colors are comparable (which is often my case also, with time series of ndvi for example), a common style file would be the best solution. Perhaps, in case a raster style is present, the by default procedure and calculations could be bypassed. Would this be a good solution in your case? Agus El día 20 de abril de 2012 15:10, Andrea Periaperi2...@gmail.com escribió: - on initial load of a raster, generate a quicklook that is the larger of 1/4 screen resolution or 500x500 pixels by sampling every nth pixel - generate a histogram from the quicklook - calculate clipped 2% - 96% range min max for each band - apply a histogram stretch based on the above - the histogram could be used for generating the graph in raster props, and the quicklook could be used to create thumbs and previews etc - ideally we should cache these quicklooks and only regenerate them if the underlying dataset has changed I believe if we do this we will have fast initial load and the images (grayscale and rgb) will 'look right' when first loaded (i.e with good contrast) and it would not be necessary to assign any color value to grayscales by default. Regards Hi, just my 2 ct. I guess the more important capability with raster is to open they faster possible. I fear calculate all these values on first opened take more time than what is waitable for the open of a raster. Perhaps this action should be choosable by settings ? Of course I see our situation. Our situation is of more sets of raster (7-800 each set) where every raster is grey level or true color of 3-400 Mbyte each. And all these raster are accessible by a remote shared server to our users. For a total, actually, of about 13.000 rasters. I don't understand if this new feature could be really usable in a situation like our. -- - Andrea Peri . . . . . . . . . qwerty àèìòù - ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] raster visualization
Andrea, Opening the raster layers very fast but getting a bad visualization would not be a major waste of time? This is what currently happens to me: the initial display is always useless. If your raster layers have similar statistics and or you want to display them with the same stretching so that grey levels or colors are comparable (which is often my case also, with time series of ndvi for example), a common style file would be the best solution. Perhaps, in case a raster style is present, the by default procedure and calculations could be bypassed. Would this be a good solution in your case? Agus El día 20 de abril de 2012 15:10, Andrea Peri aperi2...@gmail.com escribió: - on initial load of a raster, generate a quicklook that is the larger of 1/4 screen resolution or 500x500 pixels by sampling every nth pixel - generate a histogram from the quicklook - calculate clipped 2% - 96% range min max for each band - apply a histogram stretch based on the above - the histogram could be used for generating the graph in raster props, and the quicklook could be used to create thumbs and previews etc - ideally we should cache these quicklooks and only regenerate them if the underlying dataset has changed I believe if we do this we will have fast initial load and the images (grayscale and rgb) will 'look right' when first loaded (i.e with good contrast) and it would not be necessary to assign any color value to grayscales by default. Regards Hi, just my 2 ct. I guess the more important capability with raster is to open they faster possible. I fear calculate all these values on first opened take more time than what is waitable for the open of a raster. Perhaps this action should be choosable by settings ? Of course I see our situation. Our situation is of more sets of raster (7-800 each set) where every raster is grey level or true color of 3-400 Mbyte each. And all these raster are accessible by a remote shared server to our users. For a total, actually, of about 13.000 rasters. I don't understand if this new feature could be really usable in a situation like our. -- - Andrea Peri . . . . . . . . . qwerty àèìòù - ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] raster visualization
Hi Agus , thx for your informations. Opening the raster layers very fast but getting a bad visualization would not be a major waste of time? This is what currently happens to me: the initial display is always useless. I understand your point of view, but i guess is not a need for every users. Same users can't wait the 4+ minutes need for the elaboration of a raster. Again because an user could open usually more than 20 rasters for every session, I guess this elaboration should be absolutely optional to avoid a really big lost of time. If your raster layers have similar statistics and or you want to display them with the same stretching so that grey levels or colors are comparable (which is often my case also, with time series of ndvi for example), a common style file would be the best solution. Your solution seem good to me. We have more set of rasters of ortophoto type colors and grey. Eachset of colors photo is surely with comparable levels, instead I don't know for the gray photo sets. They are too older (1954 and so on). Instead for raster cell (grid data) from Lidar: Just now we begin to merge all our sets to have a full land-cover. So we are merging 1x1, 2x2 and 3x3 meters cells. I don't know if this could have some trouble with having a comparable set of values, but guess of no. Surely is not possible to find a unique style good for all the sets, but is possible to establish a good style for each set. ...Perhaps, in case a raster style is present, the by default procedure and calculations could be bypassed. Would this be a good solution in your case? You mean a file raster-style in the same folder of the raster set or of the catalog file ? I guess this could be a good compromise to help the use in situation like ours. Andrea. Il 22/04/2012 19:43, Agustin Lobo ha scritto: Andrea, Opening the raster layers very fast but getting a bad visualization would not be a major waste of time? This is what currently happens to me: the initial display is always useless. If your raster layers have similar statistics and or you want to display them with the same stretching so that grey levels or colors are comparable (which is often my case also, with time series of ndvi for example), a common style file would be the best solution. Perhaps, in case a raster style is present, the by default procedure and calculations could be bypassed. Would this be a good solution in your case? Agus El día 20 de abril de 2012 15:10, Andrea Periaperi2...@gmail.com escribió: - on initial load of a raster, generate a quicklook that is the larger of 1/4 screen resolution or 500x500 pixels by sampling every nth pixel - generate a histogram from the quicklook - calculate clipped 2% - 96% range min max for each band - apply a histogram stretch based on the above - the histogram could be used for generating the graph in raster props, and the quicklook could be used to create thumbs and previews etc - ideally we should cache these quicklooks and only regenerate them if the underlying dataset has changed I believe if we do this we will have fast initial load and the images (grayscale and rgb) will 'look right' when first loaded (i.e with good contrast) and it would not be necessary to assign any color value to grayscales by default. Regards Hi, just my 2 ct. I guess the more important capability with raster is to open they faster possible. I fear calculate all these values on first opened take more time than what is waitable for the open of a raster. Perhaps this action should be choosable by settings ? Of course I see our situation. Our situation is of more sets of raster (7-800 each set) where every raster is grey level or true color of 3-400 Mbyte each. And all these raster are accessible by a remote shared server to our users. For a total, actually, of about 13.000 rasters. I don't understand if this new feature could be really usable in a situation like our. -- - Andrea Peri . . . . . . . . . qwerty àèìòù - ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] raster visualization
Hi all. Visualizing monoband rasters could be improved: - why not loading it with a greyscale by default? or with a colour ramp? - why not adding a dtm colour table (we can take the one in/usr/lib/grass64/etc/colors/terrain), possibly replacing the Freak out one? Small changes, much more pleasant experience for users. Thoughts? All the best. -- Paolo Cavallini See: http://www.faunalia.it/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] raster visualization
On Fri, 2012-04-20 at 10:19 +0200, Paolo Cavallini wrote: Hi all. Visualizing monoband rasters could be improved: - why not loading it with a greyscale by default? or with a colour ramp? - why not adding a dtm colour table (we can take the one in/usr/lib/grass64/etc/colors/terrain), possibly replacing the Freak out one? +100 much needed improvements -- Giovanni -- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] raster visualization
Hi On Fri, Apr 20, 2012 at 10:47 AM, Giovanni Manghi giovanni.man...@gmail.com wrote: On Fri, 2012-04-20 at 10:19 +0200, Paolo Cavallini wrote: Hi all. Visualizing monoband rasters could be improved: - why not loading it with a greyscale by default? or with a colour ramp? - why not adding a dtm colour table (we can take the one in/usr/lib/grass64/etc/colors/terrain), possibly replacing the Freak out one? +100 much needed improvements All good ideas but we are feature frozen so lets first focus on releasing 1.8 and then we can do these. BTW Freak out will go after resampler branch is merged Regards Tim -- Giovanni -- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Tim Sutton - QGIS Project Steering Committee Member (Release Manager) == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Visit http://linfiniti.com to find out about: * QGIS programming and support services * Mapserver and PostGIS based hosting plans * FOSS Consulting Services Skype: timlinux Irc: timlinux on #qgis at freenode.net == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] raster visualization
Hi BTW Freak out will go after resampler branch is merged I've managed to convert freakout style to singleband pseudocolor in the project file / qml conversion to the new format :-) - visualizing monoband rasters could be improved: - why not loading it with a greyscale by default? or with a colour ramp? - why not adding a dtm colour table (we can take the one I'd like to improve selecting colorramps in the raster resampler branch (that would even allow us to add a freakout color ramp for trips down memory lane). Default style: I'm not sure what would be a good default, since we don't know the value range at the beginning (at least not without doing a time consuming value scan). Do you have any ideas (maybe a partial raster scan to speed things up?). Regards, Marco On 20.04.2012 11:10, Tim Sutton wrote: Hi On Fri, Apr 20, 2012 at 10:47 AM, Giovanni Manghi giovanni.man...@gmail.com wrote: On Fri, 2012-04-20 at 10:19 +0200, Paolo Cavallini wrote: Hi all. Visualizing monoband rasters could be improved: - why not loading it with a greyscale by default? or with a colour ramp? - why not adding a dtm colour table (we can take the one in/usr/lib/grass64/etc/colors/terrain), possibly replacing the Freak out one? +100 much needed improvements All good ideas but we are feature frozen so lets first focus on releasing 1.8 and then we can do these. BTW Freak out will go after resampler branch is merged Regards Tim -- Giovanni -- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Dr. Marco Hugentobler Sourcepole - Linux Open Source Solutions Churerstrasse 22, CH-8808 Pfäffikon SZ, Switzerland marco.hugentob...@sourcepole.ch http://www.sourcepole.ch Technical Advisor QGIS Project Steering Committee ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] raster visualization
Hi On Fri, Apr 20, 2012 at 2:17 PM, Marco Hugentobler marco.hugentob...@sourcepole.ch wrote: Hi BTW Freak out will go after resampler branch is merged I've managed to convert freakout style to singleband pseudocolor in the project file / qml conversion to the new format :-) - visualizing monoband rasters could be improved: - why not loading it with a greyscale by default? or with a colour ramp? - why not adding a dtm colour table (we can take the one I'd like to improve selecting colorramps in the raster resampler branch (that would even allow us to add a freakout color ramp for trips down memory lane). Default style: I'm not sure what would be a good default, since we don't know the value range at the beginning (at least not without doing a time consuming value scan). Do you have any ideas (maybe a partial raster scan to speed things up?). Yes - Julien had a really nice suggestion to implement the following logic: - on initial load of a raster, generate a quicklook that is the larger of 1/4 screen resolution or 500x500 pixels by sampling every nth pixel - generate a histogram from the quicklook - calculate clipped 2% - 96% range min max for each band - apply a histogram stretch based on the above - the histogram could be used for generating the graph in raster props, and the quicklook could be used to create thumbs and previews etc - ideally we should cache these quicklooks and only regenerate them if the underlying dataset has changed I believe if we do this we will have fast initial load and the images (grayscale and rgb) will 'look right' when first loaded (i.e with good contrast) and it would not be necessary to assign any color value to grayscales by default. Regards Tim Regards, Marco On 20.04.2012 11:10, Tim Sutton wrote: Hi On Fri, Apr 20, 2012 at 10:47 AM, Giovanni Manghi giovanni.man...@gmail.com wrote: On Fri, 2012-04-20 at 10:19 +0200, Paolo Cavallini wrote: Hi all. Visualizing monoband rasters could be improved: - why not loading it with a greyscale by default? or with a colour ramp? - why not adding a dtm colour table (we can take the one in/usr/lib/grass64/etc/colors/terrain), possibly replacing the Freak out one? +100 much needed improvements All good ideas but we are feature frozen so lets first focus on releasing 1.8 and then we can do these. BTW Freak out will go after resampler branch is merged Regards Tim -- Giovanni -- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Dr. Marco Hugentobler Sourcepole - Linux Open Source Solutions Churerstrasse 22, CH-8808 Pfäffikon SZ, Switzerland marco.hugentob...@sourcepole.ch http://www.sourcepole.ch Technical Advisor QGIS Project Steering Committee ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Tim Sutton - QGIS Project Steering Committee Member (Release Manager) == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Visit http://linfiniti.com to find out about: * QGIS programming and support services * Mapserver and PostGIS based hosting plans * FOSS Consulting Services Skype: timlinux Irc: timlinux on #qgis at freenode.net == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] raster visualization
- on initial load of a raster, generate a quicklook that is the larger of 1/4 screen resolution or 500x500 pixels by sampling every nth pixel - generate a histogram from the quicklook - calculate clipped 2% - 96% range min max for each band - apply a histogram stretch based on the above - the histogram could be used for generating the graph in raster props, and the quicklook could be used to create thumbs and previews etc - ideally we should cache these quicklooks and only regenerate them if the underlying dataset has changed I believe if we do this we will have fast initial load and the images (grayscale and rgb) will 'look right' when first loaded (i.e with good contrast) and it would not be necessary to assign any color value to grayscales by default. Regards Hi, just my 2 ct. I guess the more important capability with raster is to open they faster possible. I fear calculate all these values on first opened take more time than what is waitable for the open of a raster. Perhaps this action should be choosable by settings ? Of course I see our situation. Our situation is of more sets of raster (7-800 each set) where every raster is grey level or true color of 3-400 Mbyte each. And all these raster are accessible by a remote shared server to our users. For a total, actually, of about 13.000 rasters. I don't understand if this new feature could be really usable in a situation like our. -- - Andrea Peri . . . . . . . . . qwerty àèìòù - ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
