Creating windowShapes in Rev

[Dar Scott]

On Tuesday, December 30, 2003, at 01:02 PM, Ken Norris wrote:

> What's really needed is a full-blown image processor plugin, eh?

Yeah.  And maybe based on a library.

> ------------
>> I have something, but it is ugly and really needs nested arrays.
> ------------
> Nested arrays? Do you mean you are creating some paint tools to 
> accomplish
> these tasks? Perhaps by examining what's under the tool point, 
> changing the
> arrays and redrawing when you save?

I got a little mixed up.

I want to have an image type or value.  An array as representation is a 
problem because I can't do this (at this time):

   get tint( over(img1,img2), 20)

So the first thing I want is to allow arrays to be full values.  I want 
a function to be able to return an array and in the same expression 
allow the array returned to be a parameter for another function.

I thought about putting pixel values into a nested array, but it might 
work to leave them at the highest level.  The problem with that is that 
full array operations would not work.  So, if pixel values are arrays, 
then it would be good if all the functions I need are array operations.

However, I have done well with packed numerical "arrays" that are 
implemented as binary strings.  The problem here is random access in 
changing values.  I have a feature request in that would make this much 
faster.  It would apply to any case of a substring being replaced with 
a string of the same length.

So any of those three wishes will help and all will.

However, if I finish this up, and I don't have those, then I will 
probably use "boxes" (arbitrarily nestable chunks that can be strings 
or binary or numbers or arrays) and I need to rebuild that.

> ------------
>> You might also consider taking a picture with export snapshot to a
>> variable and then looking for white or some other color to make
>> transparent parts in the final picture.
> ------------
> If I 'export snapshot' into an 'image' will it automatically convert 
> to an
> image format, i.e., Rev's own 1-byte proprietary format?

I don't know.  I export to a variable as PNG.  I suspect this is the 
same as a PNG file, but I have not checked.  I set the text property of 
the image to the variable value.  An image shows up.  I don't know 
about the proprietary format.

I have gotten the impression that an image is stored as the original 
form and that is exploded for imageData, maskData and AlphaData, and 
perhaps for display.  If the image is modified then the exploded image 
is compressed as PNG.  I can be compressed as other formats when saved 
to disk.  The fact that there is both maskData and alphaData might mean 
there are alternate internal compressed formats or they might be 
historical.  I think I heard something about the first.  This is all 
much more than I know and is all guessing and vague memories.

By 8-bit do you mean a color table?  Does this mean I can lose colors 
if I modify an image with lots of colors and then save it?

> If so, then I think I see a little of what you mean. If we use a 
> proprietary
> method, we *should* be able to do this:
>
> 1) If we can 'export snapshot' into an image, it should produce an 
> 8-bit
> image rectangle with white pixels outside the paint area to the edges 
> of the
> rectangle.

Except I don't know about "8-bit", I'd say yes.

> 2) Use the maskData property to set all the white pixels to 
> transparent.

Yes.  You can also apply this to images you import.  You might also get 
a little more complicated and consider colors almost white and pixels 
with a very low alpha.  Some images have picture or other data under 
transparent portions.

> 3) In order to facilitate a mask I can understand when I see it, I 
> will want
> to change all non-transparent pixels to black (or some other 8-bit 
> color to
> distinguish it from overlaid images for alignment purposes) during the
> process.

That is OK.

> You still have to go through every pixel and re-render, right?

Yes, but in the simplest case, you build a new maskData based on image 
data.  It will be fastest to accumulate in order.  This build does not 
need to know the height and width (formatted) because it makes a pixel 
transformation.

> All this could be solved with a zoom control, a lasso tool, and some 
> pixel
> controls in Rev's Paint Palette, so that's on my wish list.

I think Photoshop has a magic eraser that effectively is a pour 
(paint-bucket) with a transparent color.  Something like that or 
allowing a transparent background would address this.  Or allow 
selecting transparency (alpha) in colors.

> I understand that in this case there is nothing but an image ID to set 
> the
> stack to, but IMO it's still an unexpected deviation from the usual 
> syntax.
> I mean, looking at a script, you could easily mistake setting the 
> stack to
> another stack ID or something, without the designation of "image" or
> "stack".

I thought that since an image ID is specified and not an image that the 
windowShape would follow the image.  That is a change to the image 
would show up in the windowShape.  In my quick experiment with the 
eraser, that was not the case.

Dar Scott