, it
reveals
(one) artist's view on blend modes.
Cheap-skate bonus: the book is out of print (e.g. 15€ @ terrashop.de)
have fun,
yahvuu
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp
://yahvuu.files.wordpress.com/2009/08/gradient-editor-horz.png
It also features a color inspector to save the tedious extra-click for opening
the color pop-up.
regards,
yahvuu
*) How to keep all the current features on top of this model is another
question,
and, of course, what's really desired
some discussion, or maybe get a
GIMP developer who happens to like my idea to flesh it out into a real
spec.
I believe the gradient editor can be prototyped as a plugin (e.g. in python),
as all necessary API is published. If that helps...
regards,
yahvuu
(and resides in GIMP core), and a second plugin which resides
in the plugin registry and solely installs the menu entry.
Makes sense?!?
regards,
yahvuu
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU
items as well. Scratching
your
own itch can become difficult in large projects.
Disclaimer: i'm not a GIMP developer, so this may very well be a good idea at a
bad time
or simply a bad idea by itself.
regards,
yahvuu
___
Gimp-developer mailing list
working full-time should not result in a huge boost for the project.
regards,
yahvuu
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
/completed_grants
Several developer-years have been granted, mostly
dating back to the early 2000s (surprise :-)
regards,
yahvuu
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp
On 13.09.2010 15:28, Rupert Weber wrote:
On 09/13/2010 01:05 PM, yahvuu wrote:
btw, the red returned from the current GEGL implementation is too dark:
[..]
I am proposing the attached tiny patch to correct that
yep, that yields the desired RGB triple 255, 179, 128 for the example under
On 13.09.2010 11:47, Alexia Death wrote:
No. Just... no. XOR needs to die. Badly.
just curious: what coloring options exist to enshure sufficient background
contrast
when drawing non-XORed/anti-aliased?
thx,
yahvuu
___
Gimp-developer mailing list
handling the result, truncated to sRGB, will be:
(1.0 0.700.50) * 255 = 255 179 128
hopefully i'm not needlessly complicating things,
yahvuu
[1] to quick'n'dirty test the gamma-correct conversion,
gegl/gimp-gegl-utils.c:61 can be modified to:
case 3
of available dialogs and thus no decision has to be made about which
menu to use... That is, paraphrasing what Sven said.
Also, interesting to note how differently the word 'dialog' gets perceived.
bye,
yahvuu
___
Gimp-developer mailing list
Gimp-developer
redesign -- there is a whole lot more to do than just releasing
the dockables from their current hiding place and distributing them over the
menu structure. (E.g. what use is in displaying the brushes dockable while
the gradient tool is active? etc..)
regards,
yahvuu
the superfluously created image. I think it should simply paste into
the current layer.
Perhaps Tools-Screenshot Maker...
or Extras-Screenshot...
or even Edit-Paste Screenshot... ?!?
regards,
yahvuu
___
Gimp-developer mailing list
Gimp-developer
(and interaction)
of all
these different entities via their grayscale representation. But that surely
doesn't
imply to stuff everything into a single dialog -- which falsely suggests
similarity
of quite different concepts.
rant finished,
yahvuu
___
Gimp-developer
wouldn't oppose if someone wanted to get code
providing this functionality included into GIMP .-
regards,
yahvuu
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
On 18.08.2010 19:55, Rob Antonishen wrote:
To complete the set, here is a non-Gaussian blur with an x blur of 40
px and a y blur of 0.
thank you, new URL is
http://yahvuu.files.wordpress.com/2009/08/blurtest2.png
regards,
yahvuu
___
Gimp-developer
for a good term which shortens colors that are specified
using
device independent color specification -- that is either by using a device
independent
color space, or by using a device dependent color space plus the corresponding
device
color profile.
regards,
yahvuu
,
yahvuu
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
On 12.08.2010 13:09, Rupert Weber wrote:
On 08/11/2010 11:20 PM, yahvuu wrote:
Me, too, thinks that sRGB is a reasonable assumption. If you want to Do It
Right(tm),
you will have to take the image's color profile into account. Since most, if
not all
8-bit implementations of color
the gamma curve defined by sRGB.
regards,
yahvuu
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
of _each and every_ one of the
tool, filter and
blendmode routines.
So, i think GIMP should Get It Right for GEGL processing, while certain
deviations of
operations' characteristics are tolerable for 8-bit processing.
regards,
yahvuu
___
Gimp-developer
On 12.08.2010 16:16, Graeme Gill wrote:
yahvuu wrote:
I guess pretty much everyone agrees that ideally the color profiles of
imported images
should neither affect layer blending nor any tool's characteristics.
The whole point of color profiles is to describe how to interpret the
device
On 12.08.2010 17:20, yahvuu wrote:
than on import. I mean, if the device color profile isn't known, the
data can't even be displayed
without getting misinterpreted, left alone proccessed.
oh, stop. Got it myself: e.g. for profiling the screen.
Give me a second chance .-)
regards,
yahvuu
2nd take:
On 12.08.2010 16:16, Graeme Gill wrote:
yahvuu wrote:
I guess pretty much everyone agrees that ideally the color profiles of
imported images
should neither affect layer blending nor any tool's characteristics.
The whole point of color profiles is to describe how to interpret
or export Lab data you need to know the whitepoint to
interpret to the data correctly. Layer modes, in contrast, are used purely
internally,
so the chosen whitepoint doesn't really matter here.
regards,
yahvuu
[1] http://www.poynton.com/PDFs/coloureq.pdf
[2] http://en.wikipedia.org/wiki/CIELAB
.
That's a different beast from a python shell.
I think it explores some interesting ideas which might also be applicable for
GIMP,
so here's a better link to showcase how it works:
https://wiki.mozilla.org/Labs/Ubiquity/Latest_Ubiquity_User_Tutorial
regards,
yahvuu
/
regards,
yahvuu
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
smaller itches.
regards,
yahvuu
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
aware of two postings which already
touch the same problem [2,3]. Improvements are always welcome.
That being said, the canonical workaround is to align to the window border
or to another window, if necessary.
regards,
yahvuu
[1] http://gimp-brainstorm.blogspot.com/
[2]
http://gimp
rely on the compression feature of the backup software?
regards,
yahvuu
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Omari Stephens wrote:
On 03/13/2010 02:41 PM, yahvuu wrote:
But how to avoid the overhead when such files are to be archieved?
After all, URLs tend to throw 404s after a while.
Just rely on the compression feature of the backup software?
I think the answer is easy: provide a way to strip
on export here.
c) The layers analogy applies, but can be used with a slight twist:
File formats that don't support profiles can be regarded as formats which
don't
support other color spaces than sRGB. So export should silently auto-convert
by default.
regards,
yahvuu
[1]
https
-bit processing anyway.
This is my understanding of the current state of color management. If something
qualitatively
different is happening, can you please give an example of how results might get
deteriorated?
regards,
yahvuu
[1] http://lists.xcf.berkeley.edu/lists/gimp-developer/2009
-- without one having to dive into the
preferences.
regards,
yahvuu
*) There are two more variants which should require less coding than
the on-canvas approach and still offer smooth workflows:
Adjusting the color space conversion boils down to two steps: 1) undo the
last import
and 2
key + left/right mouse drag still works here.
regards,
yahvuu
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Alexia Death wrote:
windows key + left/right mouse drag still works here.
Is that something that has a chance to work in KDE?
yep, i'm running Kubuntu here.
regards,
yahvuu
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https
spaces, so some reasoning is provided. Without a chance to
compensate
for the length, a short summary is preprended. At the bottom, a direct reply to
the spec [1] is given.
regards,
yahvuu
In short:
- Every GIMP composition (aka XCF) has a color
space.
(They may well be outside of display gamut as well..)
everything IMHO,
yahvuu
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
is really important,
a second monitor means additional calibration cost
and an additional potential source of error, i guess.
regards,
yahvuu
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo
Hi,
here are some diagrams depicting selected configurations for colormanagement:
http://yahvuu.files.wordpress.com/2009/08/dataflow.png
While not yet a set of uses cases, i think these diagrams will
be useful when discussing the use cases.
Please let me know in case you spot errors or think i
that importing unmanaged data
and creating unmanged data on export might be unrelated.
For example, 2b) might be a photographer that opens a ClayRGB file from
his archive and exports a JPG without any profile information, for web use.
regards,
yahvuu
___
Gimp
color spaces. The very same color may have different
RGB values in different color spaces. Assuming a calibrated monitor,
the color picker displays absolute colors, so i think the RGB values
should change, not the colors.
regards,
yahvuu
___
Gimp-developer
it into the posting)
regards,
yahvuu
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
hi all,
this is work in progress, mostly in analysis stage and a bit chaotic,
but there are already some conclusions which might be worth discussing.
any comments appreciated,
yahvuu
From the product vision follows a tightly coupled workflow as default,
where each file should have a profile
be eased if users are supported to specify
workarounds, like: 'camera xy' + 'filename starts with _' = AdobeRGB.
Sort of heuristic device drivers.
regards,
yahvuu
PS: I think the scope of your questions is actually more of UX. As you said,
the pure technical solution is to popup when inference
Martin Nordholts wrote:
On 02/02/2010 02:40 PM, yahvuu wrote:
Thanks, I've uploaded a new patch with this addressed.
thank you for caring about this stuff!
will check it out..
Ideally, the tabs would gracefully degrade when there's not
enough space available. For increasing number of tabs
of trying to be clever i think it's best to
display only the icon as default (with tooltip) and
allow the user to customize as before.
regards,
yahvuu
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU
Liam R E Quin wrote:
On Tue, 2010-01-19 at 22:38 +0100, yahvuu wrote:
[...]
II. Range of actually useful values for IJG quality value
For GIMP's target users less than half of all possible settings
are useful:
possibly - I've often used values as low as 35% or sometimes lower
than its current
position inside the advanced parameters section suggests.
Photoshop is the reference here -- it automatically switches
from 2x2 to 1x1 subsampling for the higher quality settings [4].
regards,
yahvuu
[1] https://lists.xcf.berkeley.edu/lists/gimp-user/2010
.
regards,
yahvuu
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
to set all tabs to a certain style.
Individual tabs still can be configured to a different style, if needed.
The ideal location for such a command would be the context menu
of the empty space to the right of the tabs...
regards,
yahvuu
___
Gimp-developer
- you can make
the first image RGB again by going to it and hitting undo, but as
soon as you go back to the 2nd image, the 1st image goes grayscale
again.
i can confirm, with default image size 610x377,
gtk 2.18.4
glib 2.22.3
and yesterday's git master
regards,
yahvuu
Martin Nordholts wrote:
yahvuu wrote:
Martin Nordholts wrote:
Liam R E Quin wrote:
(1) File-New, make an RGB image, e.g. 377x233px in size.
paint a smiling face in red.
(2) File-New, choose Advanced Options and make a grayscale image
(I made mine 377x233px).
(3) Notice how
* thankful it didn't inform me about that until i asked for it.
regards,
yahvuu
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
.
An interesting option to migrate such a GEGL editor into GIMP is to make it
a standard plugin which hosts its private GEGL tree -- embedded into the
GIMP tree..
regards,
yahvuu
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https
not really shure: are there other common workflows which build selection
masks
that are more complex than just a rectangle and still dispose the mask
afterwards?
regards,
yahvuu
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https
,
yahvuu
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Ilya Zakharevich wrote:
On 2009-10-21, yahvuu yah...@gmail.com wrote:
The analogy was given to show why the the current interface to blending
(i.e. choosing among a discrete set of layer modes) is a poor one:
And my message was intended to show why the current interface is a
very good one
://lists.xcf.berkeley.edu/lists/gimp-developer/2009-October/023432.html
greetings,
yahvuu
[1] http://yahvuu.wordpress.com/2009/09/27/blendmodes1/#curves
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU
Ilya Zakharevich wrote:
On 2009-10-03, yahvuu yah...@gmail.com wrote:
Using an analogy, the current situation for blending is like not
having the curves tool, but only preset curves to choose from. And
indeed there's a relation between curves and blending, for each RGB
blend mode can
. Seriously. The most annoying buggy
software is buggy software which you expected to work flawlessly.
As Ilya points out, it's legitimate that users blame the GIMP project.
So i think a warning upfront can reduce the frustration, and
also communicate the responsibilities a bit.
regards,
yahvuu
hi again, knitting some dropped postings together...
peter sikking wrote:
yahvuu wrote:
actually a question for peter (yahvuu): how complete is this
overview?
most notably, the porter-duff modes are not listed.
I'll have a look to make the overview as complete as possible.
I am
graphical issues using an ASCII mailing list.
greetings,
yahvuu
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
peter sikking wrote:
actually a question for peter (yahvuu): how complete is this overview?
most notably, the porter-duff modes are not listed.
I'll have a look to make the overview as complete as possible.
first, I know now why our Darken section is one Shorter that our
Lighten one: we
of sheets, then it's most natural to insert
(photographic) filters in between. Say, a colorizing red glas
or a freaky effect lens, in general: an adjustment layer.
thanks for the encouraging comments,
yahvuu
___
Gimp-developer mailing list
Gimp
hi,
peter sikking wrote:
to have a reason to add these icons to GIMP, they really have to
add something for usability, not just be different enough icons that
happen to be similar in their group. what the icons have to deliver
is additional _user_insight_ into the modes, in addition to the
://sites.google.com/site/yahvuu/stuff/layermode-icons-preliminary.tar.bz2
makes sense to anyone?
greetings,
peter
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
tester [1], by setting opacity values for
'MouseDown' and 'MouseMove' to zero.
greetings,
peter
PS: a dhtml version is also available from [2]
[1]
http://sites.google.com/site/yahvuu/stuff/brushtester-web.lzx.swf8.swf?attredirects=0
[2] http://yahvuu.wordpress.com/2009/09/09/brush-tester
hi,
peter sikking wrote:
- it is fantastic to see a fuzzy/grunge brush as a real
copy of the actual brush when one is not painting, but it has to
_contrast_ with what is under it or else it just disappears. When it
contrasts (some X-OR variation, or so) I think it should not be semi
hi,
David Gowers wrote:
On Sun, Sep 13, 2009 at 10:22 AM, Rob Antonishen
rob.antonis...@gmail.com wrote:
Peter-
To clarify, you are suggesting the on screen pointer icon/sprite could
show the actual brush as it would look painted with a single mouse
click, but once painting/holding the
:
http://sites.google.com/site/yahvuu/stuff/brushtester-web.lzx.swf8.swf?attredirects=0
Other designs can be tested with a download version from
http://yahvuu.wordpress.com/2009/09/09/brush-tester/
simply replace the PNGs (e.g. tester*.png) or
edit brushes.xml and hit the reload brushes button
hi,
what about using a dashed outline for fuzzy brushes?
perhaps like a) in
http://yahvuu.files.wordpress.com/2009/08/fuzzy-outline.png
I think it's rewarding to visually mark fuzzy outlines / feathered selections,
as it opens the path for on-canvas adjustments -- as has been pointed out on
the
hi,
SHIRAKAWA Akira wrote:
yahvuu wrote:
hi,
what about using a dashed outline for fuzzy brushes?
perhaps like a) in
http://yahvuu.files.wordpress.com/2009/08/fuzzy-outline.png
This is a very good idea, but I think it would be more logic and
consistent with the style of brush outlines
hi,
from a long-term perspective, i expect resources to be shared easily
'on the cloud', with each resource item identified by a GUID.
Then, the read-only system files are just a local cache of some of the
available resources on the internet. Also from this perspective, it becomes
strange to
hi,
Danko Dolch schrieb:
A node view is your friend and sould not be hidden from the user - just
entry level users have a better understnding from a physical pipeline
based view than a complex layer tree...
But Rome wasn't build in a day either - I know - first things first ;-)
well,
hi all,
here's a (totally unbiased ;-) summary from the previous composition rendering
thread, intended as a discussion base:
1. Rendering happens on demand:
a) when a composition gets displayed on screen (of course)
b) on export. Here usually the full resolution gets rendered.
= no
hi,
peter sikking schrieb:
[..] the rest is technical detail
and for actually contributing developers to figure out.
Of course, non-devs thinking about technical issues are at
high risk of generating bogus discussion. On the other hand,
the project has traditionally been open to thoughts from
hi,
Nicolas Robidoux schrieb:
At start-up, the user could be presented with a list of unfinalized
workspaces, and asked whether to finalize each, or open each.
just for clarification: by workspaces you're referring to nip2 workspaces,
which roughly translate to GIMP compositions, correct?
hi,
Martin Nordholts schrieb:
On 07/07/2009 01:35 PM, yahvuu wrote:
I see two poles for the rendering strategy, both of which have downsides:
- eager rendering: render as soon as possible, latest when
saving the composition
Hi yahvuu
I don't see why the whole
hi,
Tobias Ellinghaus schrieb:
Am Mittwoch, 8. Juli 2009 schrub yahvuu:
[...]
The user sends a JPEG to a colleague for review -- takes 2 hours to render.
The image is OK, the user creates a TIFF for the print shop -- takes 2
hours again.
I think in this case, the user would be better
hi,
Danko Dolch schrieb:
Oh interesting topic!
To decide for a good composition rendering strategy I would suggest to
take a look at some verry similar applications like motion compositig
software.
very interesting input, indeed!
IMHO to render is exactly the word describing whats
hi,
Danko Dolch schrieb:
What about taking the cache with you? e.g. switch to another workstation
- would be cool to have an option to store the cache external too...
cool, yes. But even more corner cased than the case of very expensive
compositions already is for GIMP.
yahvuu wrote
hi,
Tobias Ellinghaus schrieb:
[..] Thus the cool things like several sources or forward
edges (think of a bumpmap on a layer which uses the same layer as source) are
not possible.
GEGL has a 'clone' operation that should enable what you're seeking.
Have a look at the example with the same
hi all,
with GEGL's ability to only render what is visible on the screen
(and ideally in that very resolution) we are comfortably spoilt
for choice by when to render a composition to full resolution.
While saving the user's work -- which amounts to the GEGL tree -- can
be done quite quickly
hi,
Nicolas Robidoux schrieb:
I don't think that using the word rendering in a menu will be
self-explanatory for non-sophisticated users when used in a save
context.
oh yes, indeed. 'Creating full resolution...' is probably less suspicious
but won't solve the problem. The ugly part is that
Hi all,
periodical autosave is long standing demand (bug 138373).
While in my regard this is headed in a totally wrong direction [1],
there's nothing wrong with having a plugin that works this way.
Somewhat suprisingly, i couldn't find such a plugin, so here's some
dirty PyGIMP which at first
hi,
Alexandre Prokoudine schrieb:
On Thu, Jun 25, 2009 at 4:55 PM, yahvuu wrote:
In mid-term i see GIMP going the database-driven path anyway [3],
While in the shortterm tools like dropbox get hot :)
why shure, dropbox is an example of what can be gained on the database-driven
path. It's
hi all,
as this issue stays intricate, a brainstormish thought:
clearly, Save must result in an XCF getting written somewhere (unless the
operation gets cancelled).
This doesn't rule out that e.g. a JPG gets exported in the process.
So in the last resort we could abstract away the export/save
hi,
peter sikking schrieb:
(peter) yahvuu wrote:
there's one thing i don't understand, may be a misconception:
why is it necessary to have separate modes for editing the RGB data
and the plates?
mainly because creating art on a RGB monitor, to be used on
many media, is not the same
hi,
Chris Mohler schrieb:
Imagine I'm designing a black t-shirt with say five spot colors,
including white.
[..]
Whew ;)
Whew, too ;) Makes me wonder if it has to be that hard or if
it points to some missing software improvements. Trying to understand
the example, i hope you don't mind some
Hi all,
there's one thing i don't understand, may be a misconception:
why is it necessary to have separate modes for editing the RGB data
and the plates?
For example, if i have an RGB image in the composition and want to apply
'value curves', that has to be done in the RGB area, for after
hi all,
here's a description of GIMP's basic image manipulation model
from a UI point of view that i'd like to share:
http://yahvuu.files.wordpress.com/2009/05/gimpmodes1.pdf
This is intended as inspiration for user interface thoughts
rather than being thorough documentation. Originally planned
Hi,
Daniel Johannsen schrieb:
I only like to add, that in the layer group it is the alpha value of the
lowest layer in the group
which provides the masking effect for the grouped layers above.
(And not a layer in the middle or on top of the group.)
hmm, special-casing the bottom layer seems
Hi all,
On Sun, May 17, 2009 at 10:39 PM, Daniel Johannsen
d...@danieljohannsen.de wrote:
Solution suggestion: A parent base layer determines alpha values for a
dependent stack of child layers above the base layer.
Then the last layer on top of the child stack e.g. could be the
athmosphere
Hi all,
peter sikking schrieb:
foo.png was never inside GIMP. it was an xcf that had foo.png as a
starting point. we try to reflect this in every way. one way that came
up during LGM discussions was that the layer should be always
(even for background) be named after the image that was
Hi all,
David Gowers schrieb:
When Martin said that, I thought that just means it's inappropriate
for us to make the decisions. It doesn't mean we shouldn't do research
-- in fact, I'm sure Peter Sikking would appreciate it.
Hence, I've CCed this to the list.
yep. Me too regards this as
Hi all,
peter sikking schrieb:
- png bKGD. looks to me it should be honoured on import
(as file creating import, that is), no extra dialogs please.
I tend to say it should not be used (by default) on export.
a set bg-color-layer should be merged into the pixels. but
then there is
Hi all,
peter sikking schrieb:
and I do not really follow what you wrote in there.
I do have the feeling we draw different conclusions.
indeed, obviously we draw different conclusions from the very same specs.
Here's my take on why png bKGD is complementary to any (future) element of XCF:
Hi all,
peter sikking schrieb:
but some crucial things depend on the bg color.
the gradient tool being the big show-stopper for me.
the tool needs a redesign, but up to then the fg-bg
type of interaction looks to be the most (universally)
usable to me.
i think the gradient tool would work
Hi,
Sparr schrieb:
I just want to point out that PNG supports a background color (and the
GIMP plugin to save PNG offers an option to save the current brush
background color as the image background color), and being the only
format to do so we should probably consider its specified functions
1 - 100 of 115 matches
Mail list logo
