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).

> 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.

> 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.

> 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....

Glad you've got things working again,
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
>


_______________________________________________
Perldl mailing list
[email protected]
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl

Reply via email to