Because I didn't see a difference between Tiff and BMP I started testing
some more with the GDALwarp options...
And because the resolution made a difference, I tested with the -r
filters...
When I used an other filter then cubicspline, the problem was gone. So
the problem was a combination with the cubicspline filter and a specific
target resolution.
I'm using an other filter now as work-around.
The testing files will be deleted. I need the space...
Marcel
Marcel Blom schreef op 28-9-2014 om 1:17:
Hi Even,
I uploaded stuff for testing in Dropbox :
https://www.dropbox.com/sh/0f1zrs295s75u5n/AAAZI2tTokaYZtJ6cfj9zxe0a?dl=0
Because I had too much data I wanted to use lower resolution files and
guess what? On other resolutions the problems were gone.
So it might have something to do with size/resolution..(?)
I also tested warping direct from one source file and the results were
the same. But because I use a VRT with multiple source files I added a
VRT file and made these target files via the VRT file.
I have only space to upload one source file. When I used multiple
source files in the VRT the target file was even darker (svt-08+.bmp)
I uploaded :
- !buildvrt.bat (with commands to build the VRT file)
- !warp.bat (with commands to warp the VRT into target files)
- _Source.tif (as source file)
- _gdalbuild.vrt (as VRT file)
Resulting target files:
- svt-02.bmp (Source > VRT > Target 2048x2048 = normal)
- svt-04.bmp (Source > VRT > Target 4096x4096 = normal)
- svt-08.bmp (Source > VRT > Target 8192x8192 = darker)
- svt-08+.bmp (Source > VRT with multiple files > Target 8192x8192 =
even darker)
- svt-16.bmp (Source > VRT > Target 16384x16384 = normal)
Really strange.
I didn't see this behaviour with the older GDAL.
Marcel
Even Rouault schreef op 26-9-2014 om 19:46:
Marcel,
The best would be that you prepare something that others can try in a
fully
reproducable way, i.e. provide source(s) image(s) and all the exact
command
lines you use.
Even
Le vendredi 26 septembre 2014 19:41:01, Marcel Blom a écrit :
Because of some problems with GDAL 1.7.0b2 in FWTools 2.4.7 I upgraded
to GDAL 1.11.0 in the latest OSGeo4W distro. This solved some issues I
had, but introduced a really annoying one and what ever I do I can't
get
rid off it. I hope someone can help me out. If BTW I try to go back to
GDAL 1.7.0b2 with FWTools the problem is still there, so I guess it's a
(new) driver/DLL update issue.
My problem looks exactly like this post... GDAL TIF to JPG Creates Dark
Image
<http://gis.stackexchange.com/questions/101393/gdal-tif-to-jpg-creates-dark
-image> Only that I don't use JPG. And I use GDALwarp. And not all
target
files have the problem. Most target files look OK. And I only see it
with
Aerial Photo like sources. With vector like raster sources I don't
see the
problem. So when reading the other post I thought it had to do with a
mask/alpha channel or something, but I can't see this in the source.
And
whatever option I test, the problem remains.
I already created a post here :
http://gis.stackexchange.com/questions/114526/gdalwarp-creates-darker-targe
t-image-sometimes But I had no final answer... And I think this is the
right place to ask.
Here are two screenshots. One from the source (Tiff) and one from a
intersection of four target files (Tiff or BMP)
Section of Source :
https://www.dropbox.com/s/gy2tu0h8dufv41o/Source.jpg?dl=0
Intersection of four Target files :
https://www.dropbox.com/s/av7mdj8ivx3zgsl/Target.jpg?dl=0
The source I use is 8bit/channel RGB JPEG. And the merged Tiff is
8bit/channel RGB.
I tested almost all options in multiple actions in my workflow. So
cutting the source with gdaltranslate in smaller parts for editing.
Building a VRT with gdalbuildvrt and cutting into final parts with
gdalwarp which will show the problem.
I started with the -b 1 -b 2 -b 3 option in my gdalbuildvrt action, but
GDAL crashes here... (?) I also tested other options that might have
something to do with the problem... -nomd -co ALPHA=YES/No -co
PHOTOMETRIC=RGBA/RGB -setci, you name it...
I checked good and bad source and target areas with gdalcompare and
gdalinfo, but I saw nothing strange...
I'm now thinking of resetting GDAL driver settings if that is
possible..(?)
Has anyone seen this before? Can anyone give me a hint..?
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
