Daily Archives: March 22, 2022

Losing the tiny peak

Methods to assess TEM and AFM images, surfactant proteins A and D

It seems likely that one of the reasons that the tiny peaks on either side of the N termini junction of a surfactant protein D dodecamer when employing signal processing is that with the enormity of the N termini peak the requirements for an adjacent peak are too great.  I think in some kinds of image processing this might also be a factor, maybe those which “sharpen” in particular, but it surely must happen in some comperable fashion.  I really noticed it more in the signal processing algorithms than image processing.

Also missing is the splitting of the N termini junction peak into two (sometimes with a very small peak in the center) using the signal processing algorhythms. Maybe for similar reasons.

It is a little distressing to watch the signal processing algorithms continually pass over a peak that I have seen many times in many molecules, and then say there are 4 peaks in a short span ot distance where there are literally “no peaks to be seen”.

Verge of a Dream: Let questions go unanswered

Prose and Poems
With you, inside,
from the pachysandra,
a barrage of deep green
and cheering white, soothing
And electrifying
protecting ardor from thought.
On the cast bench,
all debts paid,
drawn back to the boxwoods
aside the
crushed stone path
A smokey whiskey
and black poplar parasol
matching the thick sky,
no contemplation only
an industrial puff in the air
left
From the end of work days
facing a bellowing fire
miles to the east.
Let questions go unanswered,
I wonder if there is anyone
with the confidence
To fill in what you think

RLB 03-22-2022

With all due respect for Octave (Matlab)

Methods to assess TEM and AFM images

With all due respect for Octave it becomes clear that the output graphics of the peak finding programs (ipeak; findpeaksplot; autopeaksplot; findpeaksplot; etc, and even some excel templates for finding peaks, have little to do with what can be used graphically to show results in a publication-ready manner. Peak symbols are big and clumsy, peak locations are offset to a degree that they can’t be used to illustrate parameters gathered, like peak width, height and area.  You have created a very cumbersome application for those who are interested in visualizing microscopic data.  I know you guys are total genius in writing algorithms, … but not in creating presentable graphics, and its OK,  just like I am not genius in signal processing, but more capable in graphics.

My recommendation is that you hire (or train, or associate with) someone who can walk you through design, graphics, and scientific illustration.  That may sound negative but it is not. It is a legitimate recommendation and an offer to help. Just like i need help with Octave, you all need help with scientific illustration methods.

Just as one example, output to csv and import into excel or a vector graphics program (like CorelDRAW) is totally cumbersome, and we all know already that for 30 years excel has been unfriendly with their output for publication graphics. Octave takes this to a new and outstanding level of  unnecessary lines and objects.

If Octave is a freebie of Matlab, and the programs are largely interchangeable, then Matlab has the same problem.