|
|
Rank: Advanced Member
Groups: Member
Joined: 6/22/2008
Posts: 11
Points: 33
|
I'm probably missing something really simple here.
I'm using a multiLayerViewer, and adding ImageVObjects to it. What I want to do is apply Tranforms and Effects to the currently selected ImageVObject. I'm having difficulty finding how to do this. Transforms all seem to take bitmaps as an argument in the ApplyTransform methods, and obviously ImageVObjects don't have access to bitmaps directly through any methods or properties.
Could someone point me in the right direction to getting transforms, (Contrast, Redeye, Emboss etc), working on an ImageVObject.
Thanks.
|
|
Rank: Advanced Member
Groups: Administration
, Member
Joined: 1/31/2005
Posts: 386
Points: 403
|
Hello,
No, its not you. Actually it is feature which is not accessible in current version. If you want to change ImageVObject, you should apply necessary transform to the original image and recreate it.
Another way is to create an subclass and implement such features inside it.
Best wishes, Alex.
|
|
Rank: Advanced Member
Groups: Member
Joined: 6/22/2008
Posts: 11
Points: 33
|
Hi alex,
Thanks for the reply, I did email support as well. Andrew suggested 3 methods.
Using the Draw method of the object to draw to a bitmap, transform, replace the orginal object with the transformed bitmap, (which I was part way through implementing).
Using reflection to access the data (get access to the _image variable of the ImageVObject), transform then replace the original object with the transformed bitmap.
Subclassing.
I decided on method 2 and am using reflection to get the data, apply the transform to the bitmap and then replace the object, which seems to be working well, and more effectively than the draw method, (for me anyway).
Tyler
|
|
Rank: Advanced Member
Groups: Administration
, Member
Joined: 1/31/2005
Posts: 386
Points: 403
|
Hi Tyler,
Yes, it is good idea. Reflection is a sort of "unfair" tool, but in your case it is a quite reasonable choise ;).
Best wishes, Alex.
|
|
Rank: Advanced Member
Groups: Member
Joined: 3/3/2008
Posts: 47
Points: 141
|
May I know why draw is expansive. I plan to do something like that....please advice...
|
|
Rank: Advanced Member
Groups: Member
Joined: 6/22/2008
Posts: 11
Points: 33
|
Sorry for the delay, I've had my head in code.
Ok, draw for me wasn't the best option because I personally found the reflection method, was quicker to implement, and gave me more flexibility, (I did end up subclassing as well, for something else... I think the draw method would have impacted on this). As it stands now, I have all the functionality of a BitmapViewer, available on vObjects. I did try writing back to the vObject bitmap... But that caused all sorts of memory locking problems. So I'm staying with replacing the existing object.
My next challenge is serialised data. My app is generating enormous files, I need to find a way to reduce file size, and not impact on performance, or quality. Yeah I know I don't ask for much right? :)
|
|
Rank: Advanced Member
Groups: Member
Joined: 6/22/2008
Posts: 11
Points: 33
|
I'm being a little bit bloggy here, hopefully this info will help someone else.
Turns out that subclassing and reflection were both good choices, I was able to implement an optimizing routine in the ImageVObject subclass that examines the image, determines what size it's going to print at, and then resize the image down if needed to a given dpi value, (eg 300dpi).
I was using scaling to manipulate the file size, of course if you add three 4 meg jpgs to the MLV, (3504x2678 pixels), then serialise that layer, you wind up with a seriously big file, (I'm talking over 70 meg here).
So right before serialisation, go through all the images, work out if their image size, (gained through reflecting the _image private variable in the ImageVObject), is bigger than needed, and if it is, resize the image to the required size.
I managed to reduce file size from 70 meg, down to 13 by doing this alone, which makes things much more manageable.
|
|
Rank: Advanced Member
Groups: Administration
, Member
Joined: 1/31/2005
Posts: 386
Points: 403
|
Hi tcrosbie,
Thank you for your posts here, I think they can be really helpful.
As for locking issues - we both know that using reflection here is actually a small hack. It's not a bad, I think that each of us uses them from time to time ;).
And in the solution you described above (resize before serialization) reflection gives simple and efficient solution - I think I like it. The only thing I want to warn you - do not use serialization for long-term storage. Internal serialization format is a subject to change in future versions of the Graphics Mill for .NET.
Best wishes, Alex.
|
|
Rank: Advanced Member
Groups: Member
Joined: 6/22/2008
Posts: 11
Points: 33
|
Hi Alex,
Thanks, I am aware of the dangers of using serialisation as a long term solution, it suits my needs right now, (quick, effective), but I will be looking to use another method for permanent storage.
For caching purposes serialisation is working very well, and removes a lot of memory hassles for me.
Tyler
|
|
|
Guest |