10 research outputs found

    Large expert-curated database for benchmarking document similarity detection in biomedical literature search

    Get PDF
    Document recommendation systems for locating relevant literature have mostly relied on methods developed a decade ago. This is largely due to the lack of a large offline gold-standard benchmark of relevant documents that cover a variety of research fields such that newly developed literature search techniques can be compared, improved and translated into practice. To overcome this bottleneck, we have established the RElevant LIterature SearcH consortium consisting of more than 1500 scientists from 84 countries, who have collectively annotated the relevance of over 180 000 PubMed-listed articles with regard to their respective seed (input) article/s. The majority of annotations were contributed by highly experienced, original authors of the seed articles. The collected data cover 76% of all unique PubMed Medical Subject Headings descriptors. No systematic biases were observed across different experience levels, research fields or time spent on annotations. More importantly, annotations of the same document pairs contributed by different scientists were highly concordant. We further show that the three representative baseline methods used to generate recommended articles for evaluation (Okapi Best Matching 25, Term Frequency-Inverse Document Frequency and PubMed Related Articles) had similar overall performances. Additionally, we found that these methods each tend to produce distinct collections of recommended articles, suggesting that a hybrid method may be required to completely capture all relevant articles. The established database server located at https://relishdb.ict.griffith.edu.au is freely available for the downloading of annotation data and the blind testing of new methods. We expect that this benchmark will be useful for stimulating the development of new powerful techniques for title and title/abstract-based search engines for relevant articles in biomedical research.Peer reviewe

    Determining crystal structures through crowdsourcing and coursework

    Get PDF
    We show here that computer game players can build high-quality crystal structures. Introduction of a new feature into the computer game Foldit allows players to build and real-space refine structures into electron density maps. To assess the usefulness of this feature, we held a crystallographic model-building competition between trained crystallographers, undergraduate students, Foldit players and automatic model-building algorithms. After removal of disordered residues, a team of Foldit players achieved the most accurate structure. Analysing the target protein of the competition, YPL067C, uncovered a new family of histidine triad proteins apparently involved in the prevention of amyloid toxicity. From this study, we conclude that crystallographers can utilize crowdsourcing to interpret electron density information and to produce structure solutions of the highest quality

    Ablation of lysozyme M-positive cells prevents aircraft noise-induced vascular damage without improving cerebral side effects

    No full text
    Aircraft noise induces vascular and cerebral inflammation and oxidative stress causing hypertension and cardiovascular/cerebral dysfunction. With the present studies, we sought to determine the role of myeloid cells in the vascular vs. cerebral consequences of exposure to aircraft noise. Toxin-mediated ablation of lysozyme

    Protection Versus Pathology in Aviremic and High Viral Load HIV-2 Infection—The Pivotal Role of Immune Activation and T-cell Kinetics

    Get PDF
    BACKGROUND: Many human immunodeficiency virus (HIV)-2-infected individuals remain aviremic and behave as long-term non-progressors but some progress to AIDS. We hypothesized that immune activation and T-cell turnover would be critical determinants of non-progressor/progressor status. METHODS: We studied 37 subjects in The Gambia, West Africa: 10 HIV-negative controls, 10 HIV-2-infected subjects with low viral loads (HIV-2-LV), 7 HIV-2-infected subjects with high viral loads (HIV-2-HV), and 10 with HIV-1 infection. We measured in vivo T-cell turnover using deuterium-glucose labeling, and correlated results with T-cell phenotype (by flow cytometry) and T-cell receptor excision circle (TREC) abundance. RESULTS: Immune activation (HLA-DR/CD38 coexpression) differed between groups with a significant trend: controls <HIV-2-LV <HIV-1 <HIV-2-HV (P < .01 for all cell types). A similar trend was observed in the pattern of in vivo turnover of memory CD4(+) and CD8(+) T-cells and TREC depletion in naive CD4(+) T-cells, although naive T-cell turnover was relatively unaffected by either infection. T-cell turnover, immune activation, and progressor status were closely associated. CONCLUSIONS: HIV-2 non-progressors have low rates of T-cell turnover (both CD4(+) and CD8(+)) and minimal immune activation; high viral load HIV-2 progressors had high values, similar to or exceeding those in HIV-1 infection

    STIR Software for Tomographic Image Reconstruction

    No full text
    &lt;h1&gt;Summary of changes in STIR release 5.2.0&lt;/h1&gt; &lt;p&gt;This version is 100% backwards compatible with STIR 5.0 as far as usage goes. However, there are changes in the output of scatter estimation and ECAT8 normalisation, see below for more information.&lt;/p&gt; &lt;h2&gt;Overall summary&lt;/h2&gt; &lt;p&gt;Of course, there is also the usual code-cleanup and improvements to the documentation. See also &lt;a href="https://github.com/UCL/STIR/milestone/6"&gt;the 5.2 milestone on GitHub&lt;/a&gt;.&lt;/p&gt; &lt;p&gt;Overall code management and assistance by Kris Thielemans (UCL and ASC). Other main contributors were Daniel Deidda (NPL) and Markus Jehl (Positrigo).&lt;/p&gt; &lt;h2&gt;Patch release info&lt;/h2&gt; &lt;ul&gt; &lt;li&gt;5.2.0 released 30/10/2023&lt;/li&gt; &lt;/ul&gt; &lt;h2&gt;Summary for end users (also to be read by developers)&lt;/h2&gt; &lt;h3&gt;Bug fixes&lt;/h3&gt; &lt;ul&gt; &lt;li&gt;Scatter estimation was setting initial activity image to 1 at set-up, effectively ignoring the initial image, aside from geometric info.&lt;/li&gt; &lt;li&gt;Setting SPECTUB resolution model with STIR python or SIRF divided slope by 10 in error. The problem did not occur when set using parameter file&lt;/li&gt; &lt;/ul&gt; &lt;h3&gt;Changed functionality&lt;/h3&gt; &lt;ul&gt; &lt;li&gt;The ECAT8 normalisation (used for the Siemens mMR) code now takes the 4th component &lt;em&gt;axial effects&lt;/em&gt; into account. These normalisation factors are therefore different (even up to ~10%). This gives improved axial uniformity in the images. The use of the axial effects can be switched off by adding setting &lt;code&gt;use_axial_effects_factors:=0&lt;/code&gt; to the parameter file (see an example in &lt;code&gt;examples/Siemens-mMR/correct_projdata_no_axial_effects.par&lt;/code&gt;), or the class member of the same name. In addition, the Siemens normalisation header is now read (using a new class &lt;code&gt;InterfileNormHeaderSiemens&lt;/code&gt;) such that hard-coded variables for the Siemens mMR have been removed. Further testing of this functionality is still required however. &lt;a href="https://github.com/UCL/STIR/pull/1182/"&gt;PR #1182&lt;/a&gt;.&lt;/li&gt; &lt;li&gt;Interfile header parsing now correctly identifies keywords that contain a colon by checking for &lt;code&gt;:=&lt;/code&gt;.&lt;/li&gt; &lt;li&gt;The &lt;code&gt;set_up()&lt;/code&gt; method of the ray-tracing projection matrix now skips further processing if it was already called with data of the same characteristics. This will means that any cached data will be re-used, potentially leading to a speed-up when re-using it from Python. &lt;a href="https://github.com/UCL/STIR/pull/1281/"&gt;PR #1281&lt;/a&gt;.&lt;/li&gt; &lt;/ul&gt; &lt;h3&gt;New functionality&lt;/h3&gt; &lt;ul&gt; &lt;li&gt;&lt;p&gt;The &lt;code&gt;Discretised Shape3D&lt;/code&gt; shape/ROI has now an extra value &lt;code&gt;label index&lt;/code&gt;. For ROIs, this allows using a single volume with multiple ROIs encoded as labels, such as output by ITKSnap and many others. When used as a shape in &lt;code&gt;generate_image&lt;/code&gt;, it could be used to extract a single ROI from such a label image. &lt;a href="https://github.com/UCL/STIR/pull/1196/"&gt;PR #1196&lt;/a&gt;.&lt;/p&gt; &lt;/li&gt; &lt;li&gt;&lt;p&gt;Global variables in SPECTUB have been substituted by class members, such that multiple SPECTUB projectors can be used. &lt;a href="https://github.com/UCL/STIR/pull/1169/"&gt;PR #1169&lt;/a&gt;.&lt;/p&gt; &lt;/li&gt; &lt;li&gt;&lt;p&gt;Global variables in PinholeSPECTUB have been substituted by class members, such that multiple PinholeSPECTUB projectors can be used. &lt;a href="https://github.com/UCL/STIR/pull/1212/"&gt;PR #1212&lt;/a&gt;.&lt;/p&gt; &lt;/li&gt; &lt;li&gt;&lt;p&gt;Scatter estimation is now smoothed in axial direction for BlocksOnCylindrical scanners. &lt;a href="https://github.com/UCL/STIR/pull/1172/"&gt;PR #1172&lt;/a&gt;.&lt;/p&gt; &lt;/li&gt; &lt;li&gt;&lt;p&gt;&lt;code&gt;InverseSSRB&lt;/code&gt; now works for BlocksOnCylindrical after a rewrite. &lt;a href="https://github.com/UCL/STIR/pull/1172/"&gt;PR #1172&lt;/a&gt;. /&lt;/p&gt; &lt;/li&gt; &lt;li&gt;&lt;p&gt;Parallelised function &lt;code&gt;set_fan_data_add_gaps_help&lt;/code&gt; across segments to reduce computation time. &lt;a href="https://github.com/UCL/STIR/pull/1168/"&gt;PR #1168&lt;/a&gt;.&lt;/p&gt; &lt;/li&gt; &lt;li&gt;&lt;p&gt;New utility &lt;code&gt;SPECT_dicom_to_interfile&lt;/code&gt; which reads a DICOM file with SPECT projection data and extracts the data and writes one or more Interfile 3.3 headers (still somewhat preliminary). &lt;a href="https://github.com/UCL/STIR/pull/1182/"&gt;PR #1182&lt;/a&gt;.&lt;/p&gt; &lt;/li&gt; &lt;li&gt;&lt;p&gt;The new &lt;code&gt;stir_timings&lt;/code&gt; utility is mostly useful for developers, but you could use it to optimise the number of OpenMP threads to use for your data. &lt;a href="https://github.com/UCL/STIR/pull/1237/"&gt;PR #1237&lt;/a&gt;.&lt;/p&gt; &lt;/li&gt; &lt;li&gt;&lt;p&gt;New classes &lt;code&gt;SegmentIndices&lt;/code&gt;, &lt;code&gt;ViewgramIndices&lt;/code&gt; and &lt;code&gt;SinogramIndices&lt;/code&gt;, used by &lt;code&gt;ProjData&lt;/code&gt; related classes, as opposed to having to specify all the elements directly, e.g. in C++&lt;/p&gt; &lt;pre&gt;&lt;code&gt; auto sinogram = proj_data.get_sinogram(sinogram_indices);&lt;/code&gt;&lt;/pre&gt; &lt;p&gt;This makes these functions more future proof, in particular for TOF. The older functions are now deprecated. Note that as &lt;code&gt;Bin&lt;/code&gt; is now derived from &lt;code&gt;ViewgramIndices&lt;/code&gt;, instantations of &lt;code&gt;Bin&lt;/code&gt; can now be used to specify the indices as well in most places. There is still more work to do here, mostly related to the symmetries. &lt;a href="https://github.com/UCL/STIR/pull/1273/"&gt;PR #1273&lt;/a&gt;.&lt;/p&gt; &lt;/li&gt; &lt;/ul&gt; &lt;h4&gt;Python (and MATLAB)&lt;/h4&gt; &lt;ul&gt; &lt;li&gt;Examples use &lt;code&gt;stir.ProjData.read_from_file&lt;/code&gt; as opposed to &lt;code&gt;stir.ProjData_read_from_file&lt;/code&gt;. The former is supported since SWIG 3.0, and the &lt;a href="https://swig.org/Doc4.1/Python.html#Python_nn20"&gt;default from SWIG 4.1&lt;/a&gt;.&lt;/li&gt; &lt;li&gt;Addition of &lt;code&gt;DetectionPosition&lt;/code&gt; and &lt;code&gt;DetectionPositionPair&lt;/code&gt;.&lt;/li&gt; &lt;li&gt;&lt;code&gt;bin.time_frame_num&lt;/code&gt; is now no longer a function in Python, but acts like a variable (as the other &lt;code&gt;Bin&lt;/code&gt; members).&lt;/li&gt; &lt;li&gt;Addition of &lt;code&gt;RadionuclideDB&lt;/code&gt;&lt;/li&gt; &lt;/ul&gt; &lt;h3&gt;New examples&lt;/h3&gt; &lt;ul&gt; &lt;li&gt;&lt;code&gt;examples/python/construct_projdata_demo.py&lt;/code&gt; illustrates constructing a &lt;code&gt;ProjDataInMemory&lt;/code&gt;&lt;/li&gt; &lt;/ul&gt; &lt;h3&gt;Changed functionality&lt;/h3&gt; &lt;ul&gt; &lt;li&gt;Scatter estimation was resetting the activity image to 1 before each iteration. This led to cases where the reconstructed image (and therefore the scatter estimation) did not converge, especially when using a small number of sub-iterations. Now, the reconstructed image is continuouslu updated between scatter iterations by default. This should also allow users to use less sub-iterations, therefore saving some time for the scatter estimation. The old behaviour can be re-enabled by setting &lt;code&gt;restart_reconstruction_every_scatter_iteration&lt;/code&gt; to true either via a parameter file or via the &lt;code&gt;set_restart_reconstruction_every_scatter_iteration()&lt;/code&gt; function. &lt;a href="https://github.com/UCL/STIR/pull/1160/"&gt;PR #1160&lt;/a&gt;.&lt;/li&gt; &lt;li&gt;energy resolution functions and keywords have now more documentation. &lt;code&gt;Scanner::check_consistency&lt;/code&gt; also checks if the energy resolution is less than 20 (as it is FWHM/reference_energy). &lt;a href="https://github.com/UCL/STIR/pull/1149/"&gt;PR #1149&lt;/a&gt;.&lt;/li&gt; &lt;li&gt;Errors now throw &lt;code&gt;std::runtime_error&lt;/code&gt; instead of &lt;code&gt;std::string&lt;/code&gt;. &lt;a href="https://github.com/UCL/STIR/pull/1131/"&gt;PR #1131&lt;/a&gt;.&lt;/li&gt; &lt;li&gt;The parameter &lt;code&gt;use_view_offset&lt;/code&gt; was removed from the &lt;code&gt;interpolate_projdata&lt;/code&gt; functions. View-offset is now always taken into account. &lt;a href="https://github.com/UCL/STIR/pull/1172/"&gt;PR #1172&lt;/a&gt;.&lt;/li&gt; &lt;li&gt;The info, warning and error calls are thread safe now (which makes them slower), and the logging output in &lt;code&gt;distributable.cxx&lt;/code&gt; was changed from verbosity 2 (which is the STIR default) to verbosity 3. This is to reduce the default output during iterative reconstructions. &lt;a href="https://github.com/UCL/STIR/pull/1243/"&gt;PR #1243&lt;/a&gt;.&lt;/li&gt; &lt;li&gt;The &lt;code&gt;Succeeded&lt;/code&gt; class has a new method &lt;code&gt;bool succeeded()&lt;/code&gt; enabling more concise code (avoiding the need for comparing with &lt;code&gt;Succeeded::yes&lt;/code&gt; which is especially verbose in Python).&lt;/li&gt; &lt;li&gt;The example files for the Siemens mMR now use lower min/max thresholds for the (single) scatter scale. This gives better results, see &lt;a href="https://github.com/UCL/STIR/issues/1163/"&gt;Issue #1163&lt;/a&gt;. &lt;a href="https://github.com/UCL/STIR/pull/1279/"&gt;PR #1279&lt;/a&gt;.&lt;/li&gt; &lt;/ul&gt; &lt;h3&gt;Deprecated functionality and upcoming changes to required tool versions&lt;/h3&gt; &lt;ul&gt; &lt;li&gt;The following functions (previously used for upsampling the scatter estimate) have been made obsolete or replaced, and will be removed in STIR version 6.0.0: &lt;code&gt;interpolate_axial_position&lt;/code&gt;, &lt;code&gt;extend_sinogram_in_views&lt;/code&gt; and &lt;code&gt;extend_segment_in_views&lt;/code&gt;&lt;/li&gt; &lt;li&gt;Constructors/functions in &lt;code&gt;ProjData&lt;/code&gt; related classes that explicitly use &lt;code&gt;axial_pos_num&lt;/code&gt;, &lt;code&gt;view_num&lt;/code&gt; etc in their arguments are now deprecated, and should be replaced by their respective versions that use &lt;code&gt;SegmentIndices&lt;/code&gt;, &lt;code&gt;ViewgramIndices&lt;/code&gt; or &lt;code&gt;SinogramIndices&lt;/code&gt;. The former will not be compatible with TOF information that will be introduced in version 6.0.0.&lt;/li&gt; &lt;li&gt;Use of the AVW library to read Analyze files will be removed in 6.0, as this has not been checked in more than 15 years. Use ITK instead.&lt;/li&gt; &lt;li&gt;GE VOLPET and IE support will be removed in 6.0, as we have no files to test this, and it's obsolete anyway.&lt;/li&gt; &lt;li&gt;STIR version 6.0.0 will require C++ 14 (currently we require C++ 11, but already support C++ 20) and CMake 3.14.&lt;/li&gt; &lt;/ul&gt; &lt;h3&gt;Build system and dependencies&lt;/h3&gt; &lt;ul&gt; &lt;li&gt;CMake 3.12 is now required on Windows.&lt;/li&gt; &lt;li&gt;We now use CMake's &lt;a href="https://gitlab.kitware.com/cmake/community/-/wikis/doc/tutorials/Object-Library"&gt;OBJECT library feature&lt;/a&gt; for the registries. This avoids re-compilation of the registries for every executable and therefore speeds-up building time. Use of STIR in an external project is not affected as long as the recommended practice was followed. This is now documented in the User's Guide. &lt;a href="https://github.com/UCL/STIR/pull/1141/"&gt;PR #1141&lt;/a&gt;.&lt;/li&gt; &lt;li&gt;The &lt;code&gt;error&lt;/code&gt; and &lt;code&gt;warning&lt;/code&gt; functions are now no longer included from &lt;code&gt;common.h&lt;/code&gt; and need to be included manually when used (as was already the case for &lt;code&gt;#include &quot;stir/info.h&quot;&lt;/code&gt;). &lt;a href="https://github.com/UCL/STIR/pull/1192/"&gt;PR #1192&lt;/a&gt;.&lt;/li&gt; &lt;li&gt;add .h and .i as dependencies for SWIG generated wrappers to make sure they get rebuild. (Currently adding all .h files, which is too much, but CMake needs a fix before we can do this properly). &lt;a href="https://github.com/UCL/STIR/pull/1218/"&gt;PR #1218&lt;/a&gt;.&lt;/li&gt; &lt;/ul&gt; &lt;h3&gt;Changes for developers&lt;/h3&gt; &lt;ul&gt; &lt;li&gt;moved all functionality in &lt;code&gt;CListEventCylindricalScannerWithDiscreteDetectors&lt;/code&gt; to template class &lt;code&gt;CListEventScannerWithDiscreteDetectors&lt;/code&gt; (templated in &lt;code&gt;ProjDataInfoT&lt;/code&gt;). This enables re-use for generic/blocksoncylindrical scanners. &lt;a href="https://github.com/UCL/STIR/pull/1222/"&gt;PR #1222&lt;/a&gt;.&lt;/li&gt; &lt;li&gt;rewritten &lt;code&gt;ProjDataInMemory&lt;/code&gt; to avoid streams, causing a speed-up of some operations, and removing a limit of total size of 2GB. &lt;a href="https://github.com/UCL/STIR/pull/1260/"&gt;PR #1260&lt;/a&gt;.&lt;/li&gt; &lt;/ul&gt; &lt;h3&gt;Known problems&lt;/h3&gt; &lt;ul&gt; &lt;li&gt;See &lt;a href="https://github.com/UCL/STIR/labels/bug"&gt;our issue tracker&lt;/a&gt;.&lt;/li&gt; &lt;/ul&gt; &lt;h3&gt;Minor (?) bug fixes&lt;/h3&gt; &lt;ul&gt; &lt;li&gt;Small change in scatter simulation to how non-arccorrected bins are computed. Added a check in the construction of non-arccorrected projdata that the number of tangential bins is not larger than the maximum non-arccorrected bins. &lt;a href="https://github.com/UCL/STIR/pull/1152/"&gt;PR #1152&lt;/a&gt;.&lt;/li&gt; &lt;li&gt;&lt;code&gt;extend_segment_in_views&lt;/code&gt; does not handle view offsets correctly and does not work for BlocksOnCylindrical scanners &lt;a href="https://github.com/UCL/STIR/issues/1177/"&gt;issue #1177&lt;/a&gt;. A new function &lt;code&gt;extend_segment&lt;/code&gt; was added that works for Cylindrical and BlocksOnCylindrical and allows extension in tangential and axial direction as well. &lt;a href="https://github.com/UCL/STIR/pull/1172/"&gt;PR #1172&lt;/a&gt;.&lt;/li&gt; &lt;li&gt;&lt;code&gt;sample_function_on_regular_grid&lt;/code&gt; did not handle offset correctly in all places &lt;a href="https://github.com/UCL/STIR/issues/1178/"&gt;issue #1178&lt;/a&gt;. &lt;a href="https://github.com/UCL/STIR/pull/1172/"&gt;PR #1172&lt;/a&gt;.&lt;/li&gt; &lt;li&gt;Ray tracing projection for BlocksOnCylindrical scanner geometries contained a bug where some bins were swapped across oblique segments &lt;a href="https://github.com/UCL/STIR/issues/1223/"&gt;issue #1223&lt;/a&gt;. This sometimes lead to large artifacts in reconstructions. &lt;a href="https://github.com/UCL/STIR/pull/1231/"&gt;PR #1231&lt;/a&gt;.&lt;/li&gt; &lt;/ul&gt; &lt;h3&gt;Documentation changes&lt;/h3&gt; &lt;ul&gt; &lt;li&gt;Updated the STIR developers guide, which was quite out-of-date w.r.t. C++ features etc.&lt;/li&gt; &lt;/ul&gt; &lt;h3&gt;recon_test_pack changes&lt;/h3&gt; &lt;ul&gt; &lt;li&gt;Updated headers of most images and projection data to avoid warnings.&lt;/li&gt; &lt;/ul&gt; &lt;h3&gt;Other changes to tests&lt;/h3&gt; &lt;ul&gt; &lt;li&gt;&lt;code&gt;test_Scanner.cxx&lt;/code&gt; tests for energy resolution, &lt;a href="https://github.com/UCL/STIR/pull/1149/"&gt;PR #1149&lt;/a&gt;.&lt;/li&gt; &lt;li&gt;New file &lt;code&gt;test_interpolate_projdata&lt;/code&gt;, &lt;a href="https://github.com/UCL/STIR/pull/1141/"&gt;PR #1141&lt;/a&gt;.&lt;/li&gt; &lt;/ul&gt;If you use this software, please cite it using the metadata from this file

    Students' participation in collaborative research should be recognised

    No full text
    Letter to the editor

    Large expert-curated database for benchmarking document similarity detection in biomedical literature search

    No full text

    Large expert-curated database for benchmarking document similarity detection in biomedical literature search

    No full text
    Document recommendation systems for locating relevant literature have mostly relied on methods developed a decade ago. This is largely due to the lack of a large offline gold-standard benchmark of relevant documents that cover a variety of research fields such that newly developed literature search techniques can be compared, improved and translated into practice. To overcome this bottleneck, we have established the RElevant LIterature SearcH consortium consisting of more than 1500 scientists from 84 countries, who have collectively annotated the relevance of over 180 000 PubMed-listed articles with regard to their respective seed (input) article/s. The majority of annotations were contributed by highly experienced, original authors of the seed articles. The collected data cover 76% of all unique PubMed Medical Subject Headings descriptors. No systematic biases were observed across different experience levels, research fields or time spent on annotations. More importantly, annotations of the same document pairs contributed by different scientists were highly concordant. We further show that the three representative baseline methods used to generate recommended articles for evaluation (Okapi Best Matching 25, Term Frequency-Inverse Document Frequency and PubMed Related Articles) had similar overall performances. Additionally, we found that these methods each tend to produce distinct collections of recommended articles, suggesting that a hybrid method may be required to completely capture all relevant articles. The established database server located at https://relishdb.ict.griffith.edu.au is freely available for the downloading of annotation data and the blind testing of new methods. We expect that this benchmark will be useful for stimulating the development of new powerful techniques for title and title/abstract-based search engines for relevant articles in biomedical science. © The Author(s) 2019. Published by Oxford University Press

    Guidelines for the use and interpretation of assays for monitoring autophagy (4th edition)

    No full text
    In 2008, we published the first set of guidelines for standardizing research in autophagy. Since then, this topic has received increasing attention, and many scientists have entered the field. Our knowledge base and relevant new technologies have also been expanding. Thus, it is important to formulate on a regular basis updated guidelines for monitoring autophagy in different organisms. Despite numerous reviews, there continues to be confusion regarding acceptable methods to evaluate autophagy, especially in multicellular eukaryotes. Here, we present a set of guidelines for investigators to select and interpret methods to examine autophagy and related processes, and for reviewers to provide realistic and reasonable critiques of reports that are focused on these processes. These guidelines are not meant to be a dogmatic set of rules, because the appropriateness of any assay largely depends on the question being asked and the system being used. Moreover, no individual assay is perfect for every situation, calling for the use of multiple techniques to properly monitor autophagy in each experimental setting. Finally, several core components of the autophagy machinery have been implicated in distinct autophagic processes (canonical and noncanonical autophagy), implying that genetic approaches to block autophagy should rely on targeting two or more autophagy-related genes that ideally participate in distinct steps of the pathway. Along similar lines, because multiple proteins involved in autophagy also regulate other cellular pathways including apoptosis, not all of them can be used as a specific marker for bona fide autophagic responses. Here, we critically discuss current methods of assessing autophagy and the information they can, or cannot, provide. Our ultimate goal is to encourage intellectual and technical innovation in the field
    corecore