ENLIGHTEN
Cross-platform desktop GUI for Wasatch Photonics spectrometers
Loading...
Searching...
No Matches
enlighten.measurement.Measurement.Measurement Class Reference

Encapsulates a single saved measurement from one spectrometer, comprising a ProcessedReading (optionally containing the original Reading object that generated it), metadata (Settings), as well as a ThumbnailWidget for display on the capture bar. More...

Public Member Functions

 __init__ (self, ctl=None, processed_reading=None, settings=None, source_pathname=None, timestamp=None, spec=None, measurement=None, d=None)
 There are three valid instantiation patterns:
 
 add_pathname (self, pathname)
 
 build_row (self, field)
 Generate a single row of output for row-ordered CSV files.
 
 clear (self)
 
 clone (self)
 Called by PluginWidget.
 
 csv_formatted (self, roi, prec, array, pixel, obey_roi=False)
 Used by save_csv_file_by_column and save_csv_file_by_row.
 
 delete (self, from_disk=False, update_parent=False)
 Release any resources associated with this Measurement.
 
 display (self)
 Display on the graph, if not already shown.
 
 dump (self)
 
 expand_template (self, template)
 Some GUI text fields allow the user to enter strings containining "macro templates" which are dynamically expanded and evaluated at runtime.
 
 generate_basename (self)
 
 generate_id (self)
 
 generate_label (self)
 
 generate_today_dir (self)
 
dict get_all_metadata (self)
 
 get_csv_data (self, pr)
 Used by save_csv_file_by_column and save_csv_file_by_row.
 
 get_extra_header_fields (self)
 
 get_metadata (self, field)
 This function is provided because legacy Dash and ENLIGHTEN saved row- ordered CSV files with very specific column headers and sequence which we don't want to casually break.
 
 has_component (self, component)
 Not currently used.
 
 id_callback (self, declared_match)
 Called (by way of ThumbnailWidget -> KnowItAll.Feature -> Measurements) when KnowItAll has generated a KnowItAll.DeclaredMatch for this Measurement.
 
 init_from_dict (self, d)
 This is experimental.
 
 interpolate (self, new_settings)
 Passed a SpectrometerSettings object (containing wavelengths, wavenumbers etc), return a copy of this Measurement's ProcessedReading which has been interpolated to the passed x-axis.
 
 is_displayed (self)
 
 rename_files (self)
 The measurement has been relabled (say, "cyclohexane").
 
 replace_processed_reading (self, pr)
 We presumably loaded a measurement from disk, reprocessed it, and are now replacing the contents of the Measurement object with the reprocessed spectra, preparatory to re-saving (with a new timestamp and measurement_id).
 
 save (self, resave=False)
 
 save_csv_file (self, resave=False)
 
 save_csv_file_by_column (self, use_basename=False, ext="csv", delim=",", include_header=True, include_metadata=True, resave=False)
 Save the Measurement in a CSV file with the x-axis in one column, spectra in the next column and so on (similar layout as the Excel output).
 
 save_csv_file_by_row (self, resave=False)
 Save a spectrum in CSV format with the whole spectrum on one line, such that multiple acquisitions could be appended with one line per spectrum.
 
 save_dx_file (self, use_basename=False, resave=False)
 
 save_excel_file (self, resave=False)
 Save the spectra in xls format (currently, one worksheet per x-axis)
 
 save_json_file (self, use_basename=False, resave=False)
 Save the Measurement in a JSON file for simplified programmatic parsing.
 
 save_spc_file (self, use_basename=False, resave=False)
 
 save_txt_file (self, use_basename=False, resave=False)
 This is essentially the same as column-ordered CSV, but with no metadata, no header row and no commas.
 
 to_dict (self)
 Express the current Measurement as a single JSON-compatible dict.
 
 to_json (self)
 Render the current Measurement to JSON.
 
 update_label (self, label, manual=False)
 
 verify_pathname (self, pathname, resave=False)
 
 write_processed_reading_lines (self, csv_writer)
 For row-ordered CSVs, output any ProcessedReading fields which have been selected.
 
 write_row (self, csv_writer, field)
 
 write_x_axis_lines (self, csv_writer)
 For row-ordered CSVs, output any x-axis fields that have been selected.
 

Static Public Member Functions

 generate_dash_file_header (serial_numbers)
 generate a legacy Dash file header with one or more serial numbers
 

Public Attributes

bool appending = False
 
 baseline_correction_algo = None
 
str basename = None
 
 ctl = ctl
 
 declared_match = None
 
int declared_score = 0
 
 label = None
 
str measurement_id = None
 
dict metadata = {}
 
str note = ""
 
dict pathname_by_ext = {}
 
str plugin_name = ""
 
str prefix = ""
 
 processed_reading = None
 
bool renamed_manually = False
 
bool roi_active = False
 
 settings = None
 
 source_pathname = None
 
 spec = None
 
str suffix = ""
 
 technique = None
 
 thumbnail_widget = None
 
 timestamp = None
 

Static Public Attributes

list CSV_HEADER_FIELDS
 These appear in legacy saved spectra files as-written (Dash format), so don't casually screw with them (could break customer applications).
 
 CSV_HEADER_FIELDS_SET = set(CSV_HEADER_FIELDS)
 
list EXTRA_HEADER_FIELDS
 These fields weren't in the original Dash file format, so only use for the new "column-ordered" formats (including 'export')
 
 EXTRA_HEADER_FIELDS_SET = set(EXTRA_HEADER_FIELDS)
 
list ROW_ONLY_FIELDS = ['Blank', 'Line Number']
 These CSV_HEADER_FIELDS only need to be used for row-ordered files.
 

Detailed Description

Encapsulates a single saved measurement from one spectrometer, comprising a ProcessedReading (optionally containing the original Reading object that generated it), metadata (Settings), as well as a ThumbnailWidget for display on the capture bar.

Note that other than the ProcessedReading, SpectrometerApplicationState is NOT retained in the Measurement.

A Measurement object is created when:

  • the user clicks the "Acquire" button on the GUI
  • a BatchCollection triggers one or more Acquire events
  • the user loads a spectrum from disk

If a Measurement is loaded from disk, it will not contain the original Reading object. Also, the metadata may be limited.

If a Measurement is generated live, it will also have a reference to the spectrometer which generated it.

Regardless of whether the Measurement was generated from a live capture (Acquire) or loaded from disk, a ThumbnailWidget will be generated (not necessarily instantly) for visualization.

As some Measurements may be displayed in different x-axis coordinates, we need to store the "current / selected / displayed" x-axis for the Measurement. I'm tentatively thinking to do that in the ThumbnailWidget, as it's kind of an attribute of the trace, but we'll see.

I am not sure whether we really need separate Thumbnail and ThumbnailWidget classes, other than that they are literally very different things (the one is a pyqtgraph export, the other is a QWidget), even though one is typically displayed within the other.

Given that there are multiple ways to create a Measurement, with somewhat different attributes and controlled background timing, a MeasurementFactory is provided to separately encapsulate the process of construction.

Each Measurement has a .measurement_id, which is permanent. The id is used as the default label attribute (both for file basenames and for on-screen display), but the label may be subsequently changed by the user.

Pathnames and Persistence

There is no simple .pathname attribute for the Measurement, as one Measurement may have been saved to any or all of several different file types.

AT PRESENT, it is assumed that the creation of a Measurement will include saving the Measurement to one or more output files at creation, but this is not a long-term requirement (we may decide to support "session traces" which are never actually persisted to disk; Spectrasuite and OceanView have these).

There is a .pathnames set which aggregates all the pathnames which are known related to this Measurement, though it is not guaranteed complete in the case of loaded files from other sessions. (Ideally all such files would contain the original measurement_id somewhere within them, though not necessarily in the pathname.)

If a Measurement has been deserialized from disk, it will have a .source_pathname attribute to indicate the source file from which it was instantiated.

Note that the application caps how many Measurements are visible in the Thumbnail bar at any given time, and currently ENLIGHTEN's file-management operations (rename, delete etc) only function on visible Thumbnails, so if you're streaming vast BatchCollections to disk such that they get rotated out of our buffer, you'll have to rename / delete them through other means.

Renaming Measurements

Renaming Measurements is a potentially thorny issue. Early versions of ENLIGHTEN renamed the output file(s) when you changed the label of on-screen thumbnail, and customers wish to retain that ability (ticket from 2019-07-19).

However, there is all kinds of ugliness down this hole:

  • What if you were appending measurements to one big CSV?
  • What if you loaded the measurement for comparison from archival spectra?
  • What if you loaded the measurement from a big export file?

My current decision is that we will retain the historical ability to rename any file(s) saved from the given Measurement IFF the files were CREATED by the CURRENT ENLIGHTEN session; OR if the spectrum was loaded from a single file (not an export or appended collection).

This distinction is made when Measurements are loaded or saved, and tracked via a renameable_files list. It's not as simple as checking whether the spectrum was created or loaded, because it matters what type of file it was loaded from, or which type of file it was saved to.

A consequence of this design is that if you initially have CSV and XLS files saved, you can rename the thumbnail to "apple" and both CSV and XLS files will be renamed to apple.csv and apple.xls. However, if you then clear your thumbnails (or quit / relaunch ENLIGHTEN) and load apple.csv from disk, if you then rename the file to banana.csv, it will NOT likewise rename apple.xls to banana.xls.

Also, relabeling the Measurement on-screen, and even renaming the underlying file artifacts DOES NOT re-write or update the file contents. The "label" field in the file metadata is not updated. It would not be particularly hard to re-save the file, but this seems like it would have many risks if a newer version of ENLIGHTEN changed the file format, or if there had been extra data in the file (ignored during a load operation, or added by the user post-save) which would then be destroyed.

Thumbnails and resources

Originally, ENLIGHTEN had no "Measurements", only "Thumbnails" – the spectra was literally stored (only) as the y-values of the thumbnail graph, with no x-axis, no metadata etc. So it was an improvement to move forward to "Measurements with Thumbnails". But there is a resource issue with EVERY Measurement having a ThumbnailWidget...what if we run a weekend collection taking 250,000 samples?

A better architecture might be just "Measurements" (the data), plus a ThumbnailBar able to dynamically generate and display ThumbnailWidgets on scroll events (similar to a Swift TableView, where cells are populated as they scroll into view, and are released when offscreen).

And possibly move away from the heavy "Widget" (with a couple Frames, Buttons, the pyqtgraph etc) to a simpler table or tree view which would probably use less memory.

For now, I'm compromising by treating the on-screen thumbnails as a ringbuffer, and kicking-off old Measurements (from memory, not disk) when we exceed a limit.

Note that the MeasurementFactory automatically saves new Measurements to disk (per SaveOptions) as they are created from Spectrometers, BEFORE they are handed to Measurements for addition to the Thumbnail bar. The process of creating a Measurement (from Spectrometer) and saving it to disk is atomic, so there is no need to worry that automatic deletion of Measurements for resource management will cause data to be lost.

Exploits

It is ASSUMED that the user used the same Settings (integration time, boxcar smoothing, scan averaging etc) when taking the 'raw', 'dark' and 'reference' component spectra in generation of the 'processed' component. Only a single Settings object is retained for the entire ProcessedReading, which is copied when the Measurement is created.

That is, if the user does something like this, the wrong integration time would be stored with the Measurement:

  1. set integration time 100ms
  2. pause scope
  3. set integration time 200ms
  4. click "Acquire" to save the current on-screen (paused) measurement

There are various ways we could address this weakness (e.g., snap a Deep Copy of Settings on pause()), but it's not a priority at this time.

Todo
more robust / defined behavior with duplicate labels across Measurements (currently has some graphing glitches when adding / removing traces)

Constructor & Destructor Documentation

◆ __init__()

enlighten.measurement.Measurement.Measurement.__init__ ( self,
ctl = None,
processed_reading = None,
settings = None,
source_pathname = None,
timestamp = None,
spec = None,
measurement = None,
d = None )

There are three valid instantiation patterns:

  • with spec (take latest from that Spectrometer)
  • with source_pathname (deserializing from disk)
  • with data (for instance, from processed plugin spectra)

Member Function Documentation

◆ add_pathname()

enlighten.measurement.Measurement.Measurement.add_pathname ( self,
pathname )

◆ build_row()

enlighten.measurement.Measurement.Measurement.build_row ( self,
field )

Generate a single row of output for row-ordered CSV files.

The contents of the generated row depend on the 'field' parameter.

Metadata is only populated for x-axis fields and the FIRST ProcessedReading array.

◆ clear()

enlighten.measurement.Measurement.Measurement.clear ( self)

◆ clone()

enlighten.measurement.Measurement.Measurement.clone ( self)

Called by PluginWidget.

◆ csv_formatted()

enlighten.measurement.Measurement.Measurement.csv_formatted ( self,
roi,
prec,
array,
pixel,
obey_roi = False )

Used by save_csv_file_by_column and save_csv_file_by_row.

◆ delete()

enlighten.measurement.Measurement.Measurement.delete ( self,
from_disk = False,
update_parent = False )

Release any resources associated with this Measurement.

Note that this will automatically delete the ThumbnailWidget from its parent layout (if emplaced), and mark the object tree for garbage collection within PySide/Qt.

◆ display()

enlighten.measurement.Measurement.Measurement.display ( self)

Display on the graph, if not already shown.

◆ dump()

enlighten.measurement.Measurement.Measurement.dump ( self)

◆ expand_template()

enlighten.measurement.Measurement.Measurement.expand_template ( self,
template )

Some GUI text fields allow the user to enter strings containining "macro templates" which are dynamically expanded and evaluated at runtime.

Macros look like "{field_name}", where field_name can be any object attribute in wasatch.EEPROM, wasatch.SpectrometerState, or Measurement metadata (any field supported by Measurement.get_metadata). As a convenience some hardcoded macros are also supported, such as {time}.

Todo
We can't easily expand the set of objects whose attributes can be used (like BatchCollection) without running into potential namespace collisions (different objects can have identically- named attributes, leading to ambiguity). Templates should move toward a prefixed notation like "m.measurement_id", "b.current_batch_count" etc. This could then be implemented within a call to string.format(), giving users access to full precision controls etc.

Also I'd pull this out into a TemplateFeature.

◆ generate_basename()

enlighten.measurement.Measurement.Measurement.generate_basename ( self)

◆ generate_dash_file_header()

enlighten.measurement.Measurement.Measurement.generate_dash_file_header ( serial_numbers)
static

generate a legacy Dash file header with one or more serial numbers

Note
left static for Measurements.export_by_row

◆ generate_id()

enlighten.measurement.Measurement.Measurement.generate_id ( self)

◆ generate_label()

enlighten.measurement.Measurement.Measurement.generate_label ( self)

◆ generate_today_dir()

enlighten.measurement.Measurement.Measurement.generate_today_dir ( self)

◆ get_all_metadata()

dict enlighten.measurement.Measurement.Measurement.get_all_metadata ( self)

◆ get_csv_data()

enlighten.measurement.Measurement.Measurement.get_csv_data ( self,
pr )

Used by save_csv_file_by_column and save_csv_file_by_row.

◆ get_extra_header_fields()

enlighten.measurement.Measurement.Measurement.get_extra_header_fields ( self)

◆ get_metadata()

enlighten.measurement.Measurement.Measurement.get_metadata ( self,
field )

This function is provided because legacy Dash and ENLIGHTEN saved row- ordered CSV files with very specific column headers and sequence which we don't want to casually break.

Todo
Note that temperature fields come from the underlying Reading object, and in the case that we loaded previously-saved spectra from disk, we're not currently re-instantiating Reading objects (only the ProcessedReading, which is all that's needed for on-screen traces), so currently those output "NA"
Todo
replace if/elif with dict of lambdas

◆ has_component()

enlighten.measurement.Measurement.Measurement.has_component ( self,
component )

Not currently used.

◆ id_callback()

enlighten.measurement.Measurement.Measurement.id_callback ( self,
declared_match )

Called (by way of ThumbnailWidget -> KnowItAll.Feature -> Measurements) when KnowItAll has generated a KnowItAll.DeclaredMatch for this Measurement.

◆ init_from_dict()

enlighten.measurement.Measurement.Measurement.init_from_dict ( self,
d )

This is experimental.

Eventually we want to be able to load Measurements saved as JSON. We should also be able to receive externally-generated Measurements sent via JSON via the External API. This is reasonably key to both. Also it's handy to use this as a free-form intermediate format for parsing external formats like SPC.

◆ interpolate()

enlighten.measurement.Measurement.Measurement.interpolate ( self,
new_settings )

Passed a SpectrometerSettings object (containing wavelengths, wavenumbers etc), return a copy of this Measurement's ProcessedReading which has been interpolated to the passed x-axis.

Interpolate on wavelength if available, otherwise wavenumbers, otherwise just copy the uninterpolated pixel data.

Who calls this?

◆ is_displayed()

enlighten.measurement.Measurement.Measurement.is_displayed ( self)

◆ rename_files()

enlighten.measurement.Measurement.Measurement.rename_files ( self)

The measurement has been relabled (say, "cyclohexane").

So if pathnames contains "old.csv" and "old.xls", we want to rename them to "cyclohexane.csv" and "cyclohexane.xls". However, if those files already exist, we don't want to overwrite them (maybe the user is looking at a lot of cyclohexane). So if cyclohexane.csv already exists, just make cyclohexane-1.csv, etc. Whatever number we pick, apply it to all the pathnames (cyclohexane-1.xls, even if there wasn't already a cyclohexane.xls).

Also note that there are at least four ways this Measurement could have been instantiated:

  1. It could have been loaded from ONE individual CSV (not necessarily within EnlightenSpectra/YYYY-MM-DD).
    • Renaming possible, but possibly not a good idea? <– supported
  2. It could have been one of a SET of Measurements loaded from a big CSV (an appended row-order or an exported column-order CSV).
    • Renaming considered NOT POSSIBLE.
  3. It could have been generated from live data and saved to one or more single-spectrum files with various extensions (csv, xls, json, png etc).
    • Renaming possible and apparently customer desirable <– supported
  4. It could have been generated from live data and APPENDED to an existing file (typically row-ordered CSV).
    • Renaming considered NOT POSSIBLE
Returns
True on success

◆ replace_processed_reading()

enlighten.measurement.Measurement.Measurement.replace_processed_reading ( self,
pr )

We presumably loaded a measurement from disk, reprocessed it, and are now replacing the contents of the Measurement object with the reprocessed spectra, preparatory to re-saving (with a new timestamp and measurement_id).

◆ save()

enlighten.measurement.Measurement.Measurement.save ( self,
resave = False )
Todo
cloud etc

◆ save_csv_file()

enlighten.measurement.Measurement.Measurement.save_csv_file ( self,
resave = False )

◆ save_csv_file_by_column()

enlighten.measurement.Measurement.Measurement.save_csv_file_by_column ( self,
use_basename = False,
ext = "csv",
delim = ",",
include_header = True,
include_metadata = True,
resave = False )

Save the Measurement in a CSV file with the x-axis in one column, spectra in the next column and so on (similar layout as the Excel output).

Note that currently this is NOT writing UTF-8 / Unicode, although KIA- generated labels are Unicode. (Dieter doesn't seem to like Unicode CSV)

◆ save_csv_file_by_row()

enlighten.measurement.Measurement.Measurement.save_csv_file_by_row ( self,
resave = False )

Save a spectrum in CSV format with the whole spectrum on one line, such that multiple acquisitions could be appended with one line per spectrum.

This is was the ONLY supported save format in Dash and legacy ENLIGHTEN, and still makes great sense for batch collections (it's much easier to append lines than columns to an existing file).

At the moment, this method is also being used to append new measurements to existing files.

Right now, we're using serial number in a new Measurement's measurement_id, hence label, hence filename. Having serial_number in a row-ordered CSV which aggregates multiple spectrometers is potentially confusing, but when we save the first spectrum we don't know that's the intention.

Note that currently this is NOT writing UTF-8 / Unicode, although KIA- generated labels are Unicode.

Note that Measurements saved while "appending" are NOT considered renamable at the file level, while Measurements saved to individual files are.

Todo

support .cropped, .interpolated

consider how to properly support verify_pathname and resave

◆ save_dx_file()

enlighten.measurement.Measurement.Measurement.save_dx_file ( self,
use_basename = False,
resave = False )

◆ save_excel_file()

enlighten.measurement.Measurement.Measurement.save_excel_file ( self,
resave = False )

Save the spectra in xls format (currently, one worksheet per x-axis)

As with save_csv_file_by_column(), currently disregarding SaveOptions selections of what x-axis and ProcessedReading fields to include, because there is little benefit to removing them from individual files. We can always add this later if requested.

Note
Only saving one column of data at this time. Make sure to limit the total columns to 255 when saving multiple spectra.
Horizontal ROI

Note that the data output is a little different from save_csv_file_by_column. This format probably should match that other format, but right now it doesn't.

A key difference is cropped (but not interpolated) ProcessedReadings. CSV files output every PHYSICAL pixel for most fields (pixel, wavelength, wavenumber, raw), and only substitute the "NA" for cropped values in "processed." Instead, this currently just outputs the cropped versions of everything.

◆ save_json_file()

enlighten.measurement.Measurement.Measurement.save_json_file ( self,
use_basename = False,
resave = False )

Save the Measurement in a JSON file for simplified programmatic parsing.

in the next column and so on (similar layout as the Excel output).

As with save_excel_file(), currently disregarding SaveOptions selections of what x-axis and ProcessedReading fields to include, because there is little benefit to removing them from individual files. We can always add this later if requested.

◆ save_spc_file()

enlighten.measurement.Measurement.Measurement.save_spc_file ( self,
use_basename = False,
resave = False )

◆ save_txt_file()

enlighten.measurement.Measurement.Measurement.save_txt_file ( self,
use_basename = False,
resave = False )

This is essentially the same as column-ordered CSV, but with no metadata, no header row and no commas.

(per proj "Pioneer")

◆ to_dict()

enlighten.measurement.Measurement.Measurement.to_dict ( self)

Express the current Measurement as a single JSON-compatible dict.

Use this for both save_json_file and External.Feature.

◆ to_json()

enlighten.measurement.Measurement.Measurement.to_json ( self)

Render the current Measurement to JSON.

Use this for both save_json_file and External.Feature.

◆ update_label()

enlighten.measurement.Measurement.Measurement.update_label ( self,
label,
manual = False )

◆ verify_pathname()

enlighten.measurement.Measurement.Measurement.verify_pathname ( self,
pathname,
resave = False )

◆ write_processed_reading_lines()

enlighten.measurement.Measurement.Measurement.write_processed_reading_lines ( self,
csv_writer )

For row-ordered CSVs, output any ProcessedReading fields which have been selected.

In column-ordered files, it's not a big deal to always store dark / reference / raw, because they're easy to ignore if you're not using them. However, in row-ordered files, those extra lines can be really confusing, partly because of the "prefix columns" enforced by the file format (repeating wavecal coeffs etc), but also because when "appending" to existing files, it becomes very hard to tell which lines are spectrum-vs- component. So anyway, be careful not to print extra lines here that the user didn't request.

Regardless, there's no "caching" these across Measurements, because technically the user could have (and often would) take a new dark and reference repeatedly during a session. (They're not 'reasonably persistent' as with the x-axis.)

◆ write_row()

enlighten.measurement.Measurement.Measurement.write_row ( self,
csv_writer,
field )
See also
Scooby-Doo

◆ write_x_axis_lines()

enlighten.measurement.Measurement.Measurement.write_x_axis_lines ( self,
csv_writer )

For row-ordered CSVs, output any x-axis fields that have been selected.

Only do this if they have not yet been output for a given spectrometer.

To support multiple spectrometers, we're adding the spectrometer's serial number (as well as the x-axis unit) to the Notes field.

Note
the Dash file format reprints wavecal coeffs and excitation in every line, so technically the recipient could regenerate pixels, wavelengths and wavenumbers for every spectrum anyway. These are just convenience rows.

Member Data Documentation

◆ appending

bool enlighten.measurement.Measurement.Measurement.appending = False

◆ baseline_correction_algo

enlighten.measurement.Measurement.Measurement.baseline_correction_algo = None

◆ basename

enlighten.measurement.Measurement.Measurement.basename = None

◆ CSV_HEADER_FIELDS

enlighten.measurement.Measurement.Measurement.CSV_HEADER_FIELDS
static
Initial value:
= ['Line Number',
'Integration Time',
'Timestamp',
'Blank',
'Note',
'Temperature',
'CCD C0',
'CCD C1',
'CCD C2',
'CCD C3',
'CCD Offset',
'CCD Gain',
'CCD Offset Odd',
'CCD Gain Odd',
'Laser Wavelength',
'Laser Enable',
'Laser Power %',
'Laser Temperature',
'Pixel Count']

These appear in legacy saved spectra files as-written (Dash format), so don't casually screw with them (could break customer applications).

Note that all are scalars (no lists).

◆ CSV_HEADER_FIELDS_SET

enlighten.measurement.Measurement.Measurement.CSV_HEADER_FIELDS_SET = set(CSV_HEADER_FIELDS)
static

◆ ctl

enlighten.measurement.Measurement.Measurement.ctl = ctl

◆ declared_match

enlighten.measurement.Measurement.Measurement.declared_match = None

◆ declared_score

int enlighten.measurement.Measurement.Measurement.declared_score = 0

◆ EXTRA_HEADER_FIELDS

list enlighten.measurement.Measurement.Measurement.EXTRA_HEADER_FIELDS
static

These fields weren't in the original Dash file format, so only use for the new "column-ordered" formats (including 'export')

◆ EXTRA_HEADER_FIELDS_SET

enlighten.measurement.Measurement.Measurement.EXTRA_HEADER_FIELDS_SET = set(EXTRA_HEADER_FIELDS)
static

◆ label

enlighten.measurement.Measurement.Measurement.label = None

◆ measurement_id

enlighten.measurement.Measurement.Measurement.measurement_id = None

◆ metadata

dict enlighten.measurement.Measurement.Measurement.metadata = {}

◆ note

str enlighten.measurement.Measurement.Measurement.note = ""

◆ pathname_by_ext

enlighten.measurement.Measurement.Measurement.pathname_by_ext = {}

◆ plugin_name

str enlighten.measurement.Measurement.Measurement.plugin_name = ""

◆ prefix

str enlighten.measurement.Measurement.Measurement.prefix = ""

◆ processed_reading

enlighten.measurement.Measurement.Measurement.processed_reading = None

◆ renamed_manually

bool enlighten.measurement.Measurement.Measurement.renamed_manually = False

◆ roi_active

bool enlighten.measurement.Measurement.Measurement.roi_active = False

◆ ROW_ONLY_FIELDS

list enlighten.measurement.Measurement.Measurement.ROW_ONLY_FIELDS = ['Blank', 'Line Number']
static

These CSV_HEADER_FIELDS only need to be used for row-ordered files.

◆ settings

enlighten.measurement.Measurement.Measurement.settings = None

◆ source_pathname

enlighten.measurement.Measurement.Measurement.source_pathname = None

◆ spec

enlighten.measurement.Measurement.Measurement.spec = None

◆ suffix

str enlighten.measurement.Measurement.Measurement.suffix = ""

◆ technique

enlighten.measurement.Measurement.Measurement.technique = None

◆ thumbnail_widget

enlighten.measurement.Measurement.Measurement.thumbnail_widget = None

◆ timestamp

enlighten.measurement.Measurement.Measurement.timestamp = None

The documentation for this class was generated from the following file: