Warning: Can't synchronize with repository "(default)" (/home/git/ome.git does not appear to be a Git repository.). Look in the Trac log for more information.
- Timestamp:
-
10/29/12 20:43:58 (12 years ago)
- Author:
-
jmoore
- Comment:
-
Legend:
- Unmodified
- Added
- Removed
- Modified
-
- Property Cc mlinkert-x bpindelski cblackburn wmoore added
-
Property
Sprint
changed from
2011-04-07 (9)
to
-
Property
Milestone
changed from
OMERO-Beta4.3
to
Unscheduled
-
initial
|
v7
|
|
1 | | The background thread (#4736) has some restrictions on which pyramids it generates, but this should use the same strategy as the `PixelsService` getPixelBuffer method, so that only where a request would require a pyramid will it be generated. Further, the creation of pyramids for an entire plate should possibly be skipped and done only on demand. |
| 1 | The background thread (#4736) has some restrictions on which pyramids it generates, but this should use the same strategy as the `PixelsService` getPixelBuffer method, so that only where a request would require a pyramid will it be generated. |
| 2 | * Further, the creation of pyramids for an entire plate should possibly be skipped and done only on demand. |
| 3 | * Further, under fs-lite any file format with a pre-calculated pyramid structure should of course ''not'' have a pyramid generated. EM images and certain odd edge cases (a DV file with 8k x 8) will have `getResolutionCount() == 1` and ''should'' have pyramids generated. |
| 4 | |
| 5 | It's unclear whether pyramids should be: |
| 6 | * stored under `/OMERO/Pixels` **or** stored beside (or at least near) the fs files themselves |
| 7 | * deleted periodically in order to reduce disk space |
| 8 | * generated in a background process or done in the fore-ground (saving a LOT of memory on the `PixelData` process) |
1.3.13-PRO © 2008-2011
Agilo Software all
rights reserved
(this page was served in: 0.13289 sec.)