Re: [Gimp-developer] The toolbox Wilber problem
Hi, Sven Neumann wrote: > don't you guys get it? I get it - I'm just disappointed by it. I shall refrain from beating the dead horse any further. All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Feature request: no-image-open window remembers position as well as size
Hi, I've just been playing a bit with 2.6, and have a request. When the last image is closed, the no-image-open window snaps back to whatever size it was before the first image was opened - which is great. Could we take that further and make it snap back to its previous position, as well as size? I like to have GIMP open in between editing, with the toolbox and dock full of dialogs on the right-hand-side of the screen in a neat column - this leaves plenty of screen usable for browsing images, and leaves GIMP accessible for dragging-and-dropping images. As it stands, with 2.6 I either have to have the no-image-open window cluttering the main part of the screen, or I can tuck it neatly out of the way with the toolboxes - but if I do that, I have to drag it manually back into the main part of the screen when I open an image, and put it away again afterwards. Assuming it's not possible to turn this no-image-open window off altogether (it's not, right?) I'd like the window to be able to switch between those two positions automatically as the first image is opened and the last image is closed. All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The toolbox Wilber problem
Hi, Sven Neumann wrote: > if you don't like it, or it doesn't fit your screen layout, then why > don't you just turn it off? There's a gimprc option for this and it is > documented. Is it documented anywhere other than the gimprc file itself (and now this mailing list too!)? In other words, is it "discoverable"? As a long time user I'd sooner not waste that screen space either, but it would never have dawned on me to go poking around in gimprc if I hadn't just read your comment. I'm not sure I'd have figured out that the Wilber was supposed to represent a drop target, either - though the tooltip is admittedly a bit of a hint! :) > There is no UI for it, but that should be OK. There are > quite a few options that don't have a UI, simply because they are not > considered important enough to clutter the preferences dialog (which is > still way too cluttered). As far as I can tell, the toolbox doesn't currently respond to right-clicks at all, so perhaps it's worth considering a right-click menu with checkboxes to replace (or just complement) the contents of the Preferences dialog's "toolbox" page. That's how many programs, from the Windows taskbar, to web browsers, to OpenOffice.org, allow the visibility of optional UI elements to be set, so would probably be more in line with user expectations than checkboxes in an already-crowded dialog. All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] patch for scale-region.c
Hi :) [EMAIL PROTECTED] wrote: > Comparing Lanczos 3% old vs patched: lefthand building roof has bad moire > effects that totally obscure underlying detail. Both sets of trees have > much less obvious staircasing in the current code. There is an overall > impression of sharpness in the new code but this seems really to be just > high contrast artifacts with a lack of intermediate tones. I think these are aliasing artifacts caused by high-frequency components in the original image - unless you take steps to remove frequencies higher than the target sample rate before resampling a signal, aliasing will result. And as you noted, it affects my code too. Reducing that effect required some form of low-pass filtering before scaling - to remove the high frequency components which can't be represented in the lower-resolution image. Here's another version of the 3% reduction image, with a 33 radius (100% / 3%) gaussian blur applied before the reduction: http://www.blackfiveservices.co.uk/3PercentPreBlur.png I also note that my original 3% version was one pixel narrower than Sven's, so here it is again: http://www.blackfiveservices.co.uk/3Percent.png > Interestingly the blackfive code (thanks for sending the that algo > Alistair) seems even harsher but does give some impression of sharpness by > apparently accentuating edges. I suspect that's just the result of a "cleaner", single-stage reduction with the aliasing artifacts on top. > If this is considered from an analytical , data processing perspective I > can't imaginge what the frequency responce of this multipass approach must > look like. Chances are it would be low-pass to some degree, so arguably a beneficial side-effect, even if a designed filter would be an improvement! All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] patch for scale-region.c
Hi :) Geert Jordaens wrote: > The code is not interpolating rather resampling (supersampling in case > of lanczos and bicubic) in the case of scaling down. OK - perhaps I'm misunderstanding the approach taken here, then. As with interpolation, the Lanczos/Bicubic functions are being used to fit a parametric function to the original discrete samples, yes? The question is how is this function then used? Is a single sample taken from it for each sample of the scaled-down image, or is the function "integrated" over an appropriate interval for each sample? I'd assumed, perhaps incorrectly, that the former approach was being used, and if so, then a simple box-filter should be more accurate; if the latter, however, then I'd expect the results to be better than a box filter. All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] patch for scale-region.c
Hi
Sven Neumann wrote:
> As already explained in my previous mail, the decimation routines are
> only used for the pre-scaling steps. As soon as the image is close
> enough to the final size, the chosen interpolation routine is used. This
> gives continuous results for all scale factors as there is no longer any
> special casing for scaling down by 50%.
What I don't understand is why there's a need to interpolate at all in
the case of scaling an image down. When scaling up, interpolation is
used to estimate missing information, but when scaling down there is no
missing information to be estimated - the problem is instead finding the
best strategy for *discarding* information.
What I do in PhotoPrint is just use a simple sub-pixel-capable box
filter - which is what your current approach
(scale-by-nearest-power-of-two, then interpolate) is approximating.
The routine looks like this:
// We accumulate pixel values from a potentially
// large number of pixels and process all the samples
// in a pixel at one time.
double tmp[IS_MAX_SAMPLESPERPIXEL];
for(int i=0;iGetRow(row);
// We use a Bresenham-esque method of calculating the
// pixel boundaries for scaling - add the smaller value
// to an accumulator until it exceeds the larger value,
// then subtract the larger value, leaving the remainder
// in place for the next round.
int a=0;
int src=0;
int dst=0;
while(dstwidth)
{
if(src>=source->width)
src=source->width-1;
for(int i=0;iwidth-(a-width);
p/=width;
// p now contains the proportion of the next pixel
// to be counted towards the output pixel.
a-=source->width;
// And a now contains the remainder,
// ready for the next round.
// So we add p * the new source pixel
// to the current output pixel...
if(src>=source->width)
src=source->width-1;
for(int i=0;iwidth;
}
++dst;
// And start off the next output pixel with
// (1-p) * the source pixel.
for(int i=0;i The main problem with the code in trunk is though that I think that the
> results of the new code are too blurry. Please have a look at the tests
> that I published at http://svenfoo.org/scalepatch/. And please try the
> patch and do your own tests.
The slight blurriness comes, I think, from performing the scaling in two
distinct stages. Just for kicks, since I had a rare spare hour to play
with such things, here are versions of the 3% and 23% test from your
page, for comparison, scaled using the downsample filter whose core is
posted above:
http://www.blackfiveservices.co.uk/3Percent.png
http://www.blackfiveservices.co.uk/23Percent.png
Hope this is some help
All the best,
--
Alastair M. Robinson
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Option for locking tabs?
Hi again - replying to myself,,, > ...so that if a co-worker comes along, uses GIMP and then closes > all my windows, not just the toolbox, they'll come back the way I like > them next time I run GIMP. And I've just spotted how to do this - disable "Save window positions on exit", and click the "Save Window Positions Now" button - how I've failed to spot those for so long I don't know! All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Option for locking tabs?
Hi :) [EMAIL PROTECTED] wrote: > I did that now. While it does help a bit, I still think locking them > would be ideal, at least to a user. I did some rough testing with a > value of 100 and it happened anyways when working hurriedly across > different tabs. I can't speak for others, but knowing they are locked > would be preferable in my case. Yup, I find I accidentally move palettes out of the window too - so an option to lock a dock full of tabs would make my life easier. What I'd also like, since I'm in WishList mode, is to be able to lock a UI "State" - so that if a co-worker comes along, uses GIMP and then closes all my windows, not just the toolbox, they'll come back the way I like them next time I run GIMP. Currently, whenever that happens I have to spend a few minutes adding tabs to a new dock window. All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Gaussian blur: Silly question or buffer error?
Hi,
I may be missing something obvious here, but I'm trying to understand
the workings of the Gaussian Blur plugin, since I need to implement
something similar myself, and either there's something screwy here, or
there's something obvious I'm missing.
In gimp-2.4.4/plugins/common/gauss.c, the gauss_iir() function,
at line 960 we have four pointers initialised - two to the beginning of
their respective buffers, and two to one tuple before the end.
sp_p = src;
sp_m = src + (height - 1) * bytes;
vp = val_p;
vm = val_m + (height - 1) * bytes;
But then the inner loop does this:
for (b = 0; b < bytes; b++)
{
vpptr = vp + b; vmptr = vm + b;
for (i = 0; i <= terms; i++)
{
*vpptr += n_p[i] * sp_p[(-i * bytes) + b] - d_p[i] * vp[(-i *
bytes) + b];
*vmptr += n_m[i] * sp_m[(i * bytes) + b] - d_m[i] * vm[(i *
bytes) + b];
}
...
On the first run through, with b=0, the index [(-i * bytes) + b] will be
negative for all but the first iteration, yet it's used with the sp_p
and vp pointers, which point to the beginning of their buffers, thus
accessing memory outside the buffer. Or am I missing something here?
And while we're on the subject, can anyone point me to an explanation of
the maths behind this IIR approximation of the Gaussian filter? I
understand Gaussian blurring well enough to implement a
convolution-based version, but I want to implement a
local-contrast-stretch filter - basically a gentle large-radius
unsharp-mask, which would require unfeasibly large convolution matrices
to do it that way.
All the best,
--
Alastair M. Robinson
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] pushing color management further
Hi, Sven Neumann wrote: > either we reuse the same display filter for all previews or we introduce > a transformation cache. Perhaps doing both would be the best solution as > multiple displays on the same image would also benefit from a > transformation cache. I've implemented a Transform Cache in PhotoPrint - I think I've mentioned before that as a "signature" for matching the correct transform I use an MD5 hash of both source and destination profiles (excluding headers), as well as the rendering intent. Just throwing that in, in the hope it might be useful. All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] SPAM-LOW: floating selections and other annoyances
Hi, Sven Neumann wrote: > Floating Selections > --- > We should try to remove floating selections from the user interface. It > should be possible to completely hide this implementation detail. > > This needs a thorough analysis first. How exactly should all the case be > handled where a floating selection is involved? Unfortunately I have very little time to devote to coding currently, and haven't really been keeping up with the changes here. In 2.4 The user can no longer use a selection tool to "tear off" and float a selected region, am I right? If you want to select and move a region you now have to manually float with either ctrl-shift-L or do Ctrl-X, Ctrl-V, correct? If floating selections are to be removed, how do you anticipate a user selecting a section of an image and moving it? By creating a proper layer from the selection? Thanks, -- Alastair M. Robinson ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Separate+ plug-in
Hi, Yoshinori Yamakawa wrote: > Separate+ plug-in is improvement version of Alastair M. Robinson's "Separate" > plug-in. > > For more information, please visit: > http://cue.yellowmagic.info/softwares/separate.html Excellent work! I've just given it a test-drive, and I like what I see :) All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Softproof rendering intent
Hi, Sven Neumann wrote: >> Please think about why the value of "ProofingIntent" is >> "INTENT_ABSOLUTE_COLORIMETRIC". The Problem is that ProofingIntent is an ambiguous term. Does it mean "The intent whose effect we wish to simulate on screen", or "The intent used when mapping from printer to screen"? Assuming the intention within GIMP is to map as follows: RGB -> (Softproof intent) -> Printer -> (Display intent) -> Monitor then GIMP does indeed currently have these reversed. This can be proved by setting both RGB and Monitor profiles to sRGB, and the Print Simulation profile to USWebCoatedSWOP (or any other D50 output profile). Since the printer profile's whitepoint is 5000K and the Monitor's whitepoint is 6500K, then changing the Display rendering intent to "Absolute Colorimetric" should produce a yellow cast, matching screen white with the yellower paper white. In fact, what currently happens is that a blue cast is added. Setting the Softproof intent to Absolute Colorimetric instead, causes a yellow cast, but should cause a blue one. Thus, these two parameters are currently reversed. All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: 2.4 showstoppers
Hi, 2. Managed Display - To me mode this should be used for web graphics and users with the large majority of inkjets which are indeed RGB devices in that they expect RGB data. As Hal pointed out, printing is irrelevant in this mode. Behind the scenes, "Managed Display" should be doing a simple Image (or Working Space) Profile -> Monitor Prorfile transform, so that users with a profiled monitor will see the correct colours. I think the Press Simulation (was Print Simulation on 2.3.12) is intended to be a preview mode so that users can have a better idea what their output will look like on the intended printer/ink/paper combo or other output device and I don't think this has anything to do with the output device being CMYK or RGB. This is also how this works in photoshop. This mode uses a proofing transform, so that colours are shown on screen as they would appear if rendered on another device - usually a printer or press. Whether this extra device profile is RGB or CMYK matters not one jot (not even at code level). Why was this renamed to Press Simulation, BTW? This mode is every bit as valid and useful for profiled desktop printers as it is for printing presses - hence it's potentially useful for digital photographers, not just pre-press operatives. All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Is there a way to update the cursor position from within a tool?
Hi, Karl Günter Wünsch wrote: I have a problem. Because of the aspect pegging in the rectangle selection tool the cursor position and the corner of the area can move asynchronously because of rounding effects in conjunction with the set aspect ratio. When you say asynchronously, are we talking about the corner of the selection parting company with the mouse by a couple of pixels, or can the selection get "left behind"? I haven't looked at the code - but can you keep the coordinates as floats, and round down only when you draw the selection box - and avoid the cumulative rounding error that way? That's why I would like to update the cursor position after all of the calculations are through to reflect the results. That's not a good idea - Adobe PageMaker does that for guide-snapping, and it feels *awful* - especially when you get interactions between guides, causinig the cursor's position to *oscillate* rapidly between two or more positions! I think what you're suggesting would subtly change the "feel" of the mouse while creating a selection - hopefully, there's a better solution to the problem. :) All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] about lanczos
Hi, Roberto Winter wrote: I guess the whole point is that Lanczos is not really the 'best' algorithm for reducing images (as suggested in the scalings dialogs whe selecting the algorithm). Now, isn't there a problem?... Yes, there is - and the problem isn't just that Lanczos is not the "best" algorithm for reducing images, *interpolation* of any kind is inapproprite when reducing images. Interpolation allows us to estimate pixel values that "fall in the cracks" between sample points in the original image - which is a great help when enlarging; however, when reducing, the "correct" approach is to perform a weighted average of all source pixels that are "covered" by the destination pixel. Cubic interpolation gives a tolerable approximation of the "correct" method; Lanczos Sinc, it would appear, doesn't. Another point worth considering is that, while for band-limited photographic images Lanczos performs very well, for artifically sharp images it can result in almost JPEG-like ringing artifacts. So while it produces the "best" results for many images - and is certainly the method that causes the least amount of blurring when rotating an image by a few degrees, it's not *always* the best choice. All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Comments on gimp's interface
Hi, Akkana Peck wrote: First, a dialog that says "You are about to save a layer mask as JPEG. This will not save the visible layers." So what WILL it save? There's no way of telling from the text in the dialog. Options are: [Cancel] [Confirm], so Confirming is really the only choice. Or Cancelling, and moving the focus to a real layer rather than a mask, then returning to File->Save As... I must admit I have to do this quite frequently. Export is almost always the right answer, since that saves the image as you're looking at it in the image window -- even if you just dismissed that scary layer mask dialog that said it wouldn't save the visible layers. Is this intended behaviour, or a bug? This would all be so much clearer if Save As just saved the current image (the whole thing, flattening as necessary without pestering the user about it). For people who want to save just one layer (or mask), offer a separate menu item for that, perhaps in the context menu of the layers dialog, as well as in either the File or Layers main menubar. Perhaps a menu item: Layers -> Mask -> Export... would be the most logical solution - and then remove the dual-function on File -> Save / Save As? All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Plea for a new interface for the GIMP
Hi, Robert L Krawitz wrote: Maybe there should be something in the menu bar that opens it on a single click (rather than click/drag/release). Double-cliking a tool causes the tool-options to be shown - that's probably sufficient. That's a function of your window manager setting. If you use click raise, this will happen. I don't have this problem personally, since I don't use click to raise (click on the title bar or a hotkey are the only ways for me to raise a window). Sadly that's not an option under Windows, and most disappointingly, not under stock Gnome either. Perhaps we should give some thought to a less intimidating default window layout, though. All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Bring Back the Keyboard!
Hi, Scott wrote: That is a good idea. I usually use gqview to find the 1st file I want to edit, then Ctrl-1 - being very unmousy, I never thought to drag-n-drop. I'm using fluxbox, so I'm sure I can get it set up to work for me. Thanks! And for the gr tip too. In that case, then, you'd do well to change the external editor command in GQView from "gimp %f" to "gimp-remote %f" - then the files will open in an existing GIMP instance if there is one, and you can continue to avoid the mouse :) All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Bring Back the Keyboard!
Hi, Scott wrote: Sorry, I seem to have unwittingly stepped into some hornet's nest. Novell? I have no idea what is meant. I'm just an ignorant user who used to like the way gimp worked, I have no clue what Novell would have to do with it now not working. It must be an inside joke. This issue has cause a *huge* amount of bad-feeling and in-fighting in the past, so rather than dig it all up again, I'll just offer the two workarounds I use. Firstly, I generally have GQView running behind the GIMP and use its internal image browser to locate files. I just drag-n-drop them into the GIMP's window. (You really need a window manager that will allow you to disable click-to-front for this to work well, though - i.e. not Metacity, unless you're up to patching it. That's another issue that's caused similar rows.) The other trick I use is to set up an alias to gimp-remote in my shell, so if I want to open a file that's quicker to type than locate, I just type: gr /path/to/file That way I can use the shell's tab completion. Ironic, isn't it, that a UI simplification intended to make newbies more comfortable results in me resorting to the shell... All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: [Gimp-user] 2.4 schedule estimate?
Hi, Hal V. Engel wrote: Only that the change log only lists PNG as having the ability to load and save embedded profiles. Since the display filters don't use the embedded profiles users have no way to know what it working and what is not with regard to embedded profiles. So I only have the change log to go by which only lists PGN files and not TIFF or JPEG as being able to read and write embedded profiles. I believe the TIFF (and JPEG?) loaders have been loading and saving embedded profiles as parasites for some time. They've just been ignored in all other regards. The display filter is probably the most difficult part of this to implement and it is close as it only needs to start accessing the embedded profiles. The filter itself is relatively trivial - the existing proof filter needs only minimal changes to do the job. What will be trickier is developing profile- and transform-caching strategies. The display filter is effectively log-jammed, however, until it becomes possible to fetch a reference to the image from within the filter. That's left to the print plug-ins but shouldn't be hard to add. Indeed. Once there's an infrastructure for plugins to query the GIMP for the profiles to be used for a particular task, the rest becomes relatively trivial. All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Lanczos algorithm funnyness?
Hi, Øyvind Kolås wrote: The problem with using bilinear/bicubic/lanczos for decimation is (apart from being wrong in the first place) is that you end up throwing away pixels. For bicubic a destination pixels uses information from a 4x4 source window in the original image. This is wrong. If you for instance scale to 10% of the original image size. You need to include data from at least a 10x10px window. Thank you. So I repeat, why is the Lanczos Sinc filter (or bilinear or cubic for that matter) being used at all when reducing images? All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Lanczos algorithm funnyness?
Hi, Dag Rune Sneeggen wrote: But still, its clearly a faulty algorithm... Quite serious as well(?) This might be a silly question, but why is GIMP using interpolation at all when reducing images? Shouldn't it be doing weighted averaging of all the source pixels that contribute to a destination pixel? All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Designing a Better Font Selection Widget for use in Open Source Software
Hi, Edward H. Trager wrote: I welcome the community's suggestions and criticisms -- One easily overlooked feature which I consider to be most important is keyboard support. In many Windows apps (and OpenOffice), I can type the first few characters into the font selector combo and that's usually enough to narrow it down to the font I'm going to use. This feature makes an *incredible* difference to working efficiency. All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] anti-swpat campaigner seeks pantone patent details
Hi, Ciaran O'Riordan wrote: The lack of Pantone support in GIMP is a useful example of how software users are harmed by software patents, but to make this claim I need to be able to point out which patents cause this problem. Is that really a patent issue? Pantone support need be nothing more complicated than a name -> colour lookup table. (That's how InDesign implements it - an EPS file defining a shedload of CMYKCustomColors). I would have thought that the issue with Pantone colours would be Trademark and/or Copyright. If no-one minds, I'll submit the information here too: http://www.gnu.org/patent-examp/patent-examples.html#GIMP Any other solid info about patent problems in GIMP would also be appreciated. On- or off-list. Probably best to keep this off-list; Free Software developers are better off keeping themselves entirely ignorant of patent issues, because the penalties for knowingly infringing a patent are generally much harsher than for doing so accidentally. Publishing any examples you may find could, unfortunately, backfire for the same reason. All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color Management
Hi, Jay Cox wrote: Black point compensation is not a part of the ICC specification and is not currently available in any icc library that I know of. For the record: Black Point Compensation is supported by LCMS - you just supply a flag when building the transform... All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP
Hi, Alan Horkan wrote: It is unfortunate that the new file chooser is bad at exactly the things the old file chooser was good at, a case of six of one half dozen of the other. (I always have a terminal open and make frequent use of gimp-remote so I dont mind to the new file chooser too much.) Yes, I do that too. I alias it to gr, so the only penalty is an extra mouse click and one extra keypress. That we both go to these lengths to avoid using the new dialog says something. To my mind the biggest problem with the old dialog was that it's *really* ugly to look at! It also looks reminiscent of the old Windows 3.1 file dialog, which is a big turn-off to some people... I notice some projects have added support for the new file chooser to make it a compile time option but mostly as a way to avoid forcing their users to use the latest version of GTK. I expect the gimp requires an up to date version of GTK for other other reasons but perhaps support for the old file chooser could be added as a compile time option (horribly inelegant and another unpleasant configuration option I know but I wanted to put it out there as a possibility). I seem to remember early versions of Page Plus had a very good way of balancing the needs of experienced and new users; you could set the user interface between three modes, beginner, medium and expert, which determined how many of the advanced features were visible. Later versions broke out in a nasty case of Wizarditis, but they at least had the sense to make it possible to disable them. I think ultimately, something like this might be the answer - not for The GIMP, but for GTK+ - if I could set a flag in my .gtkrc file to say "I'm not a novice, don't try and shield me from complexity" I'd be a lot happier! All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [EMAIL PROTECTED]: Re: [Gimp-developer] FAQ
Hi Sven, Sven Neumann wrote: In the long run, file dialogs and file locations in general should become something that the normal user would never have to use. Realistically, that's a good few months / years away. In the meantime, we're pretty much stuck with using the Save dialog in one form or another. The point of the expander is to hide the UI elements that you are unlikely going to use. Now if the dialog would remember this state and since I don't expect users to ever collapse the expander again, that would basically make the expander be open all the time, thus rendering it pointless. Yes, I see your point. I can only speak for myself, of course, but personally, I end up unfolding the directory view perhaps 90-95% of the times I used the dialog. The only time I generally don't need to expand the directory view is if I'm just saving off an existing image in a different file format. Anyway, just my two-penneth :) All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [EMAIL PROTECTED]: Re: [Gimp-developer] FAQ
Hi Sven, Sven Neumann wrote: True enough - drag'n'drop and gimp-remote are very useful here. Personally I tend to drag'n'drop from GQView into The GIMP - but the usefulness of DnD is hampered in stock Gnome by the impossibility of turning off click-to-front. Right-click any image in gwview and choose Edit->in The GIMP (or Ctrl-1). Yep, I do that too. But surely we should be trying to maximise the usability of the dialogs rather than merely suggesting that people don't use them? (Not that I'm complaining about the Open dialog :) ) But the entry does support entering absolute paths directly. Oh good. I'm a few versions behind on my Linux machine because I don't currently have time to update GTK, FreeType and everything else :) I already said that it could be done but that I am not convinced that it is a change to the better. I'm not suggesting that it should always be open - just that it should remember its last status. I would personally find that a huge improvement; somehow not being able to see "where" in the filesystem you are is a bit disorienting. All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [EMAIL PROTECTED]: Re: [Gimp-developer] FAQ
Hi Sven, Sven Neumann wrote: Why is she using the file open dialog at all? She could as well use the file manager and drag the files into GIMP. The file open dialog should really only be used if the file isn't readily selected elsewhere which should be rather unlikely if you are working in a document oriented way. True enough - drag'n'drop and gimp-remote are very useful here. Personally I tend to drag'n'drop from GQView into The GIMP - but the usefulness of DnD is hampered in stock Gnome by the impossibility of turning off click-to-front. (I'm technically minded and motivated enough to apply a patch, but end users aren't). DnD can also be a problem between multiple desktops. Also, you might want to explain bookmarks to your wife. She might find the dialog a lot more usable then. Bookmarks are indeed great. What I am missing is support for XDS in the common desktops so that one would have to use the file save dialog less. Yes, for me the Save dialog is an annoyance. I very rarely want to save directly into the default directory, and changing directories takes too much mousework, and is clumsy with the keyboard (tabbing to get the focus in the right place, then Ctrl-L, then enter path...) Is there any reason why the save dialog's filename entry box can't support paths directly? Could the expanded/collapsed status of the directory selector be made persistent across sessions? All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg-exif development summary
Hi Robert, Robert L Krawitz wrote: Won't they have (already be having) exactly the same problem with any other EXIF-aware viewer or editor? I doubt anyone who's encountered this issue opening files in other programs will have twigged that GIMP caused it :) Raphael's proposal sounds right on the money to me. It comes down to a question of what's most annoying: (1) having to rotate manually an unknown, but possibly quite small number of existing images, on a one-off basis, or (2) having to dismiss (or find a way of permanently disabling) an extra dialog for every existing and future image that has the relevant EXIF flag set. I'd opt for (1) every time. I could live with (2), if and only if there's a bug-me-not option to get rid of it. All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Color Management was GEGL development/gimp integration
Hi Gerhard, Gerhard Gaußling wrote: What kind of softproof is available? Hmm.. I can nothing similar find here. It took me a while to find it too - it's under the View -> Display Filters. In the resulting dialog you can choose from a number of filters, including Colour Proof. When we were discussing colour management a few months back, I hacked the Colour Proof filter to do a normal working-profile -> monitor-profile transform, and it worked pretty well. The sticking point with the display filters is that there's currently no way of getting a reference to the current image into them. Without that, using a specific profile for individual images is next to impossible, and while we're restricted to 8-bit precision internally, that's pretty much a vital capability. All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg-exif development summary
Hi Simon, Simon Budig wrote: Storing the orientation of the camera relative to the image data stored doesn't make much sense and just happens to kind of work for exif aware applications, because the camera abuses the ORIENTATION tag. The ORIENTATION tag provides enough flexibility to cope with situations other than just "Portrait" or "Landscape"; the typical camera's use of the ORIENTATION tag isn't so much an abuse of it, as a special case. FWIW though, my old HP PhotoSmart 618 does indeed rotate the image data before writing to the card, and ignores the ORIENTATION tag - so it has been done! (It also has a Coldfire processor, and uses Digita as its OS...) All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] comparing gimp speed
Hi, Dov Kruger wrote: Granted, because you are editing the image, not just displaying it, there has to be some slowdown, but I wondered if there is any way I can tweak gimp, do I somehow have it massively de-optimized. When I first set up gimp-2.0, I tried both 128 and 512 Mb tile cache sizes. 512 seems to work a lot better, but it's still pretty bad. Any idea as to the area of the speed advantage of Adobe? It's true that GIMP struggles with large images. I frequently need to edit 400 or even 600dpi full-colour A4 pages on a 256MB machine, and that's sailing pretty close to the wind. The most important thing to do is balance your tile cache setting, as you've already found. You want it large enough that GIMP doesn't have to use its own virtual memory, but not so large that the OS has to use virtual memory to accommodate it. On a 2GB machine, I'd set to about 1.5GB, assuming GIMP has pretty much free reign over the machine. The other thing that can help a lot is to set the maximum number of undo levels right down to 1, but set the maximum undo memory to something a bit higher - maybe 50 or 100 MB. That way you still get plenty of undo levels on small images, but don't waste memory with a long undo history for huge images. I've found that this solves most of the disk thrashing problems with GIMP/Win98 and A4 scans. Linux seems to have better memory management to start with, but this tweak can help here too. All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Colour management - who can do what?
Hi Robert, Robert L Krawitz wrote: Firstly, I've been quiet on this subject for a few weeks because I've bought a new printer, and my limited coding time has been spent tweaking gimp-print to settle one or two minor print quality issues! Which we've very much appreciated, even though I still have to try out your latest. I've been busy with other things, like making dcraw do the right (IMHO) thing. But I digress. Don't worry, I wasn't feeling unappreciated - just torn between two projects, like yourself :) It would *really* be helpful to plug this into the Print plugin, if not Gimp-Print itself, so that when the GIMP feeds 8 bit values to the plugin these values are reprocessed into 16 bit values, rather than 8 bit ones. This should be a fairly trivial change once we have the infrastructure to get the current working profile and/or the image's profile into plugins in general. The print plugin would itself need to link against lcms, and it would simply fetch the current working profile (or the image's own profile if there is one), and create a transform from 8-bit data in the source profile to 16-bit data in the destination profile. The sticking point would be the destination profile - the user would need one that accurately describes gimp-print's characteristics! We could of course just use sRGB (which lcms has built-in) as a default. All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Colour management - who can do what?
Hi Sven,
Sven Neumann wrote:
- implement color management as was discussed earlier
Firstly, I've been quiet on this subject for a few weeks because I've
bought a new printer, and my limited coding time has been spent tweaking
gimp-print to settle one or two minor print quality issues!
But to refresh everyone's memory about colour management, here is a list
of what I believe needs to be done:
1. Create a new class for colour-management preferences, as you suggested:
struct GimpColorConfig
{
GObject parent_instance;
gboolean enabled;
gchar *monitor_profile;
gchar *working_profile;
gchar *proof_profile;
GimpColorIntent render_intent;
GimpColorIntent proofing_intent;
};
We need to be able to get this information into both the display filters
and plugins. (Read only is probably sufficient for now.)
2. Modify the display filter interface to allow the current image to be
referenced from within.
3. Allow the creation of a global display filter that will apply to all
open images (unless disabled through an image parasite) and to the
colour-selectors too. (For the latter, the image parameter passed to
the module will be NULL)
4. Create a plugin that can transform an image between arbitrary RGB
profiles. This plugin will need to be capable of using as source a
binary profile attached to the image as a parasite "icc-profile", as
applied by the TIFF loader. It will also need a user interface for
interactive use.
5. When an image is newly loaded it should be checked for an
icc-profile parasite, and if one is found the user should be given the
*option* of converting the image to the current working space. If the
user agrees, the parasite should be flushed after conversion, because
the image will now be in the working space. If the user declines, a
further parasite should be attached to the image that will disable
colour-matching in the global display filter.
6. Image saving: some savers already support ICC profiles, as a binary
parasite. We could simply load in the working profile and attach it as
a parasite before saving, or we could do something smarter, providing
the savers with access to the structure outlined in (1).
Does anyone have anything to add to this list, or can anyone see any
fatal flaws or other problems that need to be resolved?
And the ultimate question: who's going to do what?
I can put some time into this, but probably not enough to do the entire
list. Since I don't currently know GIMP's internals very well I think
my time would best be spent working on the plugin mentioned in (4) and
the display filters themselves, but points 1 and especially 2 need to be
done first.
All the best,
--
Alastair M. Robinson
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: The way forward for Color Management
Hi Sven, Sven Neumann wrote: In order to support this feature, we'd need one more flag and an appropriate RGB colour: gboolean proof_use_alarm; RGBTriple proof_alarm_color; That would be a feature that is enabled per display and doesn't need to be stored globally ?! Perhaps - though I can see some value in applying it to the colour selector, so you can see which colours are "off limits" when targeting a specific device. All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: The way forward for Color Management
Hi Sven,
Sven Neumann wrote:
yesterday I suggested the following struct:
struct GimpColorConfig
{
GObject parent_instance;
gboolean enabled;
gchar *monitor_profile;
gchar *working_profile;
gchar *proof_profile;
GimpColorIntent render_intent;
GimpColorIntent proofing_intent;
};
I've just realised that we haven't made any provision for LCMS's very
useful alarm-colour ability for soft-proofing - in short, it can be made
to replace any colours that can't be represented on the output device
(out-of-gamut colours) with an "alarm" colour. (Lime green and shocking
pink seem to be good choices!)
In order to support this feature, we'd need one more flag and an
appropriate RGB colour:
gboolean proof_use_alarm;
RGBTriple proof_alarm_color;
All the best,
--
Alastair M. Robinson
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: The way forward for Color Management
Hi Sven, Sven Neumann wrote: What we didn't talk about yet is whether the profiles are filenames that specify what ICC color profile to load or whether they are pointers to color profiles loaded into memory. I suggest that we use filenames here and let the modules deal with loading the profile. Is loading a profile using lcms an expensive task or is the file just mmap'ed? If it turns out to be a problem we could consider to add a color profile cache that is shared by all display filters and color selectors. The profiles would be identified by their filename so the struct that I suggested should be good enough. I'm in full agreement over passing filenames instead of blocks of memory. There's a bit more to opening a profile than a simple mmap() - there's a header that much be parsed, and endianness issues taken into account - but it's not that expensive. What is quite expensive is creating a transform from a pair of profiles, so if we could cache the transforms it would be worthwhile. The other possibility is to have a single instance of the display filter used across all images and the colour-selectors, and then allow an image parasite to disable it. Advanced users could then set up through the View->Display Filters dialog any custom transforms that they require. This would more or less guarantee that inexperienced users won't accidentally end up with mismatched color-spaces, while still providing enough flexibility for advanced users. For image-specific profiles, I suggest that we continue to do what we've been doing so far and that's attaching the loaded profile to the image using the "icc-profile" parasite. Agreed. Upon image load, if this parasite exists and the user wants to transform to the working space, then a plugin will transform from this binary profile to the working profile, after which this parasite can be flushed. If the user doesn't convert to the working profile, the parasite will remain, and will be available to the display filters if the user subsequently sets up a custom transform. All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CMS PDBs in CinePaint/GIMP
Hi Sven, Sven Neumann wrote: Kai-Uwe Behrmann <[EMAIL PROTECTED]> writes: void gimp_image_set_lab_profile (gint32 image_ID); void gimp_image_set_xyz_profile (gint32 image_ID); void gimp_image_set_srgb_profile(gint32 image_ID); What are these? Setters without a value? Yes, LittleCMS has a few "standard" built-in profiles that can be used without a file on disk. sRGB is the only one we need; rather than expose it at the API level, we could just use it as a default if an empty or NULL string is passed where we expect a filename. All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: The way forward for Color Management
Hi Sven, Sven Neumann wrote: it would help a lot if you could send some information on what settings you think are needed for color management. I know this info is in Bugzilla but I'd like to see it mentioned here so that we can start to discuss how to implement it in a way that it can be used from display filter modules. I guess we also need the same info to be accessible by plug-ins also? We will then also have to add a PDB API to access them (read-only ?). OK - in approximate order of importance: colour_management_enabled - speaks for itself. Must be accessible from the loading code, since a user who has disabled color-management won't want to be bothered by embedded-profile-related questions. monitor_profile - read access needed by the display filter. Write access available to plugins would make a rough-cut monitor profiling plugin possible. working_profile - characterises the GIMP internal working space. Will default to sRGB (and will probably stay that way for most users), but some poeple have expressed an interest in using AdobeRGB instead. Read access required by the yet-to-be-written colour-management plugin that will transform from an image's embedded profile to the working profile. proof_profile - this profile characterises a device to be simulated by the proofing mode. This will typically be a CMYK profile, and these can be large (USWebCoatedSWOP.icc is over half a megabyte), so it makes sense to try and avoid having a separate instance of this filter for every image. Should only be needed by the display filter. rendering_intent - This affects how littlecms will transform the colours. Needed by the display filter. proofing_intent - In proofing mode, rendering_intent specifies how colours are rendered on the simulated device. proofing_intent is needed to specify how this simulated data is rendered on the monitor. Again, needed by the display filter. That should pretty much cover it. I think it's important to be able to disable color-management for a specific image, and I would like to be able to override the working profile for specific images, (which means getting an image parameter into the display filter so parasites can be fetched). Hope this is some help :) All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: The way forward for Color Management
Hi Sven, Sven Neumann wrote: You misunderstood me. What I was saying is that GIMP 2.0 has the API to implement all this and I would have loved to see this added about a year ago when it was proposed quite detailed already. Since that didn't happen we can now also do some useful changes to the modules API and to the core to integrate it even better. GimpDisplayConfig is OK - I've asked this before, but can anyone provide me with, or point me at, a transcript of the previous discussions? however definitely the wrong object to add this stuff to. I will try to write down my ideas on how to share color management configuration somewhen this weekend. OK - fair enough - I look forward to reading it :) Forgive my over-enthusiasm on this; I'm keen to see this get into 2.2, but no-one else has expressed an interest in coding this, and with a feature freeze approaching, I wanted at least a working prototype. (In fact, I'm already finding the modified proof filter useful, if tedious to set up every time an image is opened!) The proof filter should do proofs and nothing but proofs. What you are suggesting sounds more like a new filter. Again, that's understood - but I would recommend renaming the existing filter rather than having two separate ones; soft-proofing and "normal" colour management are not only almost identical code-wise, but mutually exclusive (at least as far as the display filters go). If you look at the code, you'll see that the bulk of it is in adding support for working and monitor profiles (both of which are necessary - at least until we've decided on the configuration issues - for the proof filter anyway). The only code that differs for the two modes is that normal color-management calls cmsCreateTransform() instead of cmsCreateProofingTransform(). All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The way forward for Color Management
Hi Nathan, Nathan Carl Summers wrote: Wait -- the color selectors need to be filtered on a per-image basis as well. What if you are working in very different colorspaces for two images? It does you no good to select a color in the gamut of one image if you really wanted to select for the other one -- that color might not even be in the gamut of the the other image! You're quite right, but it's not possible at the moment to associate the colour selector with a given image; this was one of the chief arguments in favour of a fixed working space. I envisage the vast majority of work being done in the GIMP's working space, but for advanced uses, I think the ability to override this working space is important. The plugin / dialog or whatever is used to do this will have to include warnings about the color selector not matching the image if its colorspace is overridden. Personally I envisage needing the ability to override the working profile for two things: Firstly, tagging a scanned image with the scanner's profile. If the scanned image is a photograph, then the colour selector isn't likely to be used anyway - my photo editing usually involves layer->colors->curves, and the clone tool. If the user needs to pick a colour, he/she can always use the eye-dropper to grab one that's already in the image. If the scanned image is a logo or similar, then converting to sRGB is no hardship anyway, so the problem can be bypassed. The second reason I want to be able to override the working space is that the fake CMYK colour mode of my separate plugin uses a layer in darken only mode to do naive R=1-C type CMYK->RGB conversion, which gives over-saturated colours; with the aid of a custom profile, this can be much improved. While the issues with having a fixed profile for the colour selector are real, I think it's acceptable as long as inexperienced users aren't confronted with it. Only advanced users are likely to want this feature, and they can be expected to be savvy enough to understand the implications and work around them. All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The way forward for Color Management
Hi
Øyvind Kolås wrote:
Would it make sense to break down the processing chain of the modules in
two parts? One part that is attached to the image, and one that is
attached to the
display
projection -> image filter -> display filter -> frame buffer
It's a possibility, but I think it's probably making things
unnecessarily complicated. Since we presumably want to avoid having two
sets of filter modules to maintain, the display filter would have to be
a special case of the image filter (or vice versa)?
I also think that for maximum flexibility, if we have a single global
color-management filter outside the image filter chain, we need to be
able to disable it if a color-management image filter is enabled. And
we still need to get an image parameter into the filter modules :)
A proof-of-concept image filter (based on the existing proof module) is
now attached as a patch to bug #78265. Configuration is currently done
through View->Display Filters - it needs to be made persistent, and
parasites are looking like the best way to do it.
I envisage it working something like this:
Fetch working profile from global parasites.
Fetch monitor profile from global parasites.
Fetch proof profile from global parasites.
if(we have an image)
{
if(we have an override-working-profile image parasite)
Fetch overridden working profile from image
if(we have an override-proof-profile image parasite)
Fetch overridden proof profile from image
}
This IMHO avoids too much unnecessary complication while providing the
flexibility I'd need to use it at work: I'd want to scan an image, and
rather than convert the image to sRGB, just tag it with the scanner's
profile, and have the display filter use that as the source profile.
This method also allows for proofing transforms to be enabled on
specific images.
As always, comments, criticisms and suggestions welcome :)
All the best,
--
Alastair M. Robinson
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] The way forward for Color Management
Hi Sven, > There is currently no way a plug-in or a display filter could access > these values if they become part of gimprc. If we would make them > parasites, that should work out of the box w/o any changes to the > core. Since parasites can be accessed from plug-ins, the configuration > should also be done in a plug-in. While I can see the logic in that from a technical standpoint, I can't help feeling that from a user-interface perspective configuration should be done in the prefs dialog. Is there any reason (apart from technical inelegance) why the gimpdisplayconfig code that would handle getting and setting these options couldn't take responsibility for maintaining some suitable parasites? > That's what I was expecting to happen outside the core GIMP > development based on the GIMP 2.0 API already. Of course we could > decide to do it differently now that we have the chance to do changes > to the core. We need some minor changes to the core - presumably we want to avoid anything too drastic! From my point of view, I think it's important to tweak the display module system so that the display modules can fetch parasites on a per-image basis (rather than just global ones) - this will let me implement the features I want in the display module. This conflicts slightly with the goal of applying a filter to the colour selectors - but this should be solved easily enough with a NULL argument. The other major core change will be setting up default display filters - it's currently extremely tedious enabling the filter manually for each and every image that's opened! Time, perhaps, to open Bugzilla issues for these changes? I'm about to attach a proof-of-concept patch in Bugzilla that expands the proof module to do regular source->monitor colour correction, with optional soft-proofs, instead of just soft-proofs limited to sRGB source and monitor. All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] preparing GIMP 2.2
Hi, Nathan Carl Summers wrote: I can't honestly think of a good reason to disable color management, but couldn't we just have an option for "this monitor's colorspace" instead of having two choice to choose from? Colour management is in two distinct parts - display and loading/saving. The option I'm talking about here would simply turn off the display filter, which will increase redraw speed, and perhaps save a little memory. I'm not sure I quite understand your other point - are you saying we should forget about having a "working space" and just use the monitor's colour space directly? I can see some appeal to the simplicity of this idea. Pros and cons I can think of are: Pros: * The need for a display filter is eliminated (except for soft-proofing) Cons: * Images saved in non-CMS aware formats (BMP, PCX, JPG) will be assumed by CMS aware software to be in sRGB - which would look awful for images that are in fact in the colour space of, for example, my laptop's screen! * The effect of certain plugins will be unpredictable. One of the goals of colour management is that things like GFlare or other plugins that render graphics will be consistent across hardware if we use a standardised working space. We lose this advantage if we don't use a working space. * Images have to be converted into the Monitor's colour space on loading, which means a destructive change to the data. If I'm working on images I've scanned, I'll want to set the working space to the profile of my scanner (even if I have to go to the preferences to do it, I'll do this rather than convert the data to sRGB or the monitor's colour space). I think the cons of this approach outweight the pros, but working this way would be possible if one were to disable the display filter, and set the working space to the monitor's profile. All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] preparing GIMP 2.2
Hi Everyone, Sven Neumann wrote: Color management This has been discussed quite thoroughly but it still needs to be written down in some sort of specification and then been cut down into tasks. Here's a first attempt at a suitable specification: Colour management will bring two major benefits to The GIMP: 1.Accurate display of colours when equipped with a suitable monitor profile. 2.The ability to perform a soft-proof, whereby an image is rendered to simulate how it will look on a particular output device (usually a printing press). Implementation: The hard work is performed by LittleCMS, while the existing proof display filter can provide both of these facilities with a little modification; most of the details remaining to be finalised are interface and infrastructure related. I can provide an outline here of what needs to be done; someone with a more in-depth knowledge of GIMP’s internals will have to tell us how much work this will entail: (The following assumes that we’re going to create some kind of global display filter for colour-matching, rather than (or as well as) the current per-image ones – at the very least, such a filter will be needed for colour-correcting the colour-selectors...) * Add a new section in the preferences dialog (or add to the existing Display section) the following options: * Enable/disable colour management (Do we allow this to be enabled/disabled on a per-image basis? The filter will need access to image parasites for that.) * GimpFileEntry for working space profile (ie the source profile provided to lcms) * GimpFileEntry for monitor profile (the destination profile for lcms) * GimpFileEntry for proof profile (the profile of the device to be simulated, e.g. USWebCoatedSWOP. Implementation details: lcms has a built-in sRGB profile, which should be used as a default if the working space or monitor profile entries are left blank. If the proof profile is left blank, then the display filter will use a normal transform instead of a proofing transform. If all three are left blank, then the display filter should be disabled, since it won’t have any work to do! * Update the proof display filter to allow straight Working Space -> Monitor Profile transforms as well as full proofing transforms. This is a trivial modification, and I have it working here. The filter (at least the global one) needs to be able to fetch the profiles from wherever the prefs dialog stores them. If the display filter becomes able to fetch parasites from the image, then it becomes possible (easy) to disable colour management on a per-image basis, and perform other tricks like overriding the working space for the separate plugin’s fake composite CMYK images. That’s it as far as displaying accurate colour goes, and even if we get no further than this for 2.2, it’s a worthwhile start. The next step will be to write a plugin for converting between colour spaces. This is not a difficult task. A couple of questions: * Do we allow the user to convert between arbitrary profiles, or only allow the current working space as a destination? * Where in the menu structure should this live? Finally, the image loading code needs to modified. Any loaders for formats that support embedded ICC profiles should attach it (as binary) to the image as a parasite named “icc-profile”. The loading code will check for this parasite on the loading of an image, and allow the user to choose between converting to the working space or disabling colour-management for this image. A special case will be the TIFF plugin – TIFFs can contain embedded profiles for a CMYK colour space; ideally the TIFF plugin itself will use lcms to convert the raw CMYK data to the RGB Working Space. I think this covers most of what’s needed to make colour management a useful addition to The GIMP. Comments please, both on difficulty of implementation and any technical points that need to be discussed further. All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Colour management and the proof module
Hi, Simon Budig wrote: However I don't see a way how color selectors could be dependant on an image. I don't think the image color profile can in any way be applied to the color selectors. Simply because the color selectors don't know about the image. One could assume a standard profile for the color selectors (sRGB?) and transform the color to the image profile when the tools accesses the foreground for painting in a specific image. At this stage it has been decided that the core of GIMP shouldn't be affected by colour management issues - the general consensus is that such drastic changes should wait until GEGL time. This means that in general, images will have to share a common source colour-space for the time being. While I think this is less than ideal, I can live with it as long as changing the working profile isn't too much of a chore! I also see no reason not to allow the source profile to be over-ridden by a parasite, so I'm encouraged that it will ultimately be possible for the display filter to retrieve them from the image. This will make some interesting tricks possible: For example, the separate plugin has one mode in which it generates an RGB image with solid Cyan, Magenta, Yellow and Black layers, and places each plate's data in the layer masks. Each layer's mode is set to Darken Only, which gives a rudimentary full colour display of CMYK data. This is equivalent to the naive R=1-C style CMYK->RGB conversion, so it gives over-saturated results, but I've generated a source profile that significantly improves this display. For tricks like this, it wouldn't matter one jot if the colour selector doesn't match the image display All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Colour management and the proof module
Hi All, I've been playing with the colour proof display module, since it seemed like a good place to start playing with colour management. As it stands (in gimp-2.1.2), the proof module only allows a single profile (for the monitor) to be selected. Profiles are only useful in pairs, so it builds a transform from lcms's built-in sRGB profile to the monitor's profile, which is then used in the display filter. I've played around a bit and improved the filter to the point where source, destination and proofing colour profiles can be selected individually, and am now getting some impressive results from my newly-profiled scanner and a rough profile generated for my Laptop's LCD, which like many older TFT displays has a rather odd colour balance. Now I have a couple of questions: Is there any way of retrieving an image's parasites from within its display filters (i.e. can the filter reference the image), or am I limited to global parasites? Has any thought been given to setting up global display filters so that the user doesn't have to select them for every newly-opened image? Finally, someone (Sven?) mentioned something about widgets (or more precisely, the colour selectors) being able to make use of the display filters; how far has this progressed? All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management: conclusions?
Hi Sven, Sven Neumann wrote: I wrote this in an earlier mail already but perhaps you didn't notice, so here's my question again: Sorry, yes I did miss that... I wonder if we should add the separate plug-in to the GIMP tarball for GIMP 2.2. Would you like to see that happening? I'd be delighted - though there are a few bugs I'd like to fix first! If it's going to become semi-official, though, I guess some discussion is needed about various points: 1. Where in the menus it should live. Currently, my functions are in Image->Separate. The separation is, however, performed on the current layer, not the whole image. The separation functions themselves are really not much more than a colour-profile-aware version of the compose/decompose code that's there already, so maybe alongside those would be the best place. Alternatively, depending on how far we get with colour-management in general, a new top-level Colour Management menu might be a better option? 2. Should the saving function be left with the separation functions, or be moved into the TIFF plugin. 3. How about adding support to the TIFF plugin for loading CMYK images into individual greyscale layers, thus solving the biggest limitation that the separate plugin currently has, i.e. not being able to load its own images back in. (This would have to be an alternative option to converting the CMYK data to RGB using lcms, if we implement that, or using libtiff's own Everything->RGBA converter.) Does anyone else want to bring up any further points? Finally, a question: How is a plugin supposed to go about storing persistent data between sessions (i.e. in my case, the filenames of the profiles last used)? All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management: conclusions?
Hi Sven, Sven Neumann wrote: "William Skaggs" <[EMAIL PROTECTED]> writes: So at the most concrete possible level, here is a suggestion on how to start: Step 1: Add a "Color Management" page to the Preferences. Step 2: Add "enable/disable color management" and "working colorspace" options to the page. To start with, sRGB will be the only option for the latter, but the infrastructure should not build in any assumption that this will always be true. GIMP really won't care what this working space is; as far as the core is concerned it's just a filename, so why limit it to sRGB even temporarily? Step 3: In the file-loading code, after an image has been loaded, check for the presence of parasites called either "icc-profile" or "colorspace". If one of these is found, execute the color management plug-in. Step 4: Write a color management plug-in. Sounds good except that Step 4 should be first. Sure, but the plugin will depend on the implementation of the other stages. The guts of the plugin, thanks to lcms, will be pretty trivial - far simpler than the separate plugin; the most important factor will be the design of its user interface, and supporting factors, e.g. do we support tagging images both with an actual profile, or with the filename of a profile, and such like. There are a couple of other issues that might warrant discussion with the developers of lcms; how to go about comparing profiles for equality for instance (we want to be able to avoid converting between an embedded profile and the working space if they are in fact the same profile!) All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
Hi Dave, David Neary wrote: So say I open an image with a color profile, and then load a second image with a different profile. If I now decide to do the above, what do we do to the first image? 1) We stop using the profile for the first image (and if the image window is open, this will obviously change the visual representation of the image), but keep it attached to the image so that we can re-save it with the image at save time I think this is the best bet - disable the colour-management filter for any images that don't use the current working profile. 2) We stop using the profile and propose the dialog with the 4 options the next time the image is activated (basically allowing us to change the working colorspace on demand, but this could get annoying, I guess) The easiest option is to provide a simple plugin that adds a couple of menu entries - for example: Image -> Colour Management -> Convert to working profile and Image -> Colour Management -> Use as working profile That sounds sane. I'm not quite sure how it would be implemented, but it probably involves having a color profile parasite attached to an image, with some kind of configuration parameter for the working colorspace and the monitor profile. I'm not 100% sure, but I think the TIFF plugin already attaches embedded profiles as a parasite, so they're preserved when the image is saved again. If so, we have a lead to follow! All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
Hi Sven, Sven Neumann wrote: Well, it got to be doable in the file plug-ins since we don't want to have the core depend on lcms. Applying the embedded profile at load time could very well happen in the file plug-ins though. If the core needs to perform colorspace transformations then we should postpone this whole thing and do it properly with GEGL. Given the limitations we're trying to work within, I think the best compromise is likely to be something like this: - GIMP uses a user-selectable working profile. - If a user loads an image tagged with a different profile, she is presented with the following options: - Convert from the image's profile to the working profile, and accept the degredation that will result. - Change the GIMP's working profile to match this image. This will leave the image data untouched. (This should disable the display filter for existing images, since they are presumably using a different profile.) - Load the image without colour management, disabling the display filter for this image. - If a use loads an image with no profile, the display filter should be disabled. - A simple plugin should be available to fill in the gaps, i.e. tagging an image with a specific profile (for images with no profile), or converting an image to the current working space if it has changed. For the majority of users, this should suffice; I suspect compositing images with different profiles won't be a particularly common occurrence - the user just needs to be made aware that colour-space transformations are a destructive change, and have an opportunity to avoid them. All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
Hi David, David Neary wrote: I'll conduct some tests some time and try and figure out just how bad these quantisation errors could be. Great - quantitative data will really help. I've done some testing - I wrote a little program that puts every possible 8-bit RGB colour through an lcms transform. A frequency table is kept of every colour that comes out the other side, which gives us some idea of how many codes are "lost" - how badly the dynamic range is reduced. First, as a control subject, I analyzed the gamma function at 1.1 and 0.6. The results are as follows: Gamma 1.1 Code use tally: 00: 1707993 01: 13481272 02: 1529388 03: 0 04: 57834 05: 0 06: 0 07: 0 08: 729 09: 0 In other words, 13,481,272 colours are mapped with a 1:1 ratio, so can be transformed back again without loss. 1,707,993 colours are missing from the destination set, and just under 1,600,000 colours are arrived at from multiple source colours. Gamma 0.6 Code use tally: 00: 7647887 01: 4251528 02: 3700404 03: 0 04: 1073574 05: 0 06: 0 07: 0 08: 103823 09: 0 Gamma 0.6 is considerably more destructive, only 1/4 of the codes maintain a 1:1 mapping. Now for AdobeRGB <-> sRGB: sRGB -> AdobeRGB1988 Code use tally: 00: 8102616 01: 4172676 02: 3175714 03: 438068 04: 538838 05: 66267 06: 124002 07: 23117 08: 48831 09: 87087 AdobeRGB1988 -> sRGB Code use tally: 00: 8012181 01: 8325155 02: 156167 03: 54498 04: 10468 05: 58725 06: 15054 07: 2108 08: 2129 09: 140731 This isn't as bad as I'd feared, but still considerably worse than either of the gamma tests. In both cases nearly half the codes in 8-bit RGB space are lost! This in effect reduced 24-bit RGB to 23-bit RGB. As I said, this isn't as bad as I'd feared - I was expecting to see a loss of nearly 1-bit per channel; in fact we lose only approximately 1-bit over the whole image. If anyone's curious enough to want the source of my test program, just ask :) All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
Hi Steve, Steve Stavropoulos wrote: That's exactly why we need the internal 8bit RGB colorspace used by gimp to be the widest possible. If the internal colorspace is wide enough then you won't notice any lost colors during the conversion. I don't know how I'm not actually talking about gamut clipping, I'm talking about an effective loss of colour depth through quantization errors. I'm about to run some experiments, so I can hopefully provide some concrete illustrations, or eat humble pie, as may be appropriate! much or how little these looses are, but photoshop works internally with adobe rgb 98 and no one complains about that. It seems that for practical use even the conversions to and from CMYK will be ok. Photoshop can get avoid this issue by using 16-bit / float values to hold internal data. We can't (yet). The specifications of color spaces and the gamut projections on http://www.brucelindbloom.com/index.html?WorkingSpaceInfo.html I think will be of great help. Yes indeed, I'll digest that information in due course... All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
Hi, David Neary wrote: I may be misunderstanding things, but if the conversion from the source colourspace to sRGB is done in lcms losslessly, then all we're losing is the out-of-gamut colours from the colourspace conversion. And, of course, the cost of discarding precision in the data we get after the application of the profile. But I think we still get the full 8 bits of data (they may not have the exact colours in the source file, though). As a (somewhat extreme) analogy, imagine applying a lightening gamma curve to an 8-bit data set (0,1,2,3,4.253,254,255) you'd end up with not all codes being used at the dark end and codes being used multiple times at the light end - something like (0,2,4,6,7 254,254,255,255). I.e. there are missing codes at the dark end, and reused codes at the light end, due to the limited dynamic range of the destination space. The problem I'm talking about will be something vaguely similar; there will likely be missing and reused codes in the working space. Yes, but since this profile is applied once, on the projection drawable, as the final step, its application doesn't present any problems. But I see what you mean - we can go from the source I wasn't suggesting this was a problem, merely trying to explain that profiles are only meaningful when used in pairs. People talk about applying a profile to an image; usually what they mean is applying a transformation between profiles to an image. It's an important distinction. colourspace directly to the monitor's with one transformation. This, however, poses problems for say the checkerboard pattern (which will be transformed differently with different source profiles), and for any occasion where different profiles get mixed (cut & paste operations, for example). It will indeed - I had already mentioned the cut-and-paste case as a possible pitfall. I hadn't considered the checkerboard pattern, but I'm not totally convinced that this is a critical problem! I would have thought you would still have to have the 2 profiles applied though... I'm sure I just don't know how lcms works. Yes, you need 2 profiles - the key is that you don't use profiles directly, you use transformations built from a pair of profiles. The proposed method of using a standard working space involves three profiles (and hence two transformations linking them) - the image's own profile, the internal working space profile and the monitor profile. The "this" was referring to a passage that you cut - I think it is probably a bad idea to have lots of image data in different colorspaces. I can't put my finger on why, but I just have this feeling that we will end up with a certain amount of confusion when it comes to colour stuff (as you pointed out, the colour picker is a good example, so is cut & paste). I can certainly understand your gut feeling, and agree to a certain extent. The thought of destructive modification to the source data in just loading it makes me marginally queasier though! I agree that copy-and-paste is a major potential pitfall, and will require at least a warning on mismatched profiles, and at best an option to convert as part of the paste operation. I'm more than willing to defer to the many experts we have, though. I wish I knew enough about the subject to consider myself one. I'm no expert either (expert: n. from "X", meaning unknown, and "Spurt", meaning a drip under pressure!), but I have used colour profiles outside of the usual PhotoShop setting, and am just anxious that any colour management abilities the GIMP should sprout will be usuable for pre-press work in my job! All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
Hi William, William Skaggs wrote: (1) Layer A1 is visually identical to layer B1. (2) Layer A2 is visually identical to layer B2. (3) When layers 1 and 2 are composited in "Add" mode, the two images look different. This can happen because of the nonlinearity in color profiles. I can see that this would happen; I don't, however, consider that to be a major problem, because you'd be able to see with more accuracy than at present what the result would be! It would be a real can of worms not to use the same color space internally for all images -- losses in conversion are not an important enough factor to overcome this. (But there is a reasonably strong case for allowing choice as to which color space is used internally.) I beg to differ! A silently applied destructive change to the image data is in my opinion a very important factor! All the best, -- Alastair M. Roobinson ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
Hi Steve, Steve Stavropoulos wrote: Whatever you do, you will have to make a compromise. The question is, There we are in full agreement :) You are worried about quantization errors during the conversion, but if you do the conversion in 16 bit or more I think you will not have much problems. In the littlecms site I found a command line program that does the colorspace conversion with very high accuracy. Check I'm not worried about the conversion so much as the fact that the limited precision of the destination data (8-bit RGB) will cause us to lose colour information. A conversion of 8-bit data between two RGB profiles will not be a 1:1 mapping, so the converted data will not use the full dynamic range that 8-bit RGB can provide. Since the dynamic range of 8-bit RGB is already severly limited, I consider impairing it further to be unacceptable. The bigger problem we will have when converting colorspaces, is the limited gamut of sRGB in comparison with the source colorspace. For example, if we convert from CMYK to sRGB, then almost any color with CMYK values in the range C>90, M<10, Y<10, will have no sRGB counterpart. Would it be feasible to switch from sRGB to something better? Maybe AdobeRGB? I found usefull the http://www.brucelindbloom.com/index.html?WorkingSpaceInfo.html when comparing color spaces. If the GIMP is going to hand off the colour-matching work to littlecms, then using a different profile is as trivial as providing the filename of AdobeRGB instead of sRGB! Keep in mind though, that if we change the internal color space from sRGB to something else there must be an option for the user to save his image in sRGB (and maybe that should be the default on many cases). sRGB is the best option when someone tries to view an image in a computer monitor with no color profiling. Absolutely - though under my proposal, if an sRGB image is loaded, then for that image sRGB *is* the working space. As for the proposed conversion on save to the starting colorspace, I completely dissagree. I don't see any reason to introduce more errors coming from a less than optimal conversion. Agreed. Subconsciously, I suppose I'd considered it "good manners" to save a modified image in the same colour space it started in, but you're right, this is not necessary. All the best -- Alastair M. Robinson ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
Hi Dave, Dave Neary wrote: Yes, this is what was discussed at the conference, with one important difference. We don't convert back to AdobeRGB or whatever at save time, we simply save the working image data, with the sRGB color profile. OK - I agree that converting back to the original space is in most situations unneccessary. I see your point. Perhaps there could be some kind of pre-loading where we apply the color profile in floating-point, and quantise afterwards? Just thinking out loud, this may be completely unfeasible. Assuming we're using lcms, the internal conversion will be applied in full precision - the problem is that the destination data, by necessity of the GIMP's current limitations, must be 8-bit RGB. Converting 8-bit RGB data from one profile to another will not be a 1:1 mapping, so some colour information will be lost - I haven't yet conducted empirical tests for the severity of this effect, but I suspect that the 8-bit source data will be downgraded to something like 7 - 7.25 bit. For me, seeing as 8-bit RGB is already inadequate for smooth subtle gradients (cf. my gradient dither patch of a few months back) this is unacceptable. I concede, however, that not everybody will see it this way! How does this fit in with display calibration? If we work on the unmodified image data as we read it in, then on what data should the monitor's calibration profile work during projection? Should it work on the raw RGB data, or should we apply the input profile at projection time? Would a color profile be a per-layer thing? First of all, a profile on its own is worthless for rendering accurate colour - they must be used in pairs, source and destination, to create a colour "transform". Thus, if the GIMP is using sRGB internally, then at projection time you feed the RGB image data through an sRGB->Monitor Profile transformation. If instead you're using the unmodified RGB data from the original file, you just use an Image Profile -> Monitor Profile transform instead. (If the source image has no profile of it's own, then you can just tag it with a default profile.) In short, projection your way looks like this: Image (Source Profile) -> Internal data (sRGB) -> Screen (Monitor Profile) Two transformations, first from Source Profile to sRGB, secondly from sRGB to the Monitor's profile. This would work very nicely if the internal data could be stored in 16-bit or float precision. Because it can't we lose precision. My way looks like this: Image (Source Profile) -> Internal data (Source Profile) -> Screen (Monitor Profile) Just one transformation directly from the source profle to the screen profile, and more importantly, no destructive change to the raw image data. I don't think it would be feasible to make the profile a per-layer thing. I personally consider per-image to be the best solution, as long as there's some way of warning the user if they're copying and pasting between images with mismatched profiles. I think these are the kinds of issues that Sven thought about before, and they make adding color management considerably more complicated. I think that the simplicity of applying a color profile on imput and not having to worry about it in the rendering code outweighs the down side of any quantisation that occurs. I'll conduct some tests some time and try and figure out just how bad these quantisation errors could be. I can certainly see the appeal of a simplistic approach, but if a little extra effort can prevent unnecessary destructive changes to the image data, I think it's worth exploring. I think this is probably a very bad idea. Could you expand on why you think this? Confusion? Difficulty of implementation? Something else? All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
Hi Sven, Sven Neumann wrote: This is also what I originally proposed at GIMPCon. I have then been told that this would be the wrong thing to do and that we should convert the image on load. Now that you backed up my original proposal I tend to agree with you that converting the image data is not feasible as long as we work with 8bit per channel. Is there a transcript of these discussion available anywhere? I'd certainly be interested to hear all the counter-arguments :) Color-correcting the color-selectors is of course a must. We have put the color display filter architecture into libgimpwidgets to be able to implement this. It shouldn't be too hard and could be achieved for GIMP 2.2. The colour selectors are perhaps one of the trickier aspects of my proposal; for their RGB values to be meaningful, the transform applied to the colour selector would need to change to reflect the current image's profile. All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
Hi, (Second try, this time sent to the list at large. Brains where art thou!) Sven Neumann wrote: Well, we have only one internal color space. We just need to agree on what we want to call it... My two-penneth (as author of the separate plugin, and a day-to-day user of the GIMP in a pre-press environment): There are as I understand it, two possible ways of dealing with colour profiles. In the first method, is what I believe is what PhotoShop uses (and what I think Sven proposed): When an image is loaded, scanned or whatever, it is converted from its source colour space into a "working" colour space (sRGB, AdobeRGB, etc.). Of course, the source colour-space and working colour-space can be the same. The advantage of this method is that the working data is always "normalised", so plugins and the like have perceptually identical results, whatever the image's "native" colour space. The workflow for an sRGB Image might be: Image (AdobeRGB) -> Working data (convert to sRGB) -> Editing -> Save (convert back to AdobeRGB) Personally, I don't think this method is appropriate for the GIMP until such time as we have support for 16-bit or float pixels, because if we convert from the source space to a working space with only 8 bits per sample we're going to lose some information through quantization errors. The second method, which I think we should use for the time being, is just to keep track of the "source" profile for each image (and have a user-selectable default profile - sRGB, AdobeRGB or whatever). This source profile should be user-changable (so the user can tag a scanned image with the scanner's profile, for example), and just needs to be accessible to the proof and image-saving code. The equivalent workflow would be: Image (tagged with AdobeRGB) -> Working data (8-bit RGB, unmodified) -> Editing -> Save (AdobeRGB) The advantage is that the image data doesn't have to be transformed between profiles (so we need the facility to do this manually, should the user need it), but there are some disadvantages: The effects of some plugins will look different depending on the image's colour space. (GFlare's flares, for example, will look slightly different applied to an sRGB image compared with an AdobeRGB image...). Colour-choosing is less-predictable (though no less than at present), since the RGB values selected are in a variable colour space. Since we're unlikely to get a PanTone colour-selector any time soon, this shouldn't be an issue. The ultimate solution here is to have a colour-profile attached to the colour-selector, and simply transform the selected colour to the current image's profile. The colour-selector's profile is probably as close as we need to get at the moment to a "working" profile. You would have to convert between colour spaces when copying and pasting between images with different profiles. (Ideally a warning with yes/no buttons. I personally wouldn't want this done silently, because again it would introduce quantization errors with 8-bit data). In short, though, if we use this method, we don't need to agree on what to call our working space, because it will simply be whatever is appropriate for the image being edited! Hope this little essay is some help! All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] OS X help with plugin
Hi everyone, I've been asked by an OS X user if there's any chance of an OS X version of my CMYK plugin (at http://www.blackfiveservices.co.uk/separate.shtml). I don't have access to an OS X machine, so if there's any developer here who does and is willing to help out, please contact me. All the best -- Alastair M Robinson ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
