[Blindmath] Version 0.0.1 of ShapeExtractor02 is now availablefordownload

Thu Feb 16 16:32:48 UTC 2012

Hi Michael and others,

Thanks for the comments. I will embed my response in your text below.

On Thu, Feb 16, 2012 at 4:29 AM, Michael Whapples <mwhapples at aim.com> wrote:

> Hello,
> I was thinking of a different method. If the blind student is adjusting it
> then they are likely to have access to the embossing equipment (is this a
> reasonable assumption). So emboss a diagram near the middle of the range
> that normally gives a good result. This probably will give an idea if this
> mid point is too much black pixels or too few. Now if no
> knowledge/experience of what happens exists the user could then go halfway
> to the "normally" reasonable range and emboss that diagram. Again they
> probably will get an idea of which way to go again if it isn't clear at
> this point. A similar search can be continued until something good is
> found. Probably with use the user might be able to make a better guess from
> the initial embossed diagram and may decide to adjust from halfway through
> the reasonable range.
>

rgb] You are correct Michael. If the student has access to an embosser and
a good description of the image, it would work pretty well to begin by
embossing a copy at the default slider position at the center of the range
(50).

rgb] Then by examining the embossed output, the student can move the slider
to the right (possibly 75) or to the left (possibly 25) depending on
whether more or fewer black pixels seem to be needed. As you are probably
aware from your other work, a series of successive divisions by half will
often converge to a desired result rather quickly.

>
> A quick example: If you say generally the range 5% to 25% give reasonable
> results, then the first diagram might be done at 15%, if there are too many
> black pixels then they reduce it to 10 and try again. If still too much
> black pixels then may be go to 5% or may be 7.5%.
>

rgb] I need to make one clarifying point. The readout on the slider in this
program is not a readout of the percentage of black pixels. My experiments
with the percentage of black pixels were performed with an unpublished
version of a different program that provides a percentage readout. As a
result of these conversations, I think I will upgrade this program to
provide information about the percentage of black pixels to the user. With
experience, a combination of slider position and percentage black pixels
might help a student to converge on the desired result with fewer trials.

>
> I think some questions might be: Is it going to be linear, IE. is it
> correct for me to say go halfway?

rgb] The process is not linear (with respect to percentage black pixels)
for a couple of reasons. Moving the slider to the right is analogous to
lowering the sea level in the Pacific ocean and moving the slider to the
left is analogous to raising that sea level. Black pixels are analogous to
exposed land mass and white pixels are analogous to the surface of the
ocean.

rgb] As the sea level is lowered, a plateau might be exposed that will
cause a sudden nonlinear increase in the number of black pixels. Similarly,
as the sea level is raised, a plateau might be hidden causing a sudden
nonlinear decrease in the number of black pixels. However, I believe that
the adjustment process is monotonic (i.e. no local minima) up to this point
so the "divide by half" concept should always go in the right direction.

rgb] Another contributor to non-linearity has to do with my efforts to
preserve embosser real estate. This may or may not be a good idea because
it is possible that this could produce local minima. In particular, the
processing algorithm discards excess white areas around the margins. It
retains a rectangle whose sides are parallel to the x and y axes, and whose
dimensions are only slightly larger than that required to contain all of
the black pixels. If the resulting image is used to produce a full-page
embosser image, this guarantees that the available dots on the embosser
won't be wasted around the edges of the image where there are no black
pixels.

rgb] Hower, if, in the process of raising or lowering the sea level, a
small peak near the edge of the image is hidden or exposed, this can cause
a sudden change in the dimensions of that rectangle, which in turn can have
a large impact on the calculation of the percentage of black pixels.

> Another thing might be what is the smallest difference where any noticable
> change will be found IE. there probably is no point in trying 7.5 and then
> 7.6.
>

rgb] For a sighted person in the final stages of adjusting the image,
jogging the slider by a very small amount to the right or left can be
useful. However, this probably would not be useful to a blind user.

rgb] Thanks for the feedback. As mentioned earlier, I will probably upgrade
the program to make it more suitable for blind users by preventing the
onscreen display from grabbing the focus and by providing a "percentage
black" readout.

>
> Michael Whapples
>
> -----Original Message----- From: Richard Baldwin
> Sent: Thursday, February 16, 2012 12:58 AM
> To: Blind Math list for those interested in mathematics
> Subject: Re: [Blindmath] Version 0.0.1 of ShapeExtractor02 is now
> availablefordownload
>
>
> Hi Peter,
>
> As you have probably observed, a sighted person can adjust the slider and
> look at an onscreen display in order to produce an output file that meets
> some given visual criteria.
>
> The difficult issue is coming up with a criteria that a blind person can
> use to know that they have the algorithm parameters properly adjusted. I am
> open to suggestions in this regard.
>
> One criteria that I have been testing is based on the number of black
> pixels in the image. Having looked at dozens of images at random, I have
> concluded that for best results in most cases, the number of black pixels
> should range somewhere between 5-percent and 25-percent of the total number
> of pixels in the image. Any more than that and the tactile image probably
> won't be interpretable due to excessive black areas. Any less than that and
> there won't be much that can be interpreted in the tactile image.
>
> However, that is still a very large range and the optimal value differs
> from one image to the next. For example, a vector diagram containing a
> single vector in a pair of Cartesian axes usually needs to be on the low
> side for good results. However, if a background grid is placed on the
> coordinate system, the percentage of black pixels needs to be substantially
> increased or the grid and the vector won't be visible in the final tactile
> image.
>
> In some cases, with a good description, the blind user might be able to
> come up with a good guess regarding the percentage of black pixels to use.
> However, most descriptions aren't written with that criteria in mind so
> that is not something that can be counted on.
>
> Right now, the best that I can come up with is to emboss three images at 5,
> 10, and 15 percent and see which seems to be best. With that information,
> it is usually possible to make a good guess for the fourth embossed image.
>
> Once again, if anyone has any ideas in this regard, I would like to hear
> them.
>
> Thanks for the response,
> Dick Baldwin
>
> On Wed, Feb 15, 2012 at 4:21 PM, Peter Donahue <pdonahue2 at satx.rr.com
> >wrote:
>
>  Hello Dick and everyone,
>>
>> What are you doing to make the slider usable by a blind person? Keep up
>> the
>> great work.
>>
>> Peter Donahue
>>
>>
>> ----- Original Message -----
>> From: "Richard Baldwin" <baldwin at dickbaldwin.com>
>> To: "BlindMath Mailing List" <blindmath at nfbnet.org>;
>> <accessibleimage at freelists.org**>
>> Sent: Wednesday, February 15, 2012 2:31 PM
>> Subject: [Blindmath] Version 0.0.1 of ShapeExtractor02 is now available
>> fordownload
>>
>>
>> There are about 16-million good reasons why the embossed version of a
>> full-color bitmap image often fails to produce satisfactory tactile
>> results. Begin with the fact that the embossing process often discards the
>> information content of more than 16-million colors ending up with what is
>> effectively black and white, or possibly black and white with two or three
>> shades of gray in between, depending on the embossing method.
>>
>> This is illustrated by the two round images in the attached image files.
>> One image shows a typical color wheel made up of a mixture of red, green,
>> and blue primary color values. The other image shows the result of
>> transforming that color image into a four-level grayscale image. The
>> black,
>> gray, and white bands in the grayscale image identify the original colors
>> that would probably be indistinguishable in a four-level embossed image of
>> the color wheel.
>>
>> Follow the loss of color information with the fact that, unless the
>> original image is very small, the spatial sampling is probably reduced by
>> a
>> factor of 5 to 10 in the embossed image with little or no consideration
>> being given to frequency aliasing that occurs in a brute-force spatial
>> re-sampling process.
>>
>> The bottom line is that it is difficult to emboss full-color bitmap images
>> and end up with high-quality tactile images.
>>
>> In some cases, it is possible to pre-process an image in a way that will
>> cause it to produce a better embossed result than would be the case
>> without
>> such pre-processing. The new free program named ShapeExtractor02 is
>> designed with that purpose in mind. I explain this more fully in the html
>> document that is attached to this message.
>>
>> The four attached images of the horse show what I mean by pre-processing
>> the image to produce an improved embossed image.
>>
>> One image shows a full-color image of a beautiful brown hourse.
>>
>> A second image shows a four or five level grayscale version of the horse
>> image. This is pretty much what you would see if you were to copy the
>> image
>> to a multi-level embosser. Essentially, you would see large areas of dots
>> whose heights are slightly different from dots in adjoining areas. It
>> remains to be seen if a blind student could pick a horse out of that. If
>> you were to copy this to a black and white (dot or no dot) embosser, you
>> probably would not get anything that would be recognizable as a horse.
>>
>> Another image shows a pre-processed version of the horse image with black,
>> white, and three levels of gray in between. The major difference between
>> this image and the simple grayscale image is that this image tends to
>> outline the salient features of the original image with black and fill in
>> the outline with shades of gray. Thus, you don't see large areas of pixels
>> all having the same color of gray. Instead, you see outlines of shapes
>> that
>> identify the salient features of the original image. That is why this
>> program is named ShapeExtractor. I believe that an embossed version of
>> this
>> image would be more recognizable as a horse than an embossed version of
>> the
>> grayscale image on a multi-level embosser.
>>
>> Another attached image shows a black and white version of the
>> pre-processed
>> image of the horse. I'm confident that this would be more recognizable
>> that
>> the grayscale image on a black and white embosser and would probably also
>> be more recognizable on a multi-level embosser..
>>
>> In all cases, a good description would be needed to help the student to
>> understand the embossed image.
>>
>> I am pleased to announce that Version 0.0.1 of the new program
>> named ShapeExtractor02 is now posted at
>> http://www.austincc.edu/**baldwin/SWT-SVG/SVGDraw01.zip<http://www.austincc.edu/baldwin/SWT-SVG/SVGDraw01.zip>and is available for
>> free and immediate downloading. (To save space on the server, the new
>> program is encapsulated in a zip file along with some earlier programs.)
>> This new program was used to produce two of the horse images that are
>> attached to this message.
>>
>> This program accepts a bitmap image as input and writes the enhanced
>> output
>> in a jpg bitmap file that can be embossed using any process that accepts a
>> jpg file as input. For example, if you and your students are fortunate to
>> have access to an IVEO system, you could import the enhanced image into
>> IVEO and add audio descriptions of the key features of the image. Then
>> emboss the updated image on a Tiger and allow the student to explore the
>> upgraded image on an IVEO touchpad.
>>
>> The program makes it easy for sighted teachers and others who assist blind
>> students to enhance bitmap images for possible improved embosser
>> performance. An onscreen display shows the enhanced version of the image
>> so
>> it isn't necessary to emboss it to evaluate the success or lack thereof of
>> the enhancement process. An onscreen slider makes it possible to easily
>> adjust the enhancement parameters for best performance.
>>
>> This program can also be used by blind students for the same purpose using
>> default settings. Even though blind students can't operate the slider to
>> optimize the output, the default settings will often produce an improved
>> embossed image.
>>
>> To use this free program, simply download the zip file using the link that
>> is provided above, extract the contents of the zip file into an empty
>> Windows folder, read the file named __ReadMeFirst.txt, and start
>> processing
>> bitmap files.
>>
>> A copy of the user instruction file is attached to this message for direct
>> reading. Another copy of the instructions, with images intact, is
>> contained
>> in the attached zip file.
>>
>> Please let me know if this program works for you and provide suggestions
>> for improvement.
>>
>> Dick Baldwin
>>
>>
>> > --
>> Richard G. Baldwin (Dick Baldwin)
>> Home of Baldwin's on-line Java Tutorials
>> http://www.DickBaldwin.com
>>
>> Professor of Computer Information Technology
>> Austin Community College
>> (512) 223-4758
>> mailto:Baldwin at DickBaldwin.com
>> http://www.austincc.edu/**baldwin/ <http://www.austincc.edu/baldwin/>
>>
>>
>>
>>
>> ------------------------------**------------------------------**
>> --------------------
>>
>>
>> ______________________________**_________________
>> Blindmath mailing list
>> Blindmath at nfbnet.org
>> http://nfbnet.org/mailman/**listinfo/blindmath_nfbnet.org<http://nfbnet.org/mailman/listinfo/blindmath_nfbnet.org>
>> To unsubscribe, change your list options or get your account info for
>> Blindmath:
>>
>> http://nfbnet.org/mailman/**options/blindmath_nfbnet.org/**
>> pdonahue2%40satx.rr.com<http://nfbnet.org/mailman/options/blindmath_nfbnet.org/pdonahue2%40satx.rr.com>
>>
>>
>> ______________________________**_________________
>> Blindmath mailing list
>> Blindmath at nfbnet.org
>> http://nfbnet.org/mailman/**listinfo/blindmath_nfbnet.org<http://nfbnet.org/mailman/listinfo/blindmath_nfbnet.org>
>> To unsubscribe, change your list options or get your account info for
>> Blindmath:
>>
>> http://nfbnet.org/mailman/**options/blindmath_nfbnet.org/**
>> baldwin%40dickbaldwin.com<http://nfbnet.org/mailman/options/blindmath_nfbnet.org/baldwin%40dickbaldwin.com>
>>
>>
>
>
> --
> Richard G. Baldwin (Dick Baldwin)
> Home of Baldwin's on-line Java Tutorials
> http://www.DickBaldwin.com
>
> Professor of Computer Information Technology
> Austin Community College
> (512) 223-4758
> mailto:Baldwin at DickBaldwin.com
> http://www.austincc.edu/**baldwin/ <http://www.austincc.edu/baldwin/>
> ______________________________**_________________
> Blindmath mailing list
> Blindmath at nfbnet.org
> http://nfbnet.org/mailman/**listinfo/blindmath_nfbnet.org<http://nfbnet.org/mailman/listinfo/blindmath_nfbnet.org>
> To unsubscribe, change your list options or get your account info for
> Blindmath:
> http://nfbnet.org/mailman/**options/blindmath_nfbnet.org/**
> mwhapples%40aim.com<http://nfbnet.org/mailman/options/blindmath_nfbnet.org/mwhapples%40aim.com>
>
> ______________________________**_________________
> Blindmath mailing list
> Blindmath at nfbnet.org
> http://nfbnet.org/mailman/**listinfo/blindmath_nfbnet.org<http://nfbnet.org/mailman/listinfo/blindmath_nfbnet.org>
> To unsubscribe, change your list options or get your account info for
> Blindmath:
> http://nfbnet.org/mailman/**options/blindmath_nfbnet.org/**
> baldwin%40dickbaldwin.com<http://nfbnet.org/mailman/options/blindmath_nfbnet.org/baldwin%40dickbaldwin.com>
>

-- 
Richard G. Baldwin (Dick Baldwin)
Home of Baldwin's on-line Java Tutorials
http://www.DickBaldwin.com

Professor of Computer Information Technology
Austin Community College
(512) 223-4758
mailto:Baldwin at DickBaldwin.com
http://www.austincc.edu/baldwin/