problems with RGB rasters under 1.7/trunk #13925
Comments
|
Author Name: Giovanni Manghi (@gioman) please ignore the first image attached, I picked the the wrong file. |
|
Author Name: Tim Sutton (Tim Sutton)
|
|
Author Name: Tim Sutton (Tim Sutton) Ok I deleted the bad image. |
|
Author Name: Tim Sutton (Tim Sutton) Ok it seems to be caused by the fact that your image is in 16bit rgb rather than 8 bit rgb. Doing this: and then opening the resulting file lets it display fine. Under linux the original 16 bit image displays fine, so there must be some issue that is specific to displaying 16bit rgb rasters - either with the OSGEO4W build of gdal or with the QGIS raster implementation under windows.
|
|
Author Name: Giovanni Manghi (@gioman) Hi Tim, the problem is slightly different: QGIS on Windows open 8 bits rasters as 16 bits, 16 bits rasters as 32 bits, etc. This seems not to make any difference on one banded images but it is causing the issue on RGB images. Tim Sutton wrote:
|
|
Author Name: Giovanni Manghi (@gioman) I tested 8/16 bit images both single band and RGB with Mapserver/OsGEO4w and it all works fine, so I guess that the problem it QGIS... Tim Sutton wrote:
|
|
Author Name: Giovanni Manghi (@gioman)
|
|
Author Name: Giovanni Manghi (@gioman) I start now to see the same issue on Linux also, so I'm starting to be really worried, especially because the 1.7 code seems to be affected. So, here is what I'm seeing on Linux (Ubuntu 10.04), eventually I'll start over the tests also under Windows (but in any case under Windows every fresh installation of the SO with qgis > 1.6 is affected). a) Ubuntugis repository, qgis 1.6 compiled against gdal 1.8: rasters do open as expected, quick as always (even very large rasters), no problems with the colors table b) Nightly build repository (after having removed the ubuntugis one and purged everything), qgis-trunk compiled against gdal 1.6.3: opening rasters takes a lot, 8 bit images are shown as 16 bit (in the metadata), 16 bit as 32 bit and so on. RGB images are rendered with a strange color table. c) QGIS trunk compiled from source against gdal 1.8 (so, with the ubuntugis repository enabled): the behavior is the same described in b) I also tested on the same machine to render the same rasters with Mapserver and with the same gdal libraries/versions, and I found no problems at all. I guess that the problem appeared in QGIS sometime along the road to 1.7 and it has not been fixed yet in trunk. Hope to hear for you soon.
|
|
Author Name: Giovanni Manghi (@gioman) I've just installed form scratch a Ubuntu Natty machine, added the nightly build repo and installed qgis trunk (and no other kind of software). The issue is then confirmed (as on Windows). |
|
Author Name: Giovanni Manghi (@gioman) Hi Radim, as I explained along the way, the problem is not OS specific or data specific. It affects ALL the fresh installations (for example in pcs where the OS was installed from scratch) and in all the machines where previous QGIS installations where purged completely. I also found machines (both linux and Windows) that had QGIS installed and that an upgrade (not removing completely the previous installation) to 1.7/trunk do not produce the issue. For example yesterday I saved (with "save as image") my canvas that was showing a street map added with the "openlayer plugin". The file as was saved in my pc is attached. If you open it outside qgis it shows OK. On the other hand if you reopens it in QGIS it will show as the screeshot I also will attach here. The other two big problems are: the RGB rasters do take a long to open. You will not see much difference with small images, but with >100mb rasters you will see the lag. Tiles and overviews seems also do be completely ignored. The metadata also needs to be fixed at it shows the wrong type of image: 8bits do show as 16bits, 16bits as 32 bit, and so on.
|
|
Author Name: Giovanni Manghi (@gioman)
|
|
Author Name: Giovanni Manghi (@gioman)
|
|
Author Name: Giovanni Manghi (@gioman) Any chance to give it a try in a Virtual machine where you can install from scratch OS (like Ubuntu Linux) and QGIS (possibly using repos like the Ubuntu nightly build or Ubuntugis)? From my tests I also conclude that is not a GDAL problem, as the issue surfaces with both gdal 1.6.3 (ubuntu) and gdal 1.8 (ubuntugis and Windows). Using the same GDAL libraries, in the same machine, with mapserver, the output is fine. |
|
Author Name: Radim Blazek (@blazek) Because your colors are darker, it could be that a higher max values are used. If you go to style tab in properties and select stretch to min/max + apply, what values appear in red/green/blue max fields? For me style tab is not available in current mater. Another bug? You can try with 1.7. |
|
Author Name: Jürgen Fischer (@jef-n)
|
|
Author Name: Giovanni Manghi (@gioman) Ok, playing around with the style parameters/values ("load min/max values from band") the colors do show as expected (but as the "contrast enhancement" parameter is saved as "stretch to min max" I would expect to see the right colors immediately). Not handy as I never seen this behavior before in the previous qgis releases. I guess that we cannot expect the common user to open their rasters and have to go in the raster properties every time to fix manually this. The remaining huge problem is the fact that is extremely slow to open rasters. I'm not speaking of huge rasters with no overviews. You will see the (small) lag also with tiff of 50mb. I have 3gb geotiffs with overviews that in 1.6 they open in a eye blink and that in 1.7/trunk simply freeze the program for minutes. By the way, this problem affects also the single band rasters. |
|
Author Name: Giovanni Manghi (@gioman) I will post you a screencast in a few minutes. So you can see what I'm speaking about. |
|
Author Name: Giovanni Manghi (@gioman) Oh gosh, it really start to be frustrating. I have two identical VMs with Windows Seven/osgeo4w for tests. In one of them I just updated osgeo4w, and it updated trunk and updated 1.6 to 1.7. In this machine/installation now I can't see anymore the issue with the colors. On the other hand I opened the other VM and I didn't made any update, so I still had qgis 1.6 and trunk (the latter a few days old). If I open a raster I still can see the issue of the colors. Then I updated also this one and I still see the colors problem... The "style" properties are configured the same in both machines. Under Ubuntu (clean install) and the nightly build repository I still can see the colors problem. In any case we can consider this problem as secondary, what it hurts is the slowness while opening rasters (still true under Windows and Linux). The console shows this messages when opening a raster, and the raster actually does not show until the last message is thrown @warning: Object::connect: No such signal QgsGdalProvider::statusChanged( QString ) in /tmp/buildd/qgis-1.8.0+git20110613+a954488 |
|
Author Name: Giovanni Manghi (@gioman) Adding the first cast, to show the difference between qgis 1.6 and trunk osgeo4w. After updating osgeo4w (so updating qgis to 1.7) the result is the same as you can see in trunk in the video. Will post i a minute a similar video made on a clear Ubuntu Natty installation.
|
|
Author Name: Giovanni Manghi (@gioman) I really start to be upset because I cannot really find a pattern in this mess. This is my last note, feel free to do whatever you think is necessary. I still believe that there is something wrong. I have many reports of users with the same issue. I cannot clean my Ubuntu 10.04 system and reinstall everything and get rid of the issue. I tried the ubuntugis repo, the nightly build one and even compiling myself. The errors I get when loading a raster are @warning: Object::connect: No such signal QgsGdalProvider::statusChanged( QString ) in /build/buildd/qgis-1.7.0~lucid1/src/core/raster/qgsrasterlayer.cpp:2504@ then when I load a raster with overviews I get thousand of this @warning: Object::connect: No such signal QgsGdalProvider::statusChanged( QString ) in /build/buildd/qgis-1.7.0~lucid1/src/core/raster/qgsrasterlayer.cpp:2504 As I was desperate to find a pattern I again tried to re-install Windows Seven/Osgeo4w and Ubuntu Natty from scratch. On Windows the result is what you can see in the screencast I already posted. It does not works as expected, on both 1.7 and trunk. On Ubuntu Natty, it happens that it works all fine, so not confirming the observation I made in the very same machine a few days ago (see above). Nevertheless when adding rasters in Natty I get @warning: Object::connect: No such signal QgsGdalProvider::statusChanged( QString ) in /build/buildd/qgis-1.7.0~natty1/src/core/raster/qgsrasterlayer.cpp:2504@ QGIS 1.6 in any OS and installed in any form is not affected at all. |
|
Author Name: Pedro Venâncio (Pedro Venâncio) Hello I can confirm these problems reported by Giovanni, a few weeks ago that this is happening to me too. After this, I already installed on several machines QGIS versions 1.7 and 1.8, both with Windows XP and 7, and always found the problem... As Giovanni said, this seems to be a serious problem that, apparently, already exists in Linux versions. |
|
Author Name: Pedro Venâncio (Pedro Venâncio) I must also say that the version 1.6 standalone continue to work correctly on the same machines, where there are problems with versions 1.7 and 1.8. Furthermore, I had already used some 1.7dev versions, without any of these problems. At some point I detected a problem with the RGB rasters http://osgeo-org.1803224.n2.nabble.com/RGB-problem-build-1-7-0-73-td6052920.html but it was quickly solved on the following builds. |
|
Author Name: Pedro Venâncio (Pedro Venâncio) Another detail that I can add is that, despite the delay in loading the raster, after it is loaded, it works normally, fast as ever. I do not know if with Giovanni this also happens, but being so, the problem should be in loading process. For example, I am testing on a raster with 3Gb and overviews, and it takes about half an hour to load, but once inside QGIS, it runs as fast as in the standalone version. |
|
Author Name: Radim Blazek (@blazek) statusChanged() is not important, that is only implemented by wms/wfs providers. |
|
Author Name: Radim Blazek (@blazek) As you describe the problem, it seems, that under certain circumstances, the raster layer collects statistics even if it is not necessary (that's the reason why it is loading so long) and then it sets symbology using wrong min/max values or something like that. PedroNGV: Do you say that it does not work on Win7/32 but works on Win7/64 bit? Giovanni: I know, that you reported in the first post that it occurs on both Win 7/XP and 32/64. Can you still confirm that it happens also on Win7/64? |
|
Author Name: Giovanni Manghi (@gioman) Hi Radim, thanks for looking into this. I can say for sure that the issue does not depends on whatever Windows is 32 or 64 bit. I would say the same also for Linux (32 or 64 bit), but has you probably read in this ticket I had different results after having installed twice from scratch Ubuntu Natty on the same machine. In my Ubuntu 10.04 machine I cannot get rid of the issue. On the other hand every fresh installation of/on Windows, both 32 and 64 bit, is having the issue. |
|
Author Name: Pedro Venâncio (Pedro Venâncio) Hello Radim, It is very possible to be that, because when the raster is loaded at the end of that long time, the Contrast enhancement is set to "Stretch to MinMax", in contrast to what happens in the version 1.6 standalone, where the Contrast enhancement is set to "No Stretch." As for Giovanni, it happens to me in both versions, 32 and 64 bits, although the only machine that has been working well is 64bit windows 7. Thanks! |
|
Author Name: Pedro Venâncio (Pedro Venâncio) Hello again, It seems that the problem is really that. I've been testing two of my installations (Windows XP and 7) where the problem was present, and after loading the raster layer, I changed the Contrast enhancement to "No Stretch", closed QGIS. It keeps the option "No Stretch" memorized. Reopening QGIS and loading rasters is practically instantaneous!! It seems to me that the solution may be to force the Contrast Enhancement to "No Stretch" by default at the QGIS start. The ideal would be QGIS speeds up the calculation of statistics for raster layers. |
|
Author Name: Giovanni Manghi (@gioman) Pedro genius! you nailed it! it is the stretching indeed! But it also something that works in a different way compared with 1.6 I always used qgis with "stretch to min max" saved in the options and this issue never surfaced before. O gee... so happy. This needs to be fixed somehow and then backported to qgis 1.7 because otherwise we will have many puzzled people. At the same time I suggest to fix the raster metadata, now it shows the wrong number of bit. |
|
Author Name: cgsbob - (cgsbob -) I usually use "Stretch And Clip To Minimax" as my defaut (which works well with 1 band images but not with many RGB images). It would be nice if there can be default for multiband images. |
|
Author Name: Alexander Bruy (@alexbruy) Giovanni Manghi wrote:
Well. This is because before QGIS 1.7 contrast enhancement did't applied automagically to loaded rasters. In 1.7 this bug was fixed. Giovanni Manghi wrote:
Ok. Since 4d56f98 default contrast enhancement is "No Stretch"
|
qgib
added
Bug
Author Name: Giovanni Manghi (@gioman)
Original Redmine Issue: 3867
Redmine category:rasters
Hi all,
a few users reported to me saying that they were having problems with
rasters under Windows (long time to open rasters, resulting image with
"funny" colors) so I started a few tests.
After a lot of tests, removing and re-installing form scratch both
qgis (osgeo4w and standalone, the latter created with creatensis.pl) and
Windows (XP and Seven, both 32 and 64 bit) on different machines, I can
confirm this issue:
On qgis-trunk (but probably also under 1.7) it takes a lot of time to
open RGB rasters (single band rasters are not affected), even small
TIFFs of 30mb. Then the resulting image renders with "wrong" colors.
After the raster is added to the canvas, zooming and panning the map
seems normal.
QGIS 1.6 is not affected as it isn't qgis-trunk under Linux.
I'll open a ticket about this issue with a couple of screenshots just to
show what I mean with "wrong" colors.
Odd enough, I have also a XP machine (I haven't reinstalled de OS on
this one) that already had qgis-trunk osgeo4w installed and doesn't show
the above issue and that is not replicable even removing and
re-installing qgis from scratch.
Anyone else is seeing this?
The text was updated successfully, but these errors were encountered: