Re: [Pipmak-Users] Imaging manipulation methods

[Christian W. <cwa...@gm...>]

Andrea Viarengo wrote:
> I'm start a new tread, because I cannot manage to visualize your last reply
> in gmane (but only in nabble)
> which across the two mailinglist (start from "devel" end go to "user")

You're right, the post shows up on devel instead of user in Gmane's web 
interface. Weird. Guess I have to break the thread next time I do such a 
thing.

> About image manipulation,
> I understand that loadimage() come from last pipmak version, when image 
> manipulation was not possible, and you want preserve its old behaviour.

Right.

> With the Adding the constructor newimage("/path/image.ext"),
> loadimage could become obsolet and maintained only for backward compatibility.

Not really. According to my latest proposal, its name becomes obsolete 
(because it's misleading now), but its functionality persists under the 
new name "getimage". Although this will continue to be mostly used 
internally and rarely by users (usually, users specify a file name and 
Pipmak converts it to an image object itself).

Reusing the same image data rather than reloading it from disk over and 
over again is crucial in situations like the following, so I'm not going 
to give this up:

hotspot { onhilite = function(self, hilite) patch:setimage(hilite and 
"hilited.png" or "normal.png") end }

> Another possibility could be adding method:
> image:copyfrom("/path/image.ext")

Right, that would be more versatile than the extended "newimage" 
function I proposed. How should differing sizes of the source and 
destination image be handled in this case? Would the source image just 
be copied to the top left corner of the destination?

In addition, that function could also take an existing image object 
instead of a file name. Then you could save intermediate stages of your 
image composition process and reuse them (whether that's really useful I 
don't know).

> and next
> 
> image:copyfrom("/path/image.ext",x,y,w,h)
> 
> permitting the loading of a image file just in a limited portion of the
> newimage, this will be very usefull, instead using a lot of patches to
> create composed image.

I'm not sure. I intended not to encourage people to do the thing you 
describe, for efficiency reasons. In the current implementation, it 
means copying around a lot of image data in main memory, while 
composition of images could also happen on the GPU, as is currently the 
case when you use separate patches.

Actually, allowing users to draw onto images loaded from files already 
violates that principle (except for the case of using image:fill() with 
alpha < 1 to cut holes). As you may remember, I didn't even anticipate 
that use when I started designing image manipulation - my expectation 
was that you would draw on a patch and place that above the unmodified 
image.

But maybe I should do some actual profiling before jumping to 
conclusions about efficiency. Actually, I can think of cases where 
composition on the CPU would probably be more efficient.

> I don't known if having object carrying modifiable and unmodifiable image
> could be a good idea...I think could confuse newbies... 

Perhaps. Although newbies probably won't deal with getimage (loadimage) 
at all. I'm still leaning towards that solution, however, because it 
would also take care of the missing-alpha-channel bug, and it would be 
easier to implement than the alternative. The copy-on-write solution 
that would make all images mutable from the point of view of the user, 
while still taking advantage of data reuse internally, could still be 
implemented in 0.3 or a later version.

Thanks for your input!

  -Christian