On Tue, Aug 31, 2010 at 11:54 AM, Chris Marshall <[email protected]> wrote: >> I would love to learn that I am doing something stupid, >> but I am fairly convinced that there is either a bug or >> an untrapped error in the PDL code. > > Actually the error is being trapped which is what > you have reported. The problem is that you have > bad values in the image data that you are trying > to save. > > If there is a problem with the current PDL > code, it may be that an error is *not* being given > for the non-LUT wpic() case. > > At any rate, the fix is to save image data *without* > bad values in them. I suggest using setbadtoval() > and then make that value in your color map special > (e.g., bright red so you can see the erroneous pixels). >
I don't even know which value is bad? If I can't see it, if I don't know which one it is, if I can't even list it out, how do I know which one to setbadtoval()? I already have set -9999 to bad, as those are pixels with no data. I used to have NaNs, and I have gotten rid of those. Now, as far as I can tell, I have either -9999, or I have a valid number. When I write the entire piddle to a b&w image, it writes fine. When I try to use a LUT, all hell breaks loose. as you say, I should use "setbadtoval() and then make that value in your color map special." What is "that value"? That is what I am trying to determine. > --Chris > -- Puneet Kishor http://www.punkish.org Carbon Model http://carbonmodel.org Charter Member, Open Source Geospatial Foundation http://www.osgeo.org Science Commons Fellow, http://sciencecommons.org/about/whoweare/kishor Nelson Institute, UW-Madison http://www.nelson.wisc.edu ----------------------------------------------------------------------- Assertions are politics; backing up assertions with evidence is science ======================================================================= _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
