#135 closed defect (fixed)
psImageTrim need to realloc buffer or not?
| Reported by: | Owned by: | Paul Price | |
|---|---|---|---|
| Priority: | high | Milestone: | |
| Component: | PSLib SDRS | Version: | unspecified |
| Severity: | normal | Keywords: | |
| Cc: |
Description
Should psImageSubset be making a shallow subset/trim, while the psImageTrim
does a hard subset/trim?
If then when psImageTrim is performed, does it resize the image buffer or
leave it alone (wasting the difference of sizes in memory but saving in time)?
If we were to add an additional attribute to the struct holding the raw buffer
location (and maybe size), one could perform a trim (or an psImageSubset?) by
just resetting the row pointers. FFT transforms would be required to be
tweaked (to handle the row stride, an advanced feature in FFTW3), but it looks
not to be a much of a problem.
What do you think?
-rdd
Change History (9)
comment:1 by , 22 years ago
| op_sys: | Linux → All |
|---|---|
| rep_platform: | Other → All |
comment:2 by , 22 years ago
If psImageTrim is used to modify a psImage, just shall be done with any of the
children?
I could reset the appropriate attributes (col0, row0, and data pointers), but
what is to be done if part or all of the image subset no longer will exist
after the trim?
-rdd
comment:3 by , 22 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Your interpretation of the two (Subset vs Trim) is correct: Subset is soft and
Trim is hard. For the third question, note that psImageTrim is creating a new
buffer representing the trimmed data. The new psImage should have no children
at all, and the children of the input image should not be affected by the operation.
comment:4 by , 22 years ago
| Resolution: | fixed |
|---|---|
| Status: | closed → reopened |
You say that psImageTrim is creating a new psImage, though the SDRS says "Trim
the specified image in-place, which involves shuffling the pixels around in
memory". This SDRS explanation strongly suggests that a new psImage should
not be made. Please clarify the SDRS if your intent was for psImageTrim to
create a new psImage instead of shifting pixels in-place within an image.
-rdd
comment:5 by , 22 years ago
discussing it here, it seems there was disagreement. I was totally wrong, the
SDRS was totally right. the trim should be done in place, and all children and
parents will have to be dropped.
comment:6 by , 22 years ago
| Owner: | changed from to |
|---|---|
| Status: | reopened → new |
comment:7 by , 22 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Added to the SDRS:
"Any children of the input image shall be freed by \code{psImageTrim} before the
trim takes place."
comment:8 by , 22 years ago
| Keywords: | VERIFIED added |
|---|
Should be fixed in SDRS-07 and ADD-06 (7 September 2004).
comment:9 by , 22 years ago
| Keywords: | VERIFIED removed |
|---|

Looking at the SDRS, it is plain that the desire of psImageSubset was not to
make a copy of the pixel data, but rather just regenerate the row pointers to
allow indexing into the original image as a subimage.
This required, however, the addition of another attribute in the psImage
struct to store the base of the data buffer (as so a subset image can know
where to psFree the data buffer properly). I named the attribute
'rawDataBuffer' and stuck it at the bottom of the definition.
I verified that other psImage* functions still work with this shallow copy, in
particular, psImageFFT (as the resulting image data of the psImageSubset is
not continguous in memory); everything works now with a bit of tweaking.
-rdd