great this gets tracked down.
One minor suggestion, a simple renaming:
Export...=> Export as...
Save back=> Export
this way, 'Export' resembles 'Save' as a one-click-action
and 'Export as...' parallels 'Save as'.
Additionally, the association between 'Save' and safe is kept con
oops, just recognized i'm replicating a previous post, sorry
yahvuu schrieb:
> One minor suggestion, a simple renaming:
> Export...=> Export as...
> Save back=> Export
___
Gimp-developer mailing
Hi,
peter sikking schrieb:
> I must also point out that this save + export change is also a
> change in attitude for GIMP. it clearly supports that our high-end
> users work in no-loss xcf all the time (if they want to store
> results) and that also means avoiding doing things like merging,
> flat
Hi,
Chris Mohler schrieb:
> I can express any CMYK color in RGB - but not the other way around.
now i'm confused :)
Is CMYK->RGB->CMYK roundtrip safe?
>From past examples (trapping, rich black) i've come to think that
hand-optimized CMYK separations can't be transformed back
to RGB losslessly (q
Hi Peter,
some ideas from a typical photo workflow:
perspective correction- select some prominent lines from the image
and "get them straight"
alignment of horizon line - in cooperation with an automated guess?
crop & rotate, set- virtual photography ala
hi,
David Gowers schrieb:
>> gradation map - nearly the same: map image points to positions in the
>> gradient
> Yahvuu, you probably need to clarify: how is this different from
> Colors->Map->Gradient Map?
sorry for the misspelling. Exactly Colors->Map->Grad
Hi all,
Louis Desjardins schrieb:
> Guillermo Espertino a écrit :
>> Even though I agree that most of the CMYK cases mentioned use CMYK
>> almost as spot colors, I can think of a very common usage scenario in
>> Graphic Design where you need to be able to edit CMYK directly:
>>
>> Corporate colors
Alexandre Prokoudine schrieb:
> 2009/3/27 Guillermo Espertino wrote:
>
>> Also, in this discussion it seems that it was never considered that you
>> can be working on images that somebody else sent you and you don't
>> control how they were created.
>> If somebody sent you a separated tiff of a ma
Hi all,
my previous posting does not stand a quality test, to put it mildly.
To save the list from multiple nearly indentical follow-ups,
i thinks it's best to bundle my replies here.
My apologies for the noise.
yahvuu schrieb:
> Thanks to GEGL's dynamic nature, the sRGB->CMYK
Hi all,
Sven Neumann schrieb:
> So why do you assume that a crop tool would
> allow you to enlarge the image?
with GIMP becoming a non-destructive editor at heart, i think
it's natural to expect cropping to work non-destructively, too.
Then it's more like selecting a frame for an (conceptually)
Hi all,
reading through some discussion which steps on "default alpha for layers?" and
"erase to alpha or to white?" questions, there's one solution i haven't seen
yet:
assign a background color to GIMP images. Not a layer, just a single color.
This way, the eraser can always work on alpha, and
Hi all,
peter sikking schrieb:
> I like the innovative nature of the idea.
it would not be without a hint of irony if, after 40+ years of digital image
processing,
GIMP were the first to finally introduce the concept of a background color ;-)
And i'm not aware of a raster file format which featu
Hi,
David Gowers schrieb:
> What happens when we want to save a 24bit png with no alpha from a
> single layered image? how is this detected?
> The current distinction between layers with and without alpha channel
> allows the user to make that clear..
A set of good rationales is IMO:
GIMP is an
Hi all,
David Gowers schrieb:
> One bump I see is things like "Cut" and "Float" -- quite often I want
> them to fill the source area with a solid color rather than with
> transparency. When this doesn't happen, it's awkward (as the layer)
in terms of the model under discussion, this is a shortcut
Hi,
David Gowers schrieb:
> On Mon, Apr 27, 2009 at 2:20 AM, yahvuu wrote:
>> Hi all,
>>
>> David Gowers schrieb:
>>> One bump I see is things like "Cut" and "Float" -- quite often I want
>>> them to fill the source area with a solid
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 functio
Hi,
saulgo...@flashingtwelve.brickfilms.com schrieb:
> Perhaps I am misunderstanding this proposal, but the ramifications
> seem to be more confusing than the present method. And while I realize
> that GIMP does not make any guarantees about retaining the colors of
> transparent pixels, its
Hi,
David Gowers schrieb:
> Hi saulgoode,
>
> On Tue, Apr 28, 2009 at 12:29 PM,
> wrote:
>> If a PNG is loaded as a layer, should the "image background color" be
>> updated to the PNG file's background color? or should it remain what
>> it was originally? If a JPEG is loaded as a layer, should t
Hi,
David Gowers schrieb:
> Yahvuu's proposition is essentially
> a) have a 'virtual layer' always at the bottom of the stack, filled with a
> color
> and
> b) make all layers have an alpha channel
>
> Nothing more.
Yep.
Just in case this rooted a misunderstanding, i'd like to add that
the eras
Hi all,
Alchemie foto\grafiche schrieb:
> The possibility to add "CUSTOM " layer modes [..]
that sounds interesting. Just curious: i wonder how custom layer modes
differ from filters that take a second layer as input (e.g. LIC)?
i mean, other than that filters currently work destructively.
gree
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 ther
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 w
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
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,
On Sun, May 17, 2009 at 10:39 PM, Daniel Johannsen
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 color" for the silhou
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 see
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
f
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
separat
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 mon
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 som
hi,
Tobias Ellinghaus schrieb:
> Am Samstag, 20. Juni 2009 schrieb yahvuu:
>
> [...]
>
>> Can you give an outline how the print color for that text will be
>> specified? The RGB color isn't useful here and the text layer can't be
>> accessed while the p
hi,
Chris Mohler schrieb:
> On Sat, Jun 20, 2009 at 11:27 AM, yahvuu wrote:
>> i assume the temporary layers are mostly grayscale?
>
> Usually RGB layers, or grayscale channels.
sorry, imprecise question. I mean, if you use a temporary RGB layer,
it's content will 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 d
hi,
after some more thinking, here's my reasoning why indeed 'Save' is the problem.
This becomes clear in comparison with a database-driven, version-controlled
approach
as e.g. sketched in the last mockup of [1]. A Save command is superfluous in
this
scenario. When an image gets edited, it's re
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 da
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 (assu
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 t
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 gla
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,
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.
>&g
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 w
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.
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 sam
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,
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 hide
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 b
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 l
e look and feel, here's a flash applet
featuring various outline designs:
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 PN
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 sem
hi,
David Gowers wrote:
> On Sun, Sep 13, 2009 at 10:22 AM, Rob Antonishen
> 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 mouse down it wo
ssed (stylus is touching surface
> and moving)?
you may try this with the brush 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/br
y patch is also available:
http://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
:
if a layer is just a transparent sheet, and a composition is just a
projection of a stack 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 comment
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
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
> L
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 lis
els somewhat anachronistic to discuss
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
Ilya Zakharevich wrote:
> On 2009-10-03, yahvuu 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
&
7;
disclaimer as a nag-screen. 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 respons
ndmodes-popup-array1.png
... just brainstorming..
greetings,
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 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
picture says more than a hundred words" springs to mind. I think it's pretty
much impossible to meet the requirements for useful layer mode icons, though:
http://lists.xcf.berkeley.edu/lists/gimp-developer/2009-October/023432.html
greetings,
yahvuu
[1] http://yahvuu.wordpress.com/2009/0
I'm 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.Berk
w - i guess prior to 0.0.18 or so.
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-devel
s for me.
I'm *very* 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
t image size 610x377,
gtk 2.18.4
glib 2.22.3
and yesterday's git master
regards,
yahvuu
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
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->
a command 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
___
their own dodge/burn, blur/sharpen, grain merge/extract tools etc.
regards,
yahvuu
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
III. Parameter Triaging
The "Subsampling" parameter is more important 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 s
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'v
s on the actual size of the tabs.
So, instead 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
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 availab
.
Possibly that pain [1] can 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,
ing the point, but ..." was in my head but didn't make 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 prof
no image is open.
But the same problem still occurs when switching between images with
different working color spaces. The very same color may have different
RGB values in different color spaces. Assuming a calibrated monitor,
the color picker displays abso
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 m
nd why 2a and 2b are separated.
the goal was to make explicit 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 w
ce. Gamut warnings
indicate when they are outside the current working 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
in those places where color 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:/
ant be moved.
windows 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.XC
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
aged primary workflow and the secondary workflow,
which moreover may be unmanaged -- 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 c
king space, but that's unavoidable
with 8-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://list
ly with the principle of least surprise.
From assuming sRGB on import follows conversion to sRGB 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
throw 404s after a while.
Just 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 answe
]. I'm 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]
ddresses the other, much smaller itches.
regards,
yahvuu
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
learned-from-ubiquity/
regards,
yahvuu
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
On 10.08.2010 00:16, Jon Nordby wrote:
> On 9 August 2010 23:42, yahvuu wrote:
>> Just a quick and cheap thought:
>> if you're talking about search, that means i'm already using the keyboard to
>> type in
>> what i want to do, and then we're only one ste
"" Often, in practice, the white point is assumed to follow a standard and is
not
"" explicitly stated
Which means, if you import or export Lab data you need to know the whitepoint to
interpret to the data correctly. Layer modes, in contrast, are used purely
internal
pedia.org/wiki/Scrgb].
regards,
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
>>
1 - 100 of 125 matches
Mail list logo
