User Story #170 (closed)
Add PixelBuffer service methods to API
Reported by: | cxallan | Owned by: | cxallan |
---|---|---|---|
Priority: | major | Milestone: | 3.0-M2 |
Component: | API | Keywords: | iteration4 |
Cc: | bwzloranger | Story Points: | n.a. |
Sprint: | n.a. | Importance: | n.a. |
Total Remaining Time: | n.a. | Estimated Remaining Time: | n.a. |
Description
A PixelBuffer? service needs to be created, allowing the creation of on disk Pixel buffers and the execution of the setters for Planes, Stacks, etc.
Change History (9)
comment:1 Changed 18 years ago by anonymous
- Component changed from General to API
- Milestone changed from Unscheduled to 3.0-M2
- Owner changed from jmoore to anonymous
- Priority changed from minor to major
- Status changed from new to assigned
- Summary changed from PixelBuffer Service to Add PixelBuffer service methods to API
- Version changed from 3.0-M1 to 3.0-M2
comment:2 Changed 18 years ago by jmoore
- Owner changed from anonymous to jmoore
- Status changed from assigned to new
gah! anonymous-silliness.
comment:3 Changed 18 years ago by jmoore
Just thinking about this, every single call to the PixelBuffer methods is going to require a hit to the DB if this is stateless. Every call will need to create a session, do iQuery.get(Pixels.class,pixelsId), and then create the delegate PixelBuffer.
Are we sure we don't want to have this stateful? What will be the use cases? How many calls in a row? Calling getTimepoint for t = getTimePointSize. is going to have some serious overhead.
comment:4 Changed 18 years ago by jmoore
- Status changed from new to assigned
Decision:
PixelBuffer will get a stateful service (RawPixelsStore?) which holds on the acquired ome.model.core.Pixels and the ome.io.nio.PixelBuffer? instances for performance reasons.
comment:5 Changed 18 years ago by jmoore
- Owner changed from jmoore to callan
- Status changed from assigned to new
Initial version committed in r731. Needs testing, etc. Chris, can I turn this over to you now? (Ha, doing it anyway.)
comment:6 Changed 18 years ago by jmoore
- Cc brain added
Working test in r738 : RawPixelStoreTest. All methods not tested, but remoting/sessions/etc. should now work.
comment:7 Changed 18 years ago by cxallan
- Status changed from new to assigned
Okay, need to implement the "to byte array" method now to have this thing be semi-complete.
comment:8 Changed 18 years ago by cxallan
- Resolution set to fixed
- Status changed from assigned to closed
Completed in r763.
comment:9 Changed 18 years ago by jmoore
r783 adds this to source:trunk
The relevant api calls seem to be:
MappedByteBuffer?getRegion(Integer size, Long offset);MappedByteBuffer?getRow(Integer y, Integer z, ...MappedByteBuffer?getPlane(Integer z, Integer c, Integer t);MappedByteBuffer?getStack(Integer c, Integer t);MappedByteBuffer?getTimepoint(Integer t);public void setRegion(Integer size, Long offset, ByteBuffer? buffer);public void setRow(ByteBuffer? buffer, Integer y, Integer z, ...public void setPlane(ByteBuffer? buffer, Integer z, Integer c, ...public void setStack(ByteBuffer? buffer, Integer z, Integer c, ...public void setTimepoint(ByteBuffer? buffer, Integer t);The PixelsService methods only come into play if we are doing this stateful. We can start off stateless, and see if the creation overhead of the PixelBuffer on each call is significant. A first, stateless solution would be caching. This means all the PixelBuffer calls get a pixelsId as the first parameter.
Of the PixelBuffer methods, a few changes need to be made. All the ones returned MappedByteBuffer need to return byte[]. Make sense? Also, all the duplicate methods taking a ByteBuffer will be omitted. (A setRow(byte[]...) is missing, however.)
As long as the methods are going to be stateless, I'll add them to the existing trunk/components/common/src/ome/api/IPixels.java@723.