[gdal-dev] GDALwarp creates some darker images after update from 1.7.0b2 to GDAL 1.11.0

[Marcel Blom]

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
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev