Layer system about grafx2 HOT 31 CLOSED

[deleted comment]

[deleted comment]

for the layer system: I would advise to take into consideration the way artgem
handles them from a user-interface point of view as well as actions on them.

as PulkoMandy suggested me, I'm providing more info on ArtGem layer system (as 
long
as I've succeeded in installing it under wine, if you need it just ask me, I've 
got
the 1.3 trial version).
Here you can find a screenshot of ArtGem:
http://peach.smartart.it/private/screenshots/screenshot-artgem-1.png
on top left you can find the always visible layer stack, and immediatly under it
there's the layer editing menu.
On the small layer stack you can see that there number of layers is fixed (16) 
and
you can see that a filled layer (like the first) is blue, the second layer is
activated (orange), while the third is deactivated (blue/embossed).
The editor window is quite simple: there're some functions similar to those 
present
in grafx2 palette editor: select, invert, copy and merge. Very easy.
Apart from the editor there's another small menu where you can do more or less 
the
same operations you can do with brushes: flip/flop, clear, select from alpha, 
invert
and obviously show/hide.

Some notes: obviously introducing layers means having alpha channel working, 
and more
than that having a grafx2 file format to store layer information, since gif 
don't
save it.

I think I've nothing more to add, for anything else just ask me.

Thanks for the informations :)

About tranparency, actually we have different possibilities for that :

1) use a simple "magic color" transparency, like for brushes. You select a 
transparency color for the layer and use the 255 other colors to draw on it.

2) use a real alpha channel. this will cause problems because if you use 
certain 
transparency levels with certain colors, we will not be able to display that 
properly on our 256 color screen.

3) use 2 layers with low color count and low precision alpha channel (for 
example, 
16 colors, and top layer always 50% transparent. This allows to display the 
result 
accurately, but is horrible to work with. The only use is to build pictures to 
display by flicking on old computers to get the impression there are more 
colors 
(see the climax demo on amstrad cpc for an example, or odd stuff on a plain 
atari st 
(not ste)).

I would prefer the first solution, as the idea is to have a simple way of 
keeping 
different objects on the screen, while being able to move them to rearrange the 
picture. I don't see an use for real 255 level alpha channel. If we don't want 
to 
limit the user to 255colors/layer, we will have to store the alpha channel 
separately (it could be done at 1bit per pixel but that would slow down 
calculations...)

FInally, the layers will probably be part of our animation system. The idea is 
you 
draw a layer in one frame, then you can make it move, rotate, distort or resize 
by 
inserting keyframes whith just these transformations. Or you can change the 
pixel 
data at some point.

I think 1) and 2) are the most viable solutions.

The 1) means something slightly different than the one used for the brushes, 
instead
of removing 1 color from the palette I'd go for a out-of-bound RGB color
representation, something like (-1, -1, -1) or (999, 999, 999). Keep in mind 
that I
don't really know how code-wise the colors and image are handled, but I think 
this is
a quick and dirty solution that internally will work flawlessy.

The 2) solution is somewhat future-wise, but as well harder to implement. 
Actually an
alpha channel means an additional 256 levels opacity channel, and the color
representation will be expanded like (X,Y,Z,0) for solid colors and (X,Y,Z,255) 
for
transparent. This could be useful only if you're planning to support RGB (non
indexed) images, otherwise is futile and -as you already stated- can give you 
more
headaches when semi-transparent colors are blending when layered (or maybe not).

Actually I'd go for 1) and I am against the limiting the colors to 255 and 
reserve 1
color for transparency instead of using an OOB representation. Obviously IMHO :)

All the images are stored in 8-bit, so we cant go out of the 0-255 range. 
That's why 
we have to use a color for transparency if we go for solution 1. If you want 
all the 
256 colors available, we have to store the alpha somewhere else, even if it's a 
boolean for each pixel.

00.rgb.studios: The program uses 24bits for RGB palette entries, so there's no 
out-
of-bounds values. It matches what can be done in the GIF (many layers) and PNG 
format (one layer).

I agree with the 1). Just like when I draw sprites, I reserve one color entry 
for 
transparency (usually #0), and set it to a distinctive RGB value that I can 
easily 
separate from normal drawing colors.

GIF is suitable for saving/loading a layered image, however it's not a good 
display 
format since it has horrible support in IE, Firefox, and almost all the image 
viewers that I know (1.6 seconds to display a 16-kayer image, loops even if it 
shouldn't...). So even if the working format is GIF, you should "flatten" it 
for 
viewing purpose.
Maybe we can store the "resulting" image as the first frame, and try to make it 
stay 
forever...but I don't think it's well supported either.

so my question is: what is the gif specs telling about transparent gifs? should
transparency be implemented as the 257th "color" or used a reserved color? (BTW:
isn't it in the TODO list? did I miss anything?)

about the file format (maybe we could even move on the ml to continue talking 
about
this), if you want to stick to GIF can use the animated gif format for saving 
the
layers, otherwise use PNG indexed specs (if I'm not wrong it should support 
layers,
but I think it really depends on how widespread is its implementation -as for 
GIF
layers).

In issue 110 I listed what PNG and GIF can do. A normal transparent GIFs has 
255 
colors + transp.

PNG doesn't have layers, according to:
http://www.imagemagick.org/discourse-server/viewtopic.php?f=1&t=12311

An idea: the number of layers doesn't matter for performance.
When drawing in the worst-case scenario, there are N layers above the drawing 
layer,
and M layers below the current. The N layers can be represented as a single 
layer of
what obstructs the view (like the current Mask mode), and we can pre-compute 
that by
merging them beforehand.
I the same way, the M layers represent what we will uncover if we fill the 
current
layer with "transparent", and this is a single solid image that we can also 
pre-compute.

Drawing only modify current layers (not above or below), so these two mergings 
only
need to be done when the user changes layers, the performance during drawing 
will not
depend on number of layers.

Work is in progress in the svn branch branches/layers.
For normal drawing, performances seem still good even on my old machine, but I 
know
that the drawing is about 2x more expensive in terms of cpu time (RAM 
read/write,
actually).
I'm afraid the performance drop would be fatal for people with machines even 
slower
than mine, so I'll try to keep the branches alive and separate for as long as 
possible.

Here's work in progress version, so you can test speed on your machine. (DO NOT 
USE
FOR REAL DRAWING - file saving is not tested at all) Almost all tools are 
adapted to
take layers into account already, only some specifics like the "copy to spare" 
and
palette remappings are not done.
This version has hard-coded 8 layers (even after loading an image, there are 7 
empty
layers above it). Keys are 1 to 4 and Shift-1 to Shift+4 to select and toggle 
the
layers 1 to 4, respectively. Color index Zero acts as transparent to see 
through layers.
Due to tiny bug at the moment, when program is started, the Undo/Redo system 
will not
update the screen if you've not switched main/spare at least once (TAB key).

Is it 1-4 on the numpad or the regular keyboard ?
In both case, it does not seem to work for me, or maybe i'm missing something...

(azerty + linux, btw, compiled from the branch)

Sorry, it's "as usual" qwerty or Windows or both.
You can edit the keys for the transparency, it's the ones I recycled: Set 
percents 10
to 80. The first four are for activating layer 1-4, the other four are for 
toggling
visibility of layer 1-4

Much-debugged version.

I like the wrap of the layer when moved. The shift+1 etc hotkeys aren't changing
anything for me. 1051 release.

To keep support for platforms that are too slow to use the layered drawing, the
solution might be to use #define sections to cleanly disable expensive 
computations.
I'll have a closer look, it seems a better solution than maintaining the two 
branches
forever.

Can't they just be disabled when there is only one layer ?

It affects the pixel-drawing functions, and during expensive draw operations 
these
can be called many, many times per second. I don't want to add an extra 'if', 
or even
a function pointer indirection, each time. It would be slower than both 
branches.

Latest build. Fixes PNG saving, adds layer merging and re-ordering.

I'm sorry for being silly, but how do I get to work with layers? :P
I DL-ed the new versions but nothing happens when I press the Layer keyboard
shortcuts from the HELP. 

No it's my fault, I still don't find good UI to dispay feedback for user 
actions :/
Load an image or draw something, then press Alt-Insert to lay one empty layer 
over it
(it will become the active layer too) Scribble a little, then see what happens 
when
you draw with color 0.
If you use Alt-Insert more than once, you have that many layers to draw on, so 
the
shortcuts for toggling layer 1, 2, 3 etc. start working.

Here's attached a ready-made test image with 8 layers. Good to test the layer 
select
/ toggle keys.

This is now finshed :)
Congratulations Yves for all the work !

Some more bugs to fix :/

Yes but it's time to open new bugreports for them I think...

Is the Layers button (that says 'layers manager') supposed to do something when 
I
click on it?
This is somewhat confusing. If it's not implemented yet, it would be nice to 
get a
dialog box telling me so rather than silently doing nothing.

Nothing plugged to this button yet. It may or may not have a menu at some point 
in
the future.
This is what you get for using WIP builds, but don't worry it will be fixed for 
the
stable release.