gwyddion-devel Mailing List for Gwyddion (Page 3)

On Mon, Aug 01, 2022 at 03:22:04PM +0200, Milan Pavuk wrote:
> I would like to report an issue I have observed when working with Gwyddion 2.61:
> 
> When you 
> 1. open an image in Gwyddion, then 
> 2. click the button that brings up the "Color Range" window, 
> 3. you close it afterwards, 
> 4. use the "Data Process>Basic Operations>Limit Range" function 
> 5. and then bring up the "Color Range" window again, 
> 
> the "Data Range" in this window is not updated (does not reflect the
> changes made by the 'Limit Range' function). However, it is updated if
> the "Statistical quantities" button is clicked after using the "Limit
> Range" function or when the image is saved and reloaded.

Thanks for the report. The tool was not updating the full range labels
when data had changed. It should be fixed in r24862.

The behaviour of the numeric entries for the range is still somewhat
different when the tool remains active while you modify the data vs.
when you switch to it anew. But this is basically because it can't read
your mind when you both change the data and manually set the colour
mapping range.

Regards,

Yeti

Hello,

I would like to report an issue I have observed when working with Gwyddion 2.61:

When you 
1. open an image in Gwyddion, then 
2. click the button that brings up the "Color Range" window, 
3. you close it afterwards, 
4. use the "Data Process>Basic Operations>Limit Range" function 
5. and then bring up the "Color Range" window again, 

the "Data Range" in this window is not updated (does not reflect the changes made by the 'Limit Range' function). However, it is updated if the "Statistical quantities" button is clicked after using the "Limit Range" function or when the image is saved and reloaded.

Another interesting observation is that if you choose the same procedure as described in the first sentence with the only difference that you do not open the "Color Range" window after opening the image, then the "Data Range" in the "Color Range" window will be updated at the end.

-- 
Best regards,
 Milan

On Mon, May 09, 2022 at 07:05:03AM +0000, 이종선(Jong Seon Lee)[skywalker16] wrote:
> It's my first time using this site, and I have some questions regarding the
> Modularity. (Plug-ins)
> 
> Could someone help me out?

Possibly. No one knows yet what the questions are. Just ask them.

> I can post a comment on other people's questions but I can't seem to make a new
> one to ask questions.

If you are not logged in the forums says

    Log in to post a comment.

in place of the comment box. If you can post you just need to click on
‘Create topic’.

Regards,

Yeti

I've subscribed to the sourceforge site, but can't write a new topic on it.

So I send it by mail.





It's my first time using this site, and I have some questions regarding the Modularity. (Plug-ins)



Could someone help me out?



I can post a comment on other people's questions but I can't seem to make a new one to ask questions.



Thanks in advance!




________________________________

[http://www.lgchem.com/images/etc/LGensol_logo.png]

[http://www.lgchem.com/images/etc/customerService_new_ko.png]<" rel="nofollow">https://www.lgensol.com/kr/customerInconvenience> [http://www.lgchem.com/images/etc/customerService_new_en.png] <" rel="nofollow">https://www.lgensol.com/en/customerInconvenience>  [http://www.lgchem.com/images/etc/customerService_new_zh.png] <" rel="nofollow">https://www.lgensol.com/cn/customerInconvenience>
________________________________

본 메일 및 첨부파일은 발신자 및 수신자에게만 공개된 내용이며 기밀사항 또는 법적으로 제한되거나 저작권 관련 내용이 포함되어 있을 수 있습니다. 본 메일 및 첨부파일을 무단으로 열람, 복사, 활용, 배포하는 행위는 금지되어 있습니다. 만약 본 메일의 해당 수신자가 아니거나 오류로 전송받았을 경우, 즉시 발신자에게 회신하고 관련 메일을 모두 삭제해 주시기 바랍니다.

The contents of this e-mail message and any attachments are intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is proprietary, privileged or confidential or otherwise legally exempt from disclosure. If you are not the named addressee, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please notify the sender immediately by e-mail and delete all copies of the message.

本邮件及附件只向来信者及收件人公开，可能受到机密事项或法律限制，或包含著作权相关内容。 禁止擅自阅览、复制、使用、分发本邮件的行为。 如非本邮件相应收件人或收到错误邮件，请立即回复来信者，并删除所有相关邮件。

On Mon, May 02, 2022 at 11:17:27AM +0200, David Nečas (Yeti) wrote:
> Gwyddion 2.61 is now available for download…

…and the actual list of changes in 2.61 follows. Sorry about posting the
2.60 news instead.

Application:
- Translations updated: Czech, French, Russian.
- Command line: New option --convert-to-gwy merges and converts SPM files to
  the Gwyddion file format.
- Command line: Non-GUI operations --identify, --check and --convert-to-gwy
  avoid more carefully GUI initialisation code, fixing some warnings.

Libraries:
- libgwyddion: gwy_check_regular_2d_grid() gives better offsets and steps.
- libgwyddion: GwySIUnit parser handles better Unicode powers like 10³ or m².
- libgwyddion: New gwy_math_curvature_at_origin() curvature function.
- libgwyprocess: GwyLawn deserialisation segment data size check was fixed.
- libgwyprocess: Elliptic area extraction and unextraction, broken in 2.59,
  work correctly again.  This fixes intersection with an elliptic area in Mask
  Editor tool.
- libgwyprocess: Rectangular pyramid shape fitting preset was added.
- libgwyprocess: Shape fitting preset parameters can have descriptions.
- libgwyprocess: gwy_data_field_row_gaussian() no longer limits kernel size
  using the vertical resolution.
- libgwyprocess: Function for changing the number of GwySurface points without
  immediately filling it with new data.
- libgwyprocess: A Zoom FFT function was added for GwyDataLine.
- libgwyprocess: New function for a linear combination of two GwyDataLines.
- libgwyprocess: GwyPeaks should no longer produce NaN peak widths for odd
  peak shapes.
- libgwydgets: Gwy3DView draws correctly the false colour axis for inverted
  gradients and follows better mapping changes made in the false colour tool.
- libgwydgets: gwy_color_axis_set_unit() invokes a redraw even if the same
  object is set again.
- libgwydgets, libgwyapp: GtkTooltips functions were deprecated (use the simple
  GtkWidget functions instead).
- libgwyapp: Incorrect warning about the default value in
  gwy_param_def_add_string() was fixed.
- libgwyapp: Crash in GwyParamTable radio button row construction was fixed.
- libgwyapp: gwy_param_table_reset() no longer tries to reset foreign controls.
- libgwyapp: New predefined parameter type for a set of grain value groups.
- libgwyapp: A helper function for adding a vector layer to a preview.

Modules:
- Nova ASCII (new): Imports NT-MDT Nova exported ASCII data.
- Indentor analyze: Completely rewritten, with useless quantities removed,
  useful added and region marking improved.
- Dimensions and Units: Bug sometimes causing it to forget the dimensions mode
  was fixed.  For Set range and Correct by factor the unit is remembered in
  settings.
- Graph Flip, Graph FZ to FD: Output data order which was causing problems in
  subsequent processing was fixed.
- Corning: Import of Corning Tropel UltraSort TTF files works now too.
- Nanonics: Raw data conversion factors were improved; some data may still be
  imported wrong.
- Nanoscope: Single force curve rebasing was made more robust.
- Curve Map Nanomechanical Fit, Fit FD Curve: Miscellaneous model improvements.
- GwyTIFF: Byte counts and offsets are read correctly when of type short.
- WRUST: Support for Liczba Kolumn parameter was added. Extra empty lines in
  header are ignored.
- 3D formats: Fixed import of STL files which was reading only some points and
  some multiple times.
- Anfatec: Also imports FV matrix data (as curve maps).  Metadata are created
  from the header file.
- Pixmap, HDR image: Option to simply use the pixel dimensions as the lateral
  dimensions was added.
- Wrap value: Option to keep the current data range unchanged was added.
- Grain correlations: Quantities available for abscissa are updated correctly
  when it is calculated from a different image.
- Measure lattice: Masking support was added.  Vector numbers can be displayed.
  The FFT image is refined.
- Tip model: Can enforce square tip image.
- Fit Shape: Pressing OK again consistently produces output images, whether
  they originate from fitting or just setting parameters manually.  Most
  parameters have toolips with descriptions.
- Perspective correction: Correction can be applied to all compatible images
  and it can modify the current image (instead of creating a new one).
- Projective selection: Supports crop and move and can be distributed by the
  selection manager tool.

Yeti

Gwyddion 2.61 is now available for download at

  https://sourceforge.net/projects/gwyddion/files/gwyddion/2.61/
  (all released files)

  http://gwyddion.net/download/2.61/
  (source code)

Released files are signed with PGP/GnuPG key

  "David Nečas (Yeti) <ye...@gw...>", id 62A07732
  fingerprint = 263F 9B1E C1E0 5261 C689  D83B 00FD D1D0 62A0 7732

-----------------------------------------------------------------------------

This is a stable version continuing the 2.x series, backward compatible with
previous 2.x versions.

More information about Gwyddion is available at

  http://gwyddion.net/

Bugs should be reported to

  kla...@gw...

the mailing list, or the project's web forum at SourceForge.

-----------------------------------------------------------------------------

Summary of changes:
Application:
- Translations updated: Brazilian Portugese, Czech, French, Russian.
- Toolbox editor: Possible crash when adding a new group was fixed.

Libraries:
- libgwyddion: New functions available in GwyExpr: step, spow (signed pow),
  exp2, log2, sinc.  If the system math library provides them, the following
  are also available: erf, erfc, lGamma, Gamma, J0, J1, Y0, Y1.
- libgwyddion: gwy_sinc function was added for the cardinal sine function.
- libgwyddion: New GwyResource methods for resource deleting and renaming,
  including corresponding on-disk operations.
- libgwyddion: Function for decomposing GwySIUnit to base units was added.
  More degree variants and a few other odd units are recognised.
- libgwyddion: One-dimensional minimum search function was added.
- libgwyprocess: Functions for magnetic force microscopy data modelling and
  handling were added.
- libgwyprocess: New tip model, ball at the end of cylinder, was added.
- libgwyprocess: New GwyBrick functions: copy, transposition, compatibility
  checking, setting a plane.
- libgwyprocess: Speed of various GwyBrick summary operations such as
  gwy_brick_mean_plane() was considerably improved.
- libgwyprocess: Function for bounding boxes of periodic grains was added.
- libgwyprocess: RMS grain quantity was added.
- libgwyprocess: Simple regularised deconvolution function was added.
- libgwyprocess: New k-th rank filter with arbitrarily shaped kernel function.
- libgwyprocess: New function for calculation of 2D PSDF from masked data.
- libgwydgets: Helper functions for managing a group of check boxes which
  correspond to a set of bit flags (gwycheckboxes) were added.
- libgwydgets: GwyGraphModel has new functions for deriving units from a
  GwyDataField and replacing a curve model at given index.
- libgwyapp: Helper functions for managing module data in the user directory.
- libgwyapp: Failed assertion message when restoring file open dialogue file
  name filter from settings was corrected.
- libgwyapp: Critical warning when deleting XYZ data channel was fixed.

Modules:
- Ambios profile (new): Imports 1D profilometry data (both XML and DAT).
- Volume ASCII export (new): Export of volume data to various text formats.
- Volume Arithmetic (new): Arithmetic operations with volume data.
- Volume summarize planes (new): Plots graphs of dependencies of volume data
  plane statistics over z.
- Volume stray field (new): Checks consistency of volume MFM data.
- Volume and image MFM recalculation (new): Converts MFM data to force
  gradient.
- Volume transfer function (new): Plane-by-plane estimation of point spread
  functions in volume data planes corresponding to different levels.
- Area function (new): Calculates the tip area function.
- Hertz (new): Calculates the apparent Young's modulus of a rough surface
  according to Hertzian contact theory.
- Phoenix (new): Imports AFM data files from NASA Phoenix Mars mission.
- Disc synthesis (new): Generates surface randomly covered by discs or tiles.
- XYZ Channels (new): Create XYZ data from three images (values and precise
  X and Y coordinates).
- DM3: Raw data are no longer scaled by inverse maximum representable value.
- Coerce: Skew-normal distribution was added.
- Volume Show and Extract: Cleanup; functions superseded by Cut'n'Slice were
  removed, visualisation and stability improved.
- MFM modules: Cleanup; a few wrong numerical factors were corrected.
- Volume Z calibration: Calibration can be also taken from another volume data.
- Volume Swap Axes: Preview image units correspond to the transformed data.
- NMM file: Sometimes incorrect import when a only subset of channels is
  selected was fixed.
- NRRD file: Import from text-encoded files was corrected.  Endian is no longer
  required for text data.
- PNI file: Support for v2.0 files was added, at least for a subset of data
  types.
- Volume slice: Mislabelled axes on output graphs were corrected.
- Transfer function (PSF) guess and fit: The set of output images can be
  controlled
- Transfer function fit: Frequency-space exponential model was added.
- Transfer function guess: The sigma estimation algorithm was improved.
- Nanoscope: Force volume file reading was standardised to follow format
  specification.
- WSxM: File headers with ‘UAM’ copyright are recognised.
- Nanonis DAT spectra: All files matching the same fooNNN.dat pattern are
  merged, not just with names starting from 1.  When files do not seem
  numbered at all, the single selected file is loaded instead of failing.
- Basic operations: Function for flipping around the diagonal was added.
- Pattern synthesis: Holes are placed with respect to image centre instead
  of some defined but unhelpful origin of coordinates.  This means generated
  images also changed and match previous versions only statistically.
- Graph logscale: Logarithm base mishandling was fixed.  Base-2 logarithm and
  negative abscissa handling options were added.
- Statistics Quantities: Volume was added as a new quantity.
- FFT profile: Renamed to 2D PSDF.  It can now both extract profiles and create
  the entire 2D PSDF image.
- Image export: Font selection having sometimes no effect on the exported
  image was, hopefully, fixed.  It no longer crashes when there is no image
  to export.
- Filters tool: The median filter now uses circular kernel.
- 2D ACF: Creation of the output image is optional.  The image can be limited
  to the zoomed part.
- Volume summarize profiles: The value for the currently selected profile is
  displayed in the dialogue.
- Dimensions and Units: Crash when reinvoked after selecting Match pixel size
  was fixed.
- Pygwy: Function gwy_app_data_browser_get_containers() no longer leaks
  references to all the returned Containers.  GraphModel supports the sequence
  protocol.

Other:
- Compilation: pygobject2 codegen is no longer required to build pygwy; an
  embedded implementation is used when it is not available.
- Compilation: autogen.sh no longer gets stuck without gettextize; it prints
  an error message.

-----------------------------------------------------------------------------

Thanks all who contributed,

Yeti

On Thu, Apr 14, 2022 at 01:59:49PM +0200, David Nečas (Yeti) wrote:
> …publish 2.61 relatively soon, hopefully by end of April (or so).

I'm not going to rush it today, so Monday should be the date.

Regards,

Yeti

On Sat, Apr 23, 2022 at 06:44:30PM +0400, Daniil Bratashov wrote:
> I also see that http://gwyddion.net/download/test/gwyddion.pot was not
> updated for a while, so the translation is based on a quite old
> version of this file.

Good catch. A rpm part of the night rebuild was failing since I upgraded
the OS by a couple of versions, but I haven't noticed. Should be fixed
by tomorrow's build.

Regards,

Yeti

I also see that http://gwyddion.net/download/test/gwyddion.pot was not
updated for a while, so the translation is based on a quite old
version of this file.

WBR, Daniil Bratashov.

On Sat, Apr 23, 2022 at 10:13 AM David Nečas (Yeti) <ye...@gw...> wrote:
>
> On Sat, Apr 23, 2022 at 07:44:25AM +0400, Daniil Bratashov wrote:
> > It looks like it is better to disable it for release and after the
> > release I will enable and finish it (I hope).
>
> OK, thanks for the info.
>
> Regards,
>
> Yeti
>
>

On Sat, Apr 23, 2022 at 07:44:25AM +0400, Daniil Bratashov wrote:
> It looks like it is better to disable it for release and after the
> release I will enable and finish it (I hope).

OK, thanks for the info.

Regards,

Yeti

It looks like it is better to disable it for release and after the
release I will enable and finish it (I hope).

WBR, Daniil Bratashov.

On Thu, Apr 14, 2022 at 6:12 PM Daniil Bratashov <dn...@gm...> wrote:
>
> If I left modules/file/zeissczi.c unfinished some time before the
> release, then it can be disabled for release. I hope I will find time
> to finish it, i have good specs for the format, some understanding how
> it is organized, but need about two free days with code to finish
> basic loading.
>
> WBR, Daniil Bratashov.
>
> On Thu, Apr 14, 2022 at 4:19 PM David Nečas (Yeti) <ye...@gw...> wrote:
> >
> >
> > Hello all,
> >
> > it has been a long time since the last stable version release.  I would
> > like to publish 2.61 relatively soon, hopefully by end of April (or so).
> > We should check more thoroughly MS Windows packages but otherwise things
> > should be in a reasonably good shape.
> >
> > Daniil, I do not see much progress in modules/file/zeissczi.c so I guess
> > it should be disabled for the release, right?
> >
> > Regards,
> >
> > Yeti
> >
> >

If I left modules/file/zeissczi.c unfinished some time before the
release, then it can be disabled for release. I hope I will find time
to finish it, i have good specs for the format, some understanding how
it is organized, but need about two free days with code to finish
basic loading.

WBR, Daniil Bratashov.

On Thu, Apr 14, 2022 at 4:19 PM David Nečas (Yeti) <ye...@gw...> wrote:
>
>
> Hello all,
>
> it has been a long time since the last stable version release.  I would
> like to publish 2.61 relatively soon, hopefully by end of April (or so).
> We should check more thoroughly MS Windows packages but otherwise things
> should be in a reasonably good shape.
>
> Daniil, I do not see much progress in modules/file/zeissczi.c so I guess
> it should be disabled for the release, right?
>
> Regards,
>
> Yeti
>
>

Hello all,

it has been a long time since the last stable version release.  I would
like to publish 2.61 relatively soon, hopefully by end of April (or so).
We should check more thoroughly MS Windows packages but otherwise things
should be in a reasonably good shape.

Daniil, I do not see much progress in modules/file/zeissczi.c so I guess
it should be disabled for the release, right?

Regards,

Yeti

On Mon, Feb 28, 2022 at 03:42:25PM +0100, Milan Pavuk wrote:
> The ruler will end with the new maximum that I entered in the "Color
> Range" window.  However, if the range did not change, this ruler
> should not have been shortened. Only the gradient should have changed.
> The color of the protrusion in the palette should start at the new
> maximum and continue to the original maximum. Then, if I looked at
> such a palette, I would conclude that the overall height range (data)
> had not changed.

OK, I see now where you are coming from.  Sometimes this would be indeed
a useful visualisation of the mapping – other times it would make the
part where colours are actually changing too short and kind of
pointless.

Regards,

Yeti

Hello,

Monday, February 28, 2022, 2:25:48 PM, you wrote:

> On Sat, Feb 26, 2022 at 01:53:44PM +0100, Milan Pavuk wrote:

> Why?  Most other software I know allows one to set the false colour
> range to something else than [data_minimum, data_maximum].  Why do you
> expect the Gwyddion colour range mapping tool to physically modify the
> data?

> I will relabel the controls, but I still do not understand your mental
> model of the tool and how you arrived at it.

My mental model is based on what I see. Back to my image with one protrusion significantly higher than the rest where I can demonstrate my perception of working with palette and height. If I reduce the maximum in the "Color Range" window, the protrusion in the image will be drawn in one color. If I showed you this image you would not be able to tell from it how tall this protrusion is. Unless I extract the height profile across the protrusion, it is not possible to say whether the height was limited from the top or not. This is because using the "Limit Range" function and the "Color Range" window leads to the same result - the same image and the same palette. The real difference between the two functions, however, is that reducing the maximum through the "Color Range" window does not change the overall range of the image. The problem, however, is that while the range of the palette has not changed, Gwyddion shortens the ruler next to the image (when changing range in Color Range window). The ruler will end with the new maximum that I entered in the "Color Range" window. However, if the range did not change, this ruler should not have been shortened. Only the gradient should have changed. The color of the protrusion in the palette should start at the new maximum and continue to the original maximum. Then, if I looked at such a palette, I would conclude that the overall height range (data) had not changed.

Furthermore, I do not claim that the image should be cropped (limited in data range) when changing the palette. On the contrary, it is good if the original data does not change. I was just suggesting that there may be a lack of clarity about the "Color Range" window. I also understand why the ruler shortens when changing the minimum and maximum in the "Color Range" window. I think that is to leave enough room to show the rest of the gradient which is more important than the limits.

To conclude, I am happy with Gwyddion as it is now, but also as if the minimum and maximum in the "Color Range" window were renamed. However, I do not want to push my personal opinion (I am only one person), so I will leave this decision to you (and others) who are actually developing this application.


Regards,
Milan

On Sat, Feb 26, 2022 at 01:53:44PM +0100, Milan Pavuk wrote:
> But since the maximum has been reduced, I assume that all pixels
> higher than the new maximum value have been replaced by the new
> maximum (because that is what I see in the image).

Why?  Most other software I know allows one to set the false colour
range to something else than [data_minimum, data_maximum].  Why do you
expect the Gwyddion colour range mapping tool to physically modify the
data?

Furthermore, you can freely shorten and expand the range.  If you
interpret shortening the range as physically replacing too small and
too large values:
- How do you interpret that they reappear when you extend the range
  back to full – shouldn't they be irretrievably lost?
- How do you interpret the histogram which still corresponds to
  unmodified data?
- Changing the colour range does not create a new image – if there is
  just one image, does it contain the modified or original data?
- Whichever you answer to the previous point, where do the other data
  exist then?
- Do you interpret also the other mapping modes (auto cut-off,
  non-linear) as physical data modification?
I will relabel the controls, but I still do not understand your mental
model of the tool and how you arrived at it.

Yeti

Hi Milan,

I wouldn't be too quick to generalize your expectation to that of the general user. I work with many users, novices and experts alike, and I can't recall that anyone expected the data to be cropped when changing the color range. If you take a profile, and change the range of the y axis, do you expect the data to be altered? I don't. Similarly, I don't expect the data to be altered when I change the minimum and maximum of the color range. 
Not that I seriously object to changing 'minimum' and 'maximum' to 'start' and 'end', but I don't see a need for it. The color range is just that: the range of the colors. Not the range of the data.

Best regards, Allard Katan

-----Original Message-----
From: Milan Pavuk <mil...@st...> 
Sent: zaterdag 26 februari 2022 13:54
To: Gwyddion development discussion <gwy...@li...>
Subject: Re: [Gwyddion-devel] 3D View bug

Hi Yeti,

Saturday, February 26, 2022, 11:23:55 AM, you wrote:

> On Sat, Feb 26, 2022 at 10:16:57AM +0100, Milan Pavuk wrote:

> What we do is simpler:  Value z₀ maps to the beginning of the 
> gradient, value z₁ to the end.  Between it is linearly interpolated; 
> outisde it is extrapolated by the endpoint values.  Inverting the 
> mapping simply means
z₀ >> z₁ instead of the more usual z₀ < z₁.

> Values z₀ and z₁ is what you enter there when you set the colour 
> mapping range manually.

Now I understand the "Color Range" window better. It should be noted that for the average user, there is a mismatch between this window and the palette next to the image. Let us imagine I have an image of height from an AFM microscope. I have several protrusions (grains) on the surface of a sample, but one is significantly higher than the others. Therefore, when displaying the full height range, the entire palette is used to draw this high protrusion. There are virtually no colors left in the palette to draw the details of the smaller protrusions. Therefore, if I want to see the smaller protrusions whose representation is the largest on the surface, then I must cut the pallet from the top. I open the "Color Range" window and lower the maximum value. Suddenly, smaller protrusions also appear in the image. At the same time, however, I will not be able to say from the image what the height of the tallest protrusion is, because its top will be drawn in only one color (the last one in the palette). And that is something to be expected. But since the maximum has been reduced, I assume that all pixels higher than the new maximum value have been replaced by the new maximum (because that is what I see in the image). However, when I extract the profile of the topography across the high protrusion, I see that the height was not actually cropped. This is something one does not expect. The whole problem is that in the "Color Range" window I have a histogram of the height (which is directly related to the sample) and the range is set just below it. But it is not the range of data, but the range of the color palette. The change you are proposing - rewrite "minimum" to "start" and the "maximum" to "end" is quite a good solution, because it will not give the impression that I am changing the range of the data. Another option would be to replace the word "Range" with the word "Color Mapping" and leave the word minimum and maximum as input box names. But your proposal seems to me to be better. This seems like a minimal change, but it completely changes the way this window is understood.

Thank you for discussing this topic.

Regards,
Milan

Hi Yeti,

Saturday, February 26, 2022, 11:23:55 AM, you wrote:

> On Sat, Feb 26, 2022 at 10:16:57AM +0100, Milan Pavuk wrote:

> What we do is simpler:  Value z₀ maps to the beginning of the gradient,
> value z₁ to the end.  Between it is linearly interpolated; outisde it is
> extrapolated by the endpoint values.  Inverting the mapping simply means
z₀ >> z₁ instead of the more usual z₀ < z₁.

> Values z₀ and z₁ is what you enter there when you set the colour mapping
> range manually.

Now I understand the "Color Range" window better. It should be noted that for the average user, there is a mismatch between this window and the palette next to the image. Let us imagine I have an image of height from an AFM microscope. I have several protrusions (grains) on the surface of a sample, but one is significantly higher than the others. Therefore, when displaying the full height range, the entire palette is used to draw this high protrusion. There are virtually no colors left in the palette to draw the details of the smaller protrusions. Therefore, if I want to see the smaller protrusions whose representation is the largest on the surface, then I must cut the pallet from the top. I open the "Color Range" window and lower the maximum value. Suddenly, smaller protrusions also appear in the image. At the same time, however, I will not be able to say from the image what the height of the tallest protrusion is, because its top will be drawn in only one color (the last one in the palette). And that is something to be expected. But since the maximum has been reduced, I assume that all pixels higher than the new maximum value have been replaced by the new maximum (because that is what I see in the image). However, when I extract the profile of the topography across the high protrusion, I see that the height was not actually cropped. This is something one does not expect. The whole problem is that in the "Color Range" window I have a histogram of the height (which is directly related to the sample) and the range is set just below it. But it is not the range of data, but the range of the color palette. The change you are proposing - rewrite "minimum" to "start" and the "maximum" to "end" is quite a good solution, because it will not give the impression that I am changing the range of the data. Another option would be to replace the word "Range" with the word "Color Mapping" and leave the word minimum and maximum as input box names. But your proposal seems to me to be better. This seems like a minimal change, but it completely changes the way this window is understood.

Thank you for discussing this topic.

Regards,
Milan

On Sat, Feb 26, 2022 at 10:16:57AM +0100, Milan Pavuk wrote:
> > So, essentially you complain that “Minimum” and “Maximum” in the colour
> 
> I am not complaining, I am just discussing with you.

You are clearly unhappy with something – otherwise we wouldn't have this
discussion.  Call it whatever you want.  Complain is basically a neutral
word for it.  I complain all the time – and grumble even more…

> My idea of color inversion is that the new color position is
> calculated as: abs(currentPosition - 1). So the whole pallete is
> mirror-inverted.

This is possible, but adds a whole new way how the gradient can be is
used, which needs to exist as a separate option.

What we do is simpler:  Value z₀ maps to the beginning of the gradient,
value z₁ to the end.  Between it is linearly interpolated; outisde it is
extrapolated by the endpoint values.  Inverting the mapping simply means
z₀ > z₁ instead of the more usual z₀ < z₁.

Values z₀ and z₁ is what you enter there when you set the colour mapping
range manually.

> However, what I do not understand is why after clicking the "Invert
> Mapping" button in the "Color Range" window, the numeric value of the
> minimum determined from the data is replaced by the maximum, and vice
> versa, the maximum is replaced by the minimum.

Where?  The colours bars in both 2D and 3D views have the lower value at
the bottom and the higher value at the top, no matter what you do (and
anyway they display the colour mapping, not the data range).  The data
range is in the colour range tool displayed under “Full” – and that
never changes.

The only thing that changes is the values under “Range”.  If you want
z₀ > z₁ then this is how they have to be entered there.  They should
just be labelled more clearly like “Start” and “End”.

Button “Invert Mapping” is not an option you can select.  It is a button
so it does something.  It swaps the endpoints z₀ and z₁, reversing the
mapping (whatever it currently is).

Yeti

Hi Yeti,

Saturday, February 26, 2022, 8:45:08 AM, you wrote:

> So, essentially you complain that “Minimum” and “Maximum” in the colour

I am not complaining, I am just discussing with you. I like Gwyddion. At the same time, it is a complex application, so some of its behavior may not be completely clear to the user.

> range tool should be called “Start” and “End” (or something like that),
> because they are properties of colour mapping, not data minimum and
> maximum.  That can be done.

I guess so.

> “Invert colours” is nonsense.  It would mean replacing colour
> (r,g,b) with (1-r,1-g,1-b), and that is definitiely not what “Invert
> mapping”.  It reverses the colour mapping.

My mistake, I did not mean the classic color inverting that graphic editors do, but flipping the palette. If I remember correctly, in Gwyddion the color gradient is defined this way: Each color in the palette has a defined position in the palette (a number from 0 to 1) and its RGB value (divided by 255 so that the value is normalized to 1). My idea of ​​color inversion is that the new color position is calculated as: abs(currentPosition - 1). So the whole pallet is mirror-inverted. For example, if the black color was at position 0.25, after the mirror flipping it will be at position 0.75. Since only the palette and not the data itself changes, the numerical value of the data minimum and the data maximum would not change. I think this is exactly what Gwyddion does. However, what I do not understand is why after clicking the "Invert Mapping" button in the "Color Range" window, the numeric value of the minimum determined from the data is replaced by the maximum, and vice versa, the maximum is replaced by the minimum. I do not think they should change. But I can be wrong. In my opinion, the minimum and maximum have not changed. What has changed is just the color palette.

Regards,
Milan

On Fri, Feb 25, 2022 at 09:37:06PM +0100, Milan Pavuk wrote:
> I personally do not have any negative experience with the current
> 2D/3D view logic. But what seems a little strange to me is how the
> Invert Mapping button in the Color Range window works. When you click
> this button, the numeric values of the minimum and maximum
> are reversed. However, the color ruler next to the image does not
> change in the same way. The value of the minimum and maximum will not
> change in it. Only the color palette flips. But as a result, that is
> what I wanted - to have an inverted palette. If the purpose of the
> "Invert Mapping" button is to invert the color palette, it would be
> easier to replace this button with a check box. Rename it to "Invert
> Colors" and do not shuffle the minimum with the maximum (neither in
> this window nor in the image palette). It would be much easier to
> understand. To make this button useful, the logical state of the check
> box should be remembered for each image (in Data Browser). Other color
> palettes (accessible via the right mouse button after clicking on the
> current palette) should be rendered based on this check box.
> If, on the other hand, the goal of the "Invert Mapping" button should
> be to swap the minimum with the maximum, then I think the existing
> function "Data Process > Basic Operations > Invert Value" is
> sufficient. Therefore, I rather suggest the check box (invert colors).

So, essentially you complain that “Minimum” and “Maximum” in the colour
range tool should be called “Start” and “End” (or something like that),
because they are properties of colour mapping, not data minimum and
maximum.  That can be done.

“Invert colours” is nonsense.  It would mean replacing colour
(r,g,b) with (1-r,1-g,1-b), and that is definitiely not what “Invert
mapping”.  It reverses the colour mapping.

Yeti

Hi Yeti,

Friday, February 25, 2022, 4:40:00 PM, you wrote:

> On Wed, Feb 16, 2022 at 10:25:08AM +0100, Milan Pavuk wrote:
>> problem description: In the 3D View no color bar is show when Invert
>> Mapping was set in the Color Range window (ie the value of Minimum is
>> lower than the value of Maximum).

For the record, I made a typo in describing this problem. The end of the description should be like this: (ie the value of minimum is HIGHER than the value of maximum).

> I should be fixed in r24619.

Thank you.

> The logic of how (or when) 3D view should follow changes in the normal image window is somewhat muddled though.

I personally do not have any negative experience with the current 2D/3D view logic. But what seems a little strange to me is how the Invert Mapping button in the Color Range window works. When you click this button, the numeric values ​​of the minimum and maximum are reversed. However, the color ruler next to the image does not change in the same way. The value of the minimum and maximum will not change in it. Only the color palette flips. But as a result, that is what I wanted - to have an inverted palette. If the purpose of the "Invert Mapping" button is to invert the color palette, it would be easier to replace this button with a check box. Rename it to "Invert Colors" and do not shuffle the minimum with the maximum (neither in this window nor in the image palette). It would be much easier to understand. To make this button useful, the logical state of the check box should be remembered for each image (in Data Browser). Other color palettes (accessible via the right mouse button after clicking on the current palette) should be rendered based on this check box.
If, on the other hand, the goal of the "Invert Mapping" button should be to swap the minimum with the maximum, then I think the existing function "Data Process > Basic Operations > Invert Value" is sufficient. Therefore, I rather suggest the check box (invert colors).

>> one feature request: Would it be possible to automatically attach file
>> extension when saving an image in 3D View?

> It works the other way round:  You type .png and it saves a PNG.  You
> type .tiff and it saves a TIFF.  The same for JPEG.

I thought the image could only be saved in PNG format. I thought so because if one does not write the file extension, the file that will be saved is actually a PNG image without a file extension. I can imagine that it would be clearer and more intuitive for the average user if there was a drop-down menu with a list of supported formats when saving the file, and also that the file extension was attached automatically. But that is just my opinion.

Have a nice weekend.

Regards,
Milan

On Wed, Feb 16, 2022 at 10:25:08AM +0100, Milan Pavuk wrote:
> problem description: In the 3D View no color bar is show when Invert
> Mapping was set in the Color Range window (ie the value of Minimum is
> lower than the value of Maximum).

I should be fixed in r24619.  The logic of how (or when) 3D view should
follow changes in the normal image window is somewhat muddled though.

> one feature request: Would it be possible to automatically attach file
> extension when saving an image in 3D View?

It works the other way round:  You type .png and it saves a PNG.  You
type .tiff and it saves a TIFF.  The same for JPEG.

Regards,

Yeti

Hello again,

I noticed the following problem in the latest version of Gwyddion (2.60), although it seems to me that this problem has already occurred in earlier versions.

problem description: In the 3D View no color bar is show when Invert Mapping was set in the Color Range window (ie the value of Minimum is lower than the value of Maximum).

one feature request: Would it be possible to automatically attach file extension when saving an image in 3D View?

Thank you

-- 
Regards,
 Milan

Hello Yeti,

Tuesday, February 15, 2022, 1:47:37 PM, you wrote:


> If this is the only problem then remove hdrimage.dll.  The function
> wsopen_s is used by OpenEXR and you probably don't need this module that
> badly.

 This worked. No more alert window during Gwyddion launch. Before that, I tried to install the last version of Visual C++ Redistributable package for WinXP as suggested by Mira, but it did not help (nevertheless, thank you Mira for the help).

> Do data analysis on a different machine from the one you use for acquistion.

this is probably the only future proof option


Thank you

-- 
Regards,
 Milan