top posting -- also, please note that I ripped code out of ImageRGB.pm into my own script. This means that it is not PDL::IO::Pic that doesn't handle bad values. Actually, index() doesn't handle bad values.
Since I was using Craig's bigstring() to print out the piddle values, and since bigstring uses list(), list() doesn't handle bad values as well. It was $pdl->list that was croaking. On Tue, Aug 31, 2010 at 6:24 PM, P Kishor <[email protected]> wrote: > On Tue, Aug 31, 2010 at 6:05 PM, Chris Marshall <[email protected]> wrote: >> On 8/31/2010 6:39 PM, P Kishor wrote: >>> >>> Hi Chris, >>> >>> On Tue, Aug 31, 2010 at 5:21 PM, Chris Marshall<[email protected]> wrote: >>>> >>>> On 8/31/2010 4:36 PM, P Kishor wrote: >>>>> >>>>> even more bizarre... >>>>> >>>>> On Tue, Aug 31, 2010 at 1:14 PM, P Kishor<[email protected]> wrote: >>>>>> >>>>>> On Tue, Aug 31, 2010 at 11:59 AM, P Kishor<[email protected]> >>>>>> wrote: >>>>>>> >>>>>>> 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). >>>> >>>> So you didn't have any luck with: >>>> >>>> pdl> $pdl->inplace->setbadtoval(255) >>>> pdl> $lut->slice(':,(255)) .= pdl(255,0,0) >>>> pdl> $pdl->wpic('nobadshere.png', { LUT=>$lut }) >>>> >>> >>> Amazing. Whatever the above is doing, it works! >> >> All the bad values are set to 255. >> Then the LUT value for 255 was set to red (255,0,0). > > > So, here is what is really interesting. My piddle, the one that causes > the index problems, had the badflag set to 1. I did the following > > $pdl->badflag(0); > > and now, like magic, PDL::IO::Pic prints my image just fine, without > requiring your code correction. > >> >>> In the meantime, here are a few more interesting things. I tried >>> PDL::IO::GD. Three things -- >>> >>> One, PDL::IO::GD works without your above code. In other words, >>> PDL::IO::GD works fine where PDL::IO::Pic fails. >> >> It all depends on the handling given to bad values. > > > Right. PDL::IO::GD handles bad values, while PDL::IO::Pic croaks. Once > again, would be nice if they were consistent. > > >> >>> Two, PDL::IO::GD doesn't require the "video correction." In other >>> words, the image comes out right side up without requiring Craig's >>> "affine transformation with a negative increment." Of course, without >>> that correction, the output from PDL::IO::Pic is flipped. >> >> Different image formats have different standards for the >> coordinate systems used. >> >>> Three, and here may be the clue for the problem I am having, given >>> exactly the same LUT, PDL::IO::GD prints the "correct" colors, while >>> PDL::IO::Pic with your code above, prints all the bad values as red. >>> These are the pixels that lie outside my area-of-interest. I don't >>> know if this mailing list allows attachments, but I have attached the >>> two images. >> >> Since bad values have no defined color, the fact that the >> colors assigned by PDL::IO::GD are pleasing to you is either >> because the GD code handles bad values (i.e., the code could >> assign the median of the surrounding values to the bad pixel) >> or because the color it assigned is not objectionable, maybe >> a dark color. >> > > Yes, PDL::IO::GD simply handles bad values. It was assigning the > correct color. My palette ranged from green to yellow, and it was > assigning all 255s to yellow. > > >>> It would be nice to get to the bottom of the problem I am facing, and, >>> more importantly, it would be nice to get the two graphics modules >>> working consistently. >> >> Either pick the color you want for bad values, I picked red >> so you could see them, you could pick black or the median >> of the surrounding values if you wished to ignore them. >> >> I haven't investigated the bad handling for either >> of the two modules. If you come up with a specific >> suggestion, that is what the sf.net feature requests >> is for.... >> > > I will do so. One, I will document this in the cookbook, so at least > someone else who trips on this can find the solution. > > Two, I will add a feature request. > > Three, is there any way I can update the actual PDL docs? I would like > to add it right there in the docs that PDL::IO::Pic does not handle > bad values, and that the image has to be flipped. Also, some of the > docs have spelling mistakes that I would like to correct. What is the > protocol for correcting the official docs? > > >> Glad you've got things working again, > > > Thank *you* for your patience with me, and helping me solve this. > > >> Chris >> >>> Many thanks, >>> >>> >>>> or whatever works for your case? >>>> >>>> --Chris >>>> >>>>> I added the appropriate commas to the above, and read them into $foo >>>>> and $bar. Then I did >>>>> >>>>> $res = index($foo, $bar) and voila! That worked fine! >>>>> >>>>> So, there is something going on when I do the same in my code, but the >>>>> output from my code re-read back into the code works fine. >>>>> >>>>> I will get to the bottom of this, if that is the last thing I do with >>>>> PDL. >>>> >>> >>> >>> >>> >>> >>> >>> No virus found in this incoming message. >>> Checked by AVG - www.avg.com >>> Version: 9.0.851 / Virus Database: 271.1.1/3105 - Release Date: 08/31/10 >>> 14:34:00 >>> >> >> > > > > -- > 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 > ======================================================================= > -- 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
