yang686526

clipping path in rasterimageproc
clipping path in rasterimageproc
hi,
during vectorization, for raster images having clipping paths we get the uvboundary parameter in rasterimageproc() as non-null and also the numboundpts parameter > 0. the uvboundary is null for non-clipped images.
however for both clipped and non-clipped images, following the call to rasterimageproc(), we always get a call to our polylineproc() (with image boundary in case of non-clipped images and the clipping path in case clipped images). is this behavior because of the kind of files we are creating or are we guarenteed to get this sequence of calls always?
the reason i ask this is: in our application, in case of clipping, we are applying the clipping path to the image in rasterimageproc() itself. so for clipped images we end up with 1 raster image + 1 clipping path + 1 non-clipping path. while for non-clipped images we only get 1 raster image + 1 non-clipping path.
so i was wondering whether this was the right way to go, or should we modify the polylineproc() to make the path clipping in case of raster images. this would give us a more consisent behavior in our app as we'd always get 1 raster image + 1 path (clipping or non-clipping) for each image in the drawing.
we don't want to lose the clipping information and hence would only like do this if we're guarented a call to polylineproc() in the said case.
thanks

quote:
however for both clipped and non-clipped images, following the call to rasterimageproc(), we always get a call to our polylineproc() (with image boundary in case of non-clipped images and the clipping path in case clipped images). is this behavior because of the kind of files we are creating or are we guarenteed to get this sequence of calls always?
it depends on raster variables, associated with the database (see dbrastervariables.h). depending on imageframe() raster variable, image frame may be turned off, may be drawn below or above the raster image.
quote:
the reason i ask this is: in our application, in case of clipping, we are applying the clipping path to the image in rasterimageproc() itself. so for clipped images we end up with 1 raster image + 1 clipping path + 1 non-clipping path.
it seems i missed to understand something.
in this case you should end up with 1 raster image + 1 clipping path (you should get it through polylineproc). where from are you getting 1 non-clipping path? from vectorization pipeline? if so, does odamfcapp renders this sample correctly?
also, what is the your task? (rendering? import?)
sincerely yours,
george udov
hi george,
imageframe raster variable is what we were looking for. thanks a lot for the pointer.
we're performing import and not render.
the problem we face is that if the imageframe is turned off, then all we get is the rasterimageproc() call (no polylineproc() call). in that case to implement the clipping we have to generate a new clipping path in the rasterimageproc() itself. anyway, thats more of a design issue specific to our application.
while implementing this we also ran into a small trouble that the clipping coordinates passed are off by -0.5. for example in the attached file, the image is 179x176 and has simply show clipped set to yes in autocad (no explicit clipping coordinates were given). the parameters passed to rasterimageproc() were:
numboundpts = 2
uvboundary = {(-0.5, -0.5), (178.5, 175.5)}
when what we really were expecting were
uvboundary = {(0, 0), (179, 176)}
any thoughts?
thanks
attached files (12.4 kb, 3 views)


quote:
while implementing this we also ran into a small trouble that the clipping coordinates passed are off by -0.5.
it is a feature of autocad, that we've reproduced.
rasterproc() implementation in our gs devices (e.g. exgigdigeometry::rasterimageproc) shifts coordinates by (0.5, 0.5) before "real using".
sincerely yours,
george udov
thanks.
we'd already got it working by using 0.5 shift. just wanted to know if there was a more elegent solution.