We don't have a hard requirement, in that we have no customers specifically
asking for this particular feature.
The requirement I am working towards is to create UI controls for all the
layers we put on a map (within reason). I am really just trying to
determine if I was doing something wrong, and if I should keep the number of
colors control in my UI. If 16 and 32 colors are not available, I wouldn't
go out of your way to make them so.
Thanks for your help,
Chase
-----Original Message-----
From: Don Dietrick [mailto:dietrick_at_bbn.com]
Sent: Friday, January 13, 2006 11:16 AM
To: Chase Barrett
Cc: openmap-users_at_bbn.com
Subject: Re: [OpenMap Users] RE: Number Of Colors in RPF Layer
On Jan 13, 2006, at 12:43 PM, Chase Barrett wrote:
>
> When loading with the above properties, RpfColortable.setNumColors
> () will
> sometimes have a value of "16" passed to it, (see breakpoints #2
> and #3 in
> the attached file), but apparently the flow of the code makes these
> calls
> ineffective.
Right. The one with the value of 16 is the one created for the
RpfCacheHandler, and the others are created for each RpfFrame and
held by their frame. Then, the RpfCacheHandler's RpfColortable gets
replaced by one of the RpfFrame versions.
> I say this because at the time RpfColortable.
> parseColorLookUpTable() is called with each new RpfFrame, the value
> of the
> table's numberOfColors field is always 216, and its
> reducedColorTable field
> is always "COLORS_216" (see breakpoint #8). Also, the images appear
> identical when setting 16 or 216 in the properties file.
Because each image is being decoded with its frame's colortable,
which is always created with 216.
Do you have a requirement to display for 16 color CADRG?
- Don
>
>
>
> -----Original Message-----
> From: Don Dietrick [mailto:dietrick_at_bbn.com]
> Sent: Friday, January 13, 2006 9:06 AM
> To: Chase Barrett
> Cc: openmap-users_at_bbn.com
> Subject: Re: [OpenMap Users] RE: Number Of Colors in RPF Layer
>
> It looks like a bug, kinda. It looks like the RpfFrameCacheHandler
> gets its RpfColorTable replaced with the frame's version that it last
> loaded. The frame's colortable object is created with the default
> settings, so you lose the properties settings.
>
> I'm starting to remember why the code does this - originially, a
> single colortable was used across all of the frames, and that
> colortable was set via the properties. This worked because the
> colortable was supposed to be the same across all frames, even though
> each frame contains colortable information as well. The problems
> started when RPF was being created without a consistent colortable
> for a product (GNC, JNC, etc) and you'd get weird colors for some
> frames when you mixed and matched data created at different times.
> The solution to this was to just have each frame use the colortable
> it has, and I think the API made it hard to pass the numberColors
> property to the RpfFrame when it's colortable object is created.
>
> And so this is the way it's been for years, and you're the first to
> mention it. :)
>
> - Don
>
>
> On Jan 12, 2006, at 12:24 PM, Chase Barrett wrote:
>
>> Any thoughts?
>>
>>
>>
>> From: Chase Barrett [mailto:chase.barrett_at_issinc.com]
>> Sent: Thursday, January 05, 2006 2:04 PM
>> To: 'openmap-users_at_bbn.com'
>> Subject: Number Of Colors in RPF Layer
>>
>>
>>
>> Hello all,
>>
>>
>>
>> I've been looking at some ONC and JNC charts with the numberColors
>> property set to various values. It seems that no matter what value
>> I choose, there's no impact on the image appearance. So if I
>> select 16, 32, or 216, the chart images appear identical.
>>
>>
>>
>> I placed a breakpoint in RpfColortable.setNumColors(), and it seems
>> that this method is always passed a value of 216, even though the
>> RpfLayer that the color table belongs to has an RpfViewAttributes
>> object with a value of 16 in its numberOfColors field.
>>
>>
>>
>> Is this a bug?
>>
>>
>>
>> Thanks,
>>
>> Chase
>>
>>
>
>
> <breakpoints.txt>
--
[To unsubscribe to this list send an email to "majdart_at_bbn.com"
with the following text in the BODY of the message "unsubscribe openmap-users"]
Received on Fri Jan 13 2006 - 15:41:28 EST