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 ======================================================================= _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
