From kde-kimageshop Sun Jun 03 15:03:47 2007 From: Boudewijn Rempt Date: Sun, 03 Jun 2007 15:03:47 +0000 To: kde-kimageshop Subject: Re: First step for GSoC: the Painterly Color Mixer. Message-Id: <200706031703.50405.boud () valdyas ! org> X-MARC-Message: https://marc.info/?l=kde-kimageshop&m=118088307801803 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============1705722626==" --===============1705722626== Content-Type: multipart/signed; boundary="nextPart1717222.pkBqyQFU0j"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart1717222.pkBqyQFU0j Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 01 June 2007, Emanuele Tamponi wrote: > The mixer takes the footprint of the paintop. Then the > footprint is mixed with the underlying colors. Optionally, the > result is automatically set as the current color of the > paintop. Okay... That could work. You'd need to have three paint devices, then: * paint mixer canvas paint device (contains all the mixed paint * dab paint device inside the paintop (you don't do anything with this=20 directly, but we need to think (later) about integration of the canvas with= =20 palette knife and oil bristle brush paintops) * the temporary paintop the paintop deposits the dab on. This works similar= to=20 indirect painting in our brush tool. Also, you'd need to be able to distinguish between paintops that do bidi pa= int=20 transfer (i.e., mix paint themselves) and paintops that don't (i.e, you mix= =20 the result yourself). So, you'd have something like KisPaintDeviceSP mixerCanvas; canvas->addPainterlyOverlay(wetness); canvas->addPainterlyOverlay(...); =2E.. (add all painterly overlays KisPaintDeviceSP paintRecipientCanvas; paintRecipientCanvasp->addPainterlyOverlay(wetness); =2E.. (add all painterly overlays) if (paintOp->supportsBidiPaintTransfer()) { =2E.. (copy the rect under event from the mixerCanvas to the=20 paintRecipientCanvas, similar the temporary target in KisToolFreehand) } KisPainter gc(paintRecipientCanvas) gc.setPaintOp(currentPaintOp); gc.paintAt(mouse event location) (the paintop either perturbs the original data in the paintRecipient or doe= s=20 its own thing) if (!paintOp->supportsBidiPaintTransfer()) { mixPaintDevices(paintRecipientCanvas, mixerCanvas); } > To do this, we need to know the nature of the current paintop: > we expect that a pencil mixes colors in a different way > respect a brush; and this just because the brush is wetter > than the pencil. Either paintops do support mixing by themselves, or they don't -- that's th= e=20 important difference. If they do, then the difference between the new bidi= =20 enabled pencil paintop and the new bidi enabled brush paintop will come abo= ut=20 automatically. > But current brush and pencil paintops (to make an example) > don't have any painterly properties, so the mixer doesn't know > about their wetness. On the other hand, there will be some > paintops that do have painterly properties. > My idea is: for all non-painterly paintops, the mixer guesses > about their wetness using their ids. For painterly paintops, > the mixer takes their properties using KisPaintOpSettings. That's a good idea: it could be done in what I temporarily called=20 mixPaintDevices(src, dst) above. That method only needs to be called for=20 paintops that don't have mixing built-in. I'd add the supportsBidiPaintTransfer() to KisPaintOp first, with a default= =20 return value of false. Then implement mixPaintDevices(); > First issue: we don't want to respect exactly current paintop > settings: for example, it's better if we use a different size > for the paintop, and, if the current dab of the paintop is a > pattern, we will ignore it (we mix colors, not peppers! ;) and > take a default color instead. Sorry, I don't parse... Settings like opacity aren't that interesting, for = the=20 mixer. The size does matter, but that's automatically done right if you fee= d=20 the paintOp the right pressure settings. > Another issue: the bidirectional paintop that I'm going to > implement will interfere with the behavior of the mixer. In my > opinion, his "bidirectionality" (excuse me for the term :) has > to be deactivated while you use it in the mixer. I think it can replace the default mixing behaviour of the mixer :-) > To do all this, my idea is: > - While on the mixer, we will change the paintop settings to > those set on the paintop (for now, this is just the size of > the paintop, but perhaps we will come up to other settings > to change). size is not a paintopsetting: it's something the paintop computes using the= =20 dab() method from the pressure values it gets from KisPaintInformation obje= ct=20 you need to create from the data from the pointer event. > - Draw the paintop footprint in a white dab (this way, the > bidirectional paintop can't do its stuff). > - Guess the paintop wetness using its id. > - Mix up the color on the dab with the color in the mixer > canvas. > - Record the changes in wetness that occurs in the canvas. > - As user option, automatically set the resulting color as the > current paintop color. > To clear a frequent equivocal: the mixer doesn't need a > painterly overlay! The overlay provides a lot of extra, > interactive functions that in a mixer (that just need to *mix* > colors) are going to be not useful, if not even not wanted. I think of adding painterly overlays to the mixer as a kind of "next step".= =20 However, you cannot record changes in wetness without painterly overlays:=20 that's where we store variables like wetness. I guess that in essence the paint mixer is nothing more than a specialized,= =20 simplified canvas (only layer only) with a specialized tool, namely one tha= t=20 mixes the temporary canvas onto which the paintop paints with the layer=20 canvas if the current paintop doesn't implement bidi paint transfer. Whether it's a good idea to make the painter mixer widget implement=20 KoCanvasBase and the mixing tool KoTool is another thing, but I'd be inclin= ed=20 to set it up that way. =2D-=20 Boudewijn Rempt=20 http://www.valdyas.org/fading/index.cgi --nextPart1717222.pkBqyQFU0j Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBGYthWdaCcgCmN5d8RAo0fAKDheQAU25eM51qssX6j7TUbuBtU6wCghjxu pA1ropgYJVHCJJw8yaohJqM= =3VI3 -----END PGP SIGNATURE----- --nextPart1717222.pkBqyQFU0j-- --===============1705722626== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ kimageshop mailing list kimageshop@kde.org https://mail.kde.org/mailman/listinfo/kimageshop --===============1705722626==--