Original issue title: When using a background layer, switching to
Indexed Color Mode fills all layer bounding rectangles with
Color 0.
Conditions to reproduce the original issue:
- Opaque RGBA sprite, i.e. the bottom layer is 'Background'.
- There is a second layer with an ellipse (for example).
- There is a mask color #000000 alpha=0 is in the palette.
- The mask color index is greater and not equal than 0.
- Go to Sprite > Color Mode > Indexed.
Result: the transparent color of the second layer will change to
index color = 0 (usually black).
Also added test for RGBA->INDEXED conversion
Before this fix, the lua command:
app.command.ExportSpriteSheet
could not process a layer within a group when the layer name
was expressed using the layer hierarchy path, for example:
layer = "Group1/Layer1"
We can select the default color or tile from preferences depending if
we're going to paint pixels or tiles
Fixes a confusing logic from 4a91d150af97e70e588e82d698dc8c5e0db8e6fe
where the bg color was obtained from preferences only when the fg
color type (rgb/gray/index/hsv/tile/etc.) was equal to the bg color
type from the preferences (rgb/gray/index/hsv/tile/etc.).
To reproduce the error before this fix on RGBA/Grayscale Color Mode:
- New 100x100 RGBA/Grayscale opaque sprite (white background).
- Draw something with some gray color in the palette.
- Keep the selected gray color as primary color.
- Configure as secondary color the mask color (#000000 alpha=0).
- Pick 'eraser' tool and erase over the gray color with right click.
- Result: The sprite doesn't look more opaque, which is wrong. Also,
if we export this sprite, the transparent parts will turn black.
A similar problem occurs in Indexed Color Mode, but getting a
transparent color in a Background sprite is inevitable if the color of
a palette entry is transparent or semi-transparent, since the index
must be set as is. This could be fixed in the future at the
render stage, however, this could lead to other perceived
inconsistencies. For now it'll be left as is.
Original issue description:
Downloaded PNG in RGB mode fails to support transparency: erase
uses secondary color and export PNG replaces transparent color
with black
Added tests for 'eraser' in 'Replace Color Mode'
To make the eraser work in 'Replace Color Mode' within the tests,
was implemented the possibility of using the right button in
the creation of the point vector.
During testing with UI available it was observed that the 'bg' color
was copied from the 'fg'. Changed this to be compatible with the way
the default value of 'fg' is assigned when it is not specified.
This last modification resulted in errors during 'tilemap.lua' due to
incompatibility of the type of 'bg' color. This was corrected
considering the color type of 'fg' color.
Furthermore, it was found that the command 'app.range.tiles = { 1 }'
did not finish assigning the tile picks to the activeSite,
then 'assert(1, #app.range.tiles)' was failing. This was fixed too.
Added other color comparison criterias (fit criteria) during
color mode conversion RGBA to Indexed or Grayscale to Indexed.
The 'fit criteria' will help us to recolor an RGB image with
a limited color palette taking into account different color
perception criteria (color spaces: RGB, linearized RGB,
CIE XYZ, CIE LAB).
Before this fix, a multi-layer mask movement/scaling (with mixed layer
types: normal layer and tilemap layers with different grids) caused
loss of drawing areas.
The heart of this solution is to correctly align the 'selection mask'
and 'transform data' according to the layer's grid, and also, forcing
'site' TilemapMode/TilesetMode before each
reproduceAllTransformationsWithInnerCmds() iteration.
During the life of a PixelMovement object there is a tilemap mode lock.
Additionally arrow keys now work to move a selected area in
TilemapMode::Tiles.
This was originated for #1279 (CLI-only Aseprite) which can be
achieved with LAF_BACKEND=none anyway.
In this way we simplify the development process, and checking for the
availability of the GUI can be done in run-time through App::isGui()
or Context::isUIAvailable().
Now we use the LAF_BACKEND=none/skia to detect if it's going to be the
CLI/GUI version of the program. The ENABLE_UI flag is still defined at
compile-time just to avoid removing all #ifdef/endif conditional
directives right now.
select_layer_boundaries was affected by a change made to Mask::fromImage
where a hardcoded threshold was changed from 128 to 0. To make
select_layer_boundaries behave as before, I've added a new parameter to
Mask::fromImage to set the threshold and then use the same hardcoded
value it was using (128)
This new variant returns an image from a specific layer's frame.
Also a copy_masked_zones() function was created to contain with the
common code for the new_image_from_mask variants
Before this fix, the 'Cancel' command did not work in the following
specific situation:
As soon as Aseprite was started and without hitting the 'Esc' key,
the 'app.command.Cancel()' command did not perform any operation.
It was discovered that the Cancel command is started only once per
session and retains the 'm_type' throughout the session. Only
a specific:
app.command.Cancel {type = "all"} or
app.command.Cancel {type = "noop"}
could change the command type.
With the introduction of Widget::processMnemonicFromText() in
17151cddcd25ab089f5d2ffcc9ec680ba6cd57bf we don't require these
functions anymore because the '&' character isn't not present in the
widget text (so we can just measure the text length as usual).
This was discovered in PR #4604:
https://github.com/aseprite/aseprite/pull/4604#discussion_r1731172284
We have to fill/use the X position of each char box instead of
calculating it through the width of each glyph (because each advance
is different from the glyph width in isolation).
