[gdal-dev] FW: Problem with GDAL perl 1.5 bindings
Ethan Alpert
ealpert at digitalglobe.com
Fri Feb 1 01:08:13 EST 2008
Ari,
I believe reference counts can be manipulated in perlguts. Would it be
possible to undef any rasterband variables referencing stale/orphaned
raster bands when the parent dataset is destroyed/dereferenced? This
would allow for perl to exit with a perl error rather than dumping core
as well wouldn't it?
Is there any use of a rasterband that has no parent dataset?
If not then trying to use it after it's dataset is destroyed and no
other datasets reference it would be a programming error and the perl
"Can't call method "WriteRaster" on an undefined value at ./test.pl line
10", for instance, would be very appropriate and much more informative
than a core dump. It would also be a better outcome than producing a
bogus tiff.IMHO
Anyhow just curious if this is possible and was thinking about my
problem.
-e
-----Original Message-----
From: Ari Jolma [mailto:ari.jolma at tkk.fi]
Sent: Thursday, January 31, 2008 10:27 AM
To: Ethan Alpert
Cc: gdal-dev at lists.osgeo.org
Subject: Re: [gdal-dev] FW: Problem with GDAL perl 1.5 bindings
Ethan Alpert kirjoitti:
> Ari,
>
> Thanks for the response. Both suggested approaches fix the problem. I
> sort of see the utility of this approach however I still believe that
a
> FlushCache and dereferencing a dataset object should result in the
> output file being closed and in a complete state. Since the rasterband
> is associated with a dataset what is the usefulness of keeping the
> dadtaset and it's rasterband after its dataset has been "closed"? If
you
> don't dereference the bands the resulting file is not just incomplete
> but wrong. Extra data gets written into the tif and the georeferncing
is
> overwritten.
>
The main idea is to prevent segfaults. If a reference to a closed
dataset is allowed to exist, using it would cause a segfault. Yes, I see
that ideally it should just make the rasterband object stale underneath
the user code. However, I don't know how to achieve that efficiently or
without modifying GDAL itself.
Hm, the first would require maintaining a list of valid rasterband
objects and at the beginning of each rasterband method the object should
be tested for validity. Probably not very efficient.
Ari
> -e
>
>
>
> -----Original Message-----
> From: Ari Jolma [mailto:ari.jolma at tkk.fi]
> Sent: Thursday, January 31, 2008 1:48 AM
> To: Ethan Alpert
> Cc: gdal-dev at lists.osgeo.org
> Subject: Re: [gdal-dev] FW: Problem with GDAL perl 1.5 bindings
>
> Ethan,
>
> This is because of something, which is a good thing. You (now in 1.5)
> get a reference to the dataset you create by getting its raster band.
> Geo::GDAL does not destroy the dataset while there is a reference to
it.
>
> You either need to use the non-referencing version of GetRasterBand,
> which is _GetRasterBand or get rid of the reference by destroying the
> raster variable $b.
>
> Best regards,
>
> Ari
>
> Ethan Alpert kirjoitti:
>
>> Prior to 1.5 I'd been using the trunk version from 11/06/2007.
Looking
>>
>
>
>> at gdal_wrap.cpp I see that there were two versions checked in 1.3.31
>> and 1.3.30. One of these checks breaks a piece of code that worked
>> fine in version 1.3.29
>>
>> The problem relates to clean up when an object is dereferenced in
>>
> perl.
>
>> For many releases now if I created and wrote an image I would have to
>> Call FlushCache **and** undef the variable referencing the
GDALdataset
>>
>
>
>> inorder for all the data I wrote to actually end up in the file. This
>> no longer works. Now I must exit my perl script completely for the
all
>>
>
>
>> the data to be completely written.
>>
>> Below is an example of converting to grayscale. This works great if
at
>>
>
>
>> the end I'm done. But this is not the case. Later in the script I
call
>>
>
>
>> gdal_rasterize and the resulting file ends up not having a
>> geotransform and is 3x too big. If I exit my app and call
>> gdal_rasterize manually everything works correctly. This is what led
>> me to believe there's been a change in the perl binding that relate
to
>>
>
>
>> cleaning up and finalizing the file that now doesn't execute on
>> derference but only when the perl script exits.
>>
>> On 11/06/2007 my code worked. Today with the stock 1.5 it doesn't. So
>> my question is there some function to call to force the file to be
>> completely written? If not is there a way to revert to the prior
>> functionality. .
>>
>> $gtiff_driver = Geo::GDAL::GetDriverByName('GTiff');
>>
>> $fil = Geo::GDAL::Open("$tmp_dir/$$.tif");
>>
>> $xsize = $fil->{RasterXSize};
>>
>> $ysize = $fil->{RasterYSize};
>>
>> $tot = $xsize;
>>
>> $width = $xsize;
>>
>> $bandr = $fil->GetRasterBand(1);
>>
>> $bandg = $fil->GetRasterBand(2);
>>
>> $bandb = $fil->GetRasterBand(3);
>>
>> $output_ds= $gtiff_driver->Create("$tmp_dir/$$\_bw.tif",
>> $fil->{RasterXSize}, $fil->{RasterYSize}, 1,
>>
> $Geo::GDAL::Const::GDT_Byte);
>
>> $output_ds->SetGeoTransform($fil->GetGeoTransform);
>>
>> $output_ds->SetProjection($fil->GetProjection);
>>
>> $b = $output_ds->GetRasterBand(1);
>>
>> for($k = 0; $k < $fil->{RasterYSize}; $k++) {
>>
>> $scanliner = $bandr->ReadRaster(0,$k,$fil->{RasterXSize},1);
>>
>> $scanlineb = $bandb->ReadRaster(0,$k,$fil->{RasterXSize},1);
>>
>> $scanlineg = $bandg->ReadRaster(0,$k,$fil->{RasterXSize},1);
>>
>> @datar = unpack("C[$tot]",$scanliner);
>>
>> @datag = unpack("C[$tot]",$scanlineg);
>>
>> @datab = unpack("C[$tot]",$scanlineb);
>>
>> @datagrey = ();
>>
>> $min = 300;
>>
>> $max = -1;
>>
>> for ($i = 0; $i < scalar @datar; $i++) {
>>
>> $t = (.3 * $datar[$i] + .59 * $datag[$i] + .11 * $datab[$i]) +
>>
> .000001;
>
>> push @datagrey, int ($t+.5);
>>
>> }
>>
>> $ot = pack("c[$tot]", at datagrey);
>>
>> $b->WriteRaster(0,$k,$width,1,$ot);
>>
>> }
>>
>> $output_ds->FlushCache;
>>
>> undef $output_ds;
>>
>> later I call:
>>
>> system "gdal_rasterize -i -l $$ -b 1 -burn 0 $tmp_dir/$$.shp
>> $tmp_dir/$$\_bw.tif ";
>>
>>
>>
>
------------------------------------------------------------------------
>
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>
>
>
--
Prof. Ari Jolma
Geoinformatiikka / Geoinformatics
Teknillinen Korkeakoulu / Helsinki University of Technology
tel: +358 9 451 3886 address: POBox 1200, 02015 TKK, Finland
Email: ari.jolma at tkk.fi URL: http://www.tkk.fi/~jolma
More information about the gdal-dev
mailing list