Simone Giannecchini a écrit :
> Do not worry man, I will fix this :-), I already know where to put my
> hands I was only waiting for time to allocate on this and good news is
> I have time between now and the 15th jan, so since the thing is
> bothering you and your group time to put something in place is come.
Thanks :). I will wait for your work then.
> You are right and wrong at the same time. You are right because the
> default behaviour should be not expanding the image, but this would
> not fix the problem. With this solution you would avoid exceptions
> (this is why your approach is correct, but what about scaling with
> bilinear interpolation? Yoou would get an mage which does not even
> resemble the original one (remember that pixels are indexes not real
> data hence if do bilinear or higher interpolation, you make a mess :)
Interpolations are performed on the "geophysics" view, which is the "correct"
place where to perform interpolations on oceanographic or meteorological remote
sensing data (interpolation on RGB images produce nice-looking images, but
wrong
data). All coverage operations that I coded ("Resample", "GradiantMagnitude",
etc.) automatically perform their work on the geophysics values (when
available)
and convert back (if needed) to the indexed image after the operation. I admit
that this is not appropriate for indexed images where index are not related to
geophysics values, like photographic images - we will need to find some way to
handle that.
The whole coverage module was initially designed with the following principle
in
mind: a 2D grid coverage is a matrix of floating point values, not an image.
The
matrix may be tiled and packed into integers values, and sometime appears to be
displayable (we do our best for that), but all computations are performed on
the
geophysics values, never on the integers (except in some cases where conversion
to geophysics view are not necessary, like "Resample" with "nearest neighboard"
interpolation).
> As of data integrity, going from a palette to rgb is not really
> jeopardizing integrity since data are untouched, pixel values do not
> change. It is more a matter of convenience. If you want to scale
> bilinear or subsample average or something like it on a paletted image
> the only way to do is by color expansion. Moreover here you are using
> the WMS not even the WCS. WCS is for accessing raw unrendered data but
> WMS is really meant for doing anything but accessing raw data (and
> preserving them :-) ).
But Operations.scale(...) and its friends are general-purpose methods, they are
not designed specifically for rendering or WMS. Operations.gradientMagnitude
for
example is used in real oceanographic models, with real economic activity
behind
them. Operations.resample(...) is also used for in statistical models combining
different images from different projections. We are working on real data, not
on
visual colors. It is crucial in my opinion that *all* grid coverage operation
work on real data as much as possible, including Operations.scale(...) and
Operation.crop(...). I know that Operations.scale do not touch the source
image,
but my concern is about Operations.scale output, not the sources. I really want
data integrity, because the scaled image may be the input for other operations
in a chain. Example: I want to compute the change in temperature (mounthly
average) between October and November. For some reason those images may have
different sizes. First I may scale them to a common size using
Operations.scale(...), then I compute the difference between the two images
using Operations.substract(...). If Operations.scale(...) corrupts the data
under the hood, I will get a totally wrong answer. In the context of economic
or
politic decisions based on GIS data, the consequence of converting data to RGB
in a library without explicit user request can be very domageable, much more
domageable than an image not looking nice in my opinion.
> I am not against refactoring scale as you suggest, but before dong
> that I would like to apply the fixes I have scheduled for making
> Indexed image work. Since you are reviewing this is a good occasion
> for me to get 4 eyes on the fixes :-). I will send you an email
> tomorrow about what should I do. I have a fixed deadline for doing
> this which is 15th Jan.
Thanks.
>> Same would need to be done for CroppedCoverage2D,
>> because it use the "Translate" operation.
>
> It uses the translate operation? I don't think so, it should use Crop
> and Crop internally does nothing more than a simple check on the
> boundary of the cropped region. It should not even make use of the
> hint for index color model. I am not sure Crop should give any
> problems in this case.
Current implementation of CroppedCoverage2D uses both "Crop" and "Translate"
JAI
operations. I have not investigate what "Translate" is used for however...
> Martin, since we are here, tomorrow I will send you an email on my
> thoughts about how to fix paletted images for good, bu there is one
> thing that would be really needed, much more than moving and renaming
> scale and the other operations, which is improving Raster
> Symbolization. The actual code from me and Alessio really sucks, it
> was a quick hack and we never really had time to improve it. What do
> you think about taking a look at that while I improve the management
> of the paletted images. Then we can switch, you can review and
> refactor a bit and i can review the raster symbolizer work. Is that a
> good idea?
We can try, but I'm not sure about what we means by raster symbolizer (I never
looked actually). I stand more on the numerical size of grid coverage...
Thanks again,
Martin
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
