Better brush/image remap workflow

[GoogleCodeExporter]

Hi there !

I wish I could easily add colours to the image's palette and place them where I 
want.
I tried the described steps to merge a tile from the spare page into the sprite 
sheet of the first page, and it tried was matching the colurs of the tile with 
the palette of the first image.What I actually wanted was Grafx" to take the 
colours of the tile and *add* them to the plaette of the first image either 
manually or automatically.Since I use to start with a clean palette (purple for 
colour one, and all the other colours white), I would love to be able to just 
add and place the colours of the spare page (or a brush I grabbed from there) 
to the first page and have GrafX2 remap the colours to the white (unused) 
palette colours,and remap the brush so it uses "its own, imported colours" 
which got added to my page 1 palette :)
So the workflow would be:
1.Load image to page one
2.Load image to page 2 (different palette)
3.Grab brush from page 2
4.Switch to page one
5."Your brush has a different palette than this image, do You want to add the 
brush colours to Your palette and remap the brush ?"

The result would be that page 1 has the former plaette plus the new colours 
added and the brush look the same as before, only that its colours have been 
added to the palette and shifted to match with the last *used* colour of the 
former palette.

You could also call it "mergecolours" if You want...

Thanks,
Emmanuel

Original issue reported on code.google.com by eh...@gmx.de on 30 Jun 2010 at 10:57

[GoogleCodeExporter]

Thanks for explanation. DawnBringer also has critics on the current 
color-swapping actions, since "Recolorize" loses precision on each swap, and 
"Get brush colors" is extremely limited in usefulness.

I think all needs would be met if the following was implemented:
1) Internal: Grafx2 keeps at all times a copy of the brush that uses original 
color indices, and a copy of the original palette.
2) 'Recolorize' is modified, it uses the original brush data to accurately 
recolor the brush according to the current image's palette.
--> It means you can grab a brush, recolorize to black-and-white in a page, 
then go back to original page, and recolorize it to original colors, no data is 
lost.

3) A new user setting to automatically perform a Recolorize when you swap 
pages. (Maybe also after a Undo/Redo). It's just to avoid typing F12 every time 
you swap.

-> With the above changes, it's already much easier to navigate between two 
screens that have different palettes.

4) Modify "Get brush colors": Perform an action similar to what you described :
- Reads the original brush pixels and colors (how it looked when you grabbed 
it) to determine the necessary colors.
- Locate these colors in the current image's palette
- If some colors are not present, add them in unused slots
- Then perform a Recolorize, to update the current palette

Compared to what you described, the only difference is that the step 5 is when 
the user presses F11 (default shortcut for "Get Brush colors")

This is still rough idea, many complications can exist, ex: tolerance for 
matching colors, and how the Brush transparency index can be handled.

Original comment by yrizoud on 30 Jun 2010 at 12:07

[GoogleCodeExporter]

Original comment by pulkoma...@gmail.com on 9 Aug 2010 at 9:43

• Added labels: Component-Tools

[GoogleCodeExporter]

Original comment by pulkoma...@gmail.com on 22 Aug 2010 at 1:39

• Added labels: Mil

[GoogleCodeExporter]

Original comment by pulkoma...@gmail.com on 22 Aug 2010 at 1:39

• Added labels: Milestone-2.3
• Removed labels: Mil

[GoogleCodeExporter]

Started experiments with this. It's a rather large-scale change.
The brush container needs be changed a lot (the smarter methods seems to be: 
memorize the unmapped bitmap and original palette, have the screen draw the 
preview using a dynamic lookup that lives only while the screen is open.)

Original comment by yrizoud on 26 Jan 2011 at 9:36

• Added labels: Level-Hard

[GoogleCodeExporter]

Progressing well : I've changed all the code that altered the brush size : 13 
places found. Now it systematically uses Realloc_brush(). This removes a lot of 
redundant code (150 lines) and makes it much easier to locate the places where 
the change will take place.

Original comment by yrizoud on 27 Jan 2011 at 10:09

• Removed labels: Level-Hard

[GoogleCodeExporter]

Great, it's welcome!

A few thoughts:

1.
"It means you can grab a brush, recolorize to black-and-white in a page, then 
go back to original page, and recolorize it to original colors, no data is 
lost."

Hm, not sure this is logical...once a brush has been recolorized, isn't the new 
(current image's) palette my "real" one? Still, it might be useful.

2. About adding colors from a brush to another palette. I've been thinking 
about this and it could be done with a script (taking the brush-color values 
from spare-palette) along with some nice preference settings. So if this seem 
too messy to implement in the system...we can always just make script.

Original comment by annas...@hotmail.com on 27 Jan 2011 at 4:27

[GoogleCodeExporter]

1: The whole point is that if you don't like the current state of the picture 
after a Recolorize, you can add more useful colors in the palette, Recolorize 
again, and see if it's better. Without need to go back to spare page and 
re-grab. Same thing with Text tool with colored pixel fonts : it will be 
instantly recolored to your own image's palette, but you can tweak the palette 
many times and Recolorize to see result, it will always try to find closest 
match to the font's palette.

2: The existing "Get brush colors" needs be removed or replaced by something 
useful, anyway.

Original comment by yrizoud on 28 Jan 2011 at 1:15

[GoogleCodeExporter]

Lots of work done in r1703.
All operations that only move pixels around (swap, rotate, resize...) preserve 
the original pixels/palette. Outline, Nibble, and modifying brush from Lua 
script make it "adopt" its current visual appearance and the image's palette.
Loading a brush automatically remaps it. Maybe it should only do it when the 
user has set auto-remap...
Manual remap (F12) works perfectly.
Get brush colors (F11) works extremely well for importing brushes from other 
images into current image. It doesn't say anything when palette is full, maybe 
it should have a message...

Still Todo: make the Text tool import the font's palette.

Original comment by yrizoud on 30 Jan 2011 at 1:09

[GoogleCodeExporter]

1. Lasso is broken, brush pick-up gets corrupted.

2. Transparent color does not remap / change its index. Not sure if this is old 
or new or what's really right here, but consider this: You pick up a brush, 
transparent color is x which is ugly-pink. You add the brush's palette to 
another image (including the ugly-pink). Now you change the selected background 
color...the brush's transparent area is now (solid) index x of the current 
palette and not ugly-pink, even though it's in the palette.

3. I notice that very many images become corrupted when loading them as brush 
or even crashed the program. I rarely load brushes so I can't tell if this an 
old or a new problem.

Original comment by annas...@hotmail.com on 30 Jan 2011 at 3:23

[GoogleCodeExporter]

1: Is fixed, thanks for seeing it!
2: Grafx2 has always used transparent index = current BG color; I've made issue 
81 to propose a bahavior closer to Deluxe Paint. In the example you gave, "Get 
Brush colors" should probably not import the ugly-pink, since it's not a 
'visible color'.
3: I've not seen this problem so far, I'll need test on a machine less 
forgiving for memory errors.

Original comment by yrizoud on 30 Jan 2011 at 3:09

[GoogleCodeExporter]

Original comment by pulkoma...@gmail.com on 15 Feb 2011 at 8:12

• Added labels: Milestone-2.4

[GoogleCodeExporter]

Arbitering issues that make it to v2.4

Original comment by yrizoud on 8 Mar 2012 at 7:18

• Added labels: Milestone-2.5