MrSID dataset

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

MrSID dataset

Andy Tompkins
I have just started using GDAL and I have a question about the MrSID
dataset.

I find that I get a black line drawn down the left and bottom sides of
the image after decoding the file with dataset->RasterIO().  I believe
that I have found a fix for this problem.

change MrSIDDataset::IRasterIO(), line 761 from:
    nZoomMag * 2 < (dfZoomMag + 0.1) && iOverview < nOverviewCount;
to
    nZoomMag * 2 < dfZoomMag && iOverview < nOverviewCount;

and change MrSIDDataset::IRasterIO(), lines 772, and 773 from:
    nTmpXSize = (int) floor( nXSize / (double) nZoomMag + 0.99 );
    nTmpYSize = (int) floor( nYSize / (double) nZoomMag + 0.99 );
to
    nTmpXSize = (int) floor( nXSize / (double) nZoomMag );
    nTmpYSize = (int) floor( nYSize / (double) nZoomMag );

This seems to fix the problem.  I guess I am wondering if I have missed
something and/or if there is a better/correct way to fix my problem?
Also, if
this is a good/correct fix, how does this change get into
GDAL?

Thank you in advance,
  Andy Tompkins
_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

RE: MrSID dataset

Kirk McKelvey
 
Andy,

The MrSID formats decode natively only at "octave" (integral
power-of-two) zoom-levels, in other words 1:1, 4:1, 16:1, et cetera.  It
looks like the logic in MrSIDDataset::IRasterIO() is doing two things:
  1. deciding which octave to decode (since it may be given a non-octave
zoom-level)
  2. translating the given pixel coords into that octave
Then the octave decode is resampled to fulfill the original zoom-level
requested.

So my question is whether you can take just one or the other of your
changes to fix the problem?  The first fudge-factor (0.1) is
manipulating the octave decision and the second fudge-factor (0.99)
looks like it is manipulating the rounding in the pixel translation.
I'm guessing you can fix your problem with just the second change.

As for whether it is the "right" change, well, someone probably put that
fudge-factor in there because they were seeing black lines of their own,
and if you take it out, theirs will come back.  The right change
involves using the LizardTech classes and methods to do zoom and
coordinate calculations.

I recently began rewriting MrSIDDataset for speed and code correctness,
and I'll make sure to address this issue while I'm in there.  You may
have to wait a few weeks though since this work is competing with other
tasks.

Cheers,
Kirk


-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Andy Tompkins
Sent: Wednesday, September 21, 2005 5:17 AM
To: [hidden email]
Subject: [Gdal-dev] MrSID dataset

I have just started using GDAL and I have a question about the MrSID
dataset.

I find that I get a black line drawn down the left and bottom sides of
the image after decoding the file with dataset->RasterIO().  I believe
that I have found a fix for this problem.

change MrSIDDataset::IRasterIO(), line 761 from:
    nZoomMag * 2 < (dfZoomMag + 0.1) && iOverview < nOverviewCount; to
    nZoomMag * 2 < dfZoomMag && iOverview < nOverviewCount;

and change MrSIDDataset::IRasterIO(), lines 772, and 773 from:
    nTmpXSize = (int) floor( nXSize / (double) nZoomMag + 0.99 );
    nTmpYSize = (int) floor( nYSize / (double) nZoomMag + 0.99 ); to
    nTmpXSize = (int) floor( nXSize / (double) nZoomMag );
    nTmpYSize = (int) floor( nYSize / (double) nZoomMag );

This seems to fix the problem.  I guess I am wondering if I have missed
something and/or if there is a better/correct way to fix my problem?
Also, if
this is a good/correct fix, how does this change get into GDAL?

Thank you in advance,
  Andy Tompkins
_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev

_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: MrSID dataset

Andy Tompkins
In reply to this post by Andy Tompkins
> Andy,
>
> The MrSID formats decode natively only at "octave" (integral
> power-of-two) zoom-levels, in other words 1:1, 4:1, 16:1, et cetera.  It
> looks like the logic in MrSIDDataset::IRasterIO() is doing two things:
>  1. deciding which octave to decode (since it may be given a non-octave
> zoom-level)
>  2. translating the given pixel coords into that octave
> Then the octave decode is resampled to fulfill the original zoom-level
> requested.
>
> So my question is whether you can take just one or the other of your
> changes to fix the problem?  The first fudge-factor (0.1) is
> manipulating the octave decision and the second fudge-factor (0.99)
> looks like it is manipulating the rounding in the pixel translation.
> I'm guessing you can fix your problem with just the second change.
>
> As for whether it is the "right" change, well, someone probably put that
> fudge-factor in there because they were seeing black lines of their own,
> and if you take it out, theirs will come back.  The right change
> involves using the LizardTech classes and methods to do zoom and
> coordinate calculations.
>
> I recently began rewriting MrSIDDataset for speed and code correctness,
> and I'll make sure to address this issue while I'm in there.  You may
> have to wait a few weeks though since this work is competing with other
> tasks.
>
> Cheers,
> Kirk
>
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Andy Tompkins
> Sent: Wednesday, September 21, 2005 5:17 AM
> To: [hidden email]
> Subject: [Gdal-dev] MrSID dataset
>
> I have just started using GDAL and I have a question about the MrSID
> dataset.
>
> I find that I get a black line drawn down the left and bottom sides of
> the image after decoding the file with dataset->RasterIO().  I believe
> that I have found a fix for this problem.
>
> change MrSIDDataset::IRasterIO(), line 761 from:
>    nZoomMag * 2 < (dfZoomMag + 0.1) && iOverview < nOverviewCount; to
>    nZoomMag * 2 < dfZoomMag && iOverview < nOverviewCount;
>
> and change MrSIDDataset::IRasterIO(), lines 772, and 773 from:
>    nTmpXSize = (int) floor( nXSize / (double) nZoomMag + 0.99 );
>    nTmpYSize = (int) floor( nYSize / (double) nZoomMag + 0.99 ); to
>    nTmpXSize = (int) floor( nXSize / (double) nZoomMag );
>    nTmpYSize = (int) floor( nYSize / (double) nZoomMag );
>
> This seems to fix the problem.  I guess I am wondering if I have missed
> something and/or if there is a better/correct way to fix my problem?
> Also, if
> this is a good/correct fix, how does this change get into GDAL?
>
> Thank you in advance,
>  Andy Tompkins
> _______________________________________________
> Gdal-dev mailing list
> [hidden email]
> http://lists.maptools.org/mailman/listinfo/gdal-dev

Kirk,

Thank you for replying with such good information.  You are correct,
just
changing the second fudge-factor (0.99 - for the rounding in the pixel
translation) fixes my problem.  I look forward you your rewrite of the
MrSIDDataset!

Thanks again,
  Andy.
_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev