Re: [Gimp-developer] Soft proofing and the GIMP Display Filters and Color Management settings
On Tue, 2014-03-11 at 15:45 -0300, Gez wrote: There are three possible workflows for print: Early binding: All the assets are converted to CMYK and editing is done in CMYK. The files you send to the print shop are CMYK. Late Binding: Everything is worked in RGB. The print shop converts to CMYK. Intermediate Binding: Creative work is done in RGB, the files are converted to CMYK prior sending them to the print shop. GIMP can't edit CMYK directly, but it can serve to the other two possible workflows. Note that the case I mentioned the other day as seeming to be out of scope is when you *are* the print shop, and you (sometimes) receive the cmyk files, or need to edit them. E.g. remove an impression number from the imprint page and then send to imposition... but it seems it's in scope and just not there yet. [...] Having the title/status bar(s) show which display filters are active would be very useful, especially given that if you close the display filter window, any activated filters (or deactivated, in the case of the Color Management filter) are still applied to the image. That would be an interesting addition, but I wonder if the current model of having multiple working profiles can't be replaced by something more useful. This is probably off-topic, but having to worry about the file profile, a working profile, a print preview profile and a print profile in the preferences as global settings seems messy and inefficient. And in GIMP 2.9 it probably doesn't make so much sense as it used to. The world is messy, I'm afraid. From a user point of view having all the imported stuff converted automatically to a high quality internal model (high bit depth linear scRGB?) and having per-image output/proof settings seems more straightforward and less error prone than the current mixture of profiles. Are you going to pay for the extra memory I'll need? I only have 32G and already with 2.9 I sometimes am swapping. It may or may not be a problem for keeping legacy compatibility, but I can imagine how simplified the UI and common workflows would be (no bit-depth modes, no assign/convert to profile, no profile-mismatch warnings, simplified CM preferences, etc). You might not always be able to do round-tripping, because a colour in the input image's colour model might be out of gamut for the working profile. I don't know how big an issue that would be. Similarly you'd end up using colours that wouldn't come out at all right on your output device. The warnings are there for a reason... Best, Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org freenode/#xml ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
[Gimp-developer] XCF error: unsupported XCF file version 7 encountered
I updated glib/babl/gegl/gimp from git a couple of days ago. Then I opened an existing xcf file, worked on it, saved it, and closed GIMP. The next day I couldn't open the xcf file. The error message is: XCF error: unsupported XCF file version 7 encountered I deleted the installation directory, did git clean -xdf, and rebuilt everything from scratch. The error message was still triggered by making a new xcf file (File/New), saving it to disk as anything other than an 8-bit integer image, then closing and reopening it. This AM I did git reset to push babl/gegl/gimp back to the last commit in February and then rebuilt everything. At that point I could save and then reopen any precision xcf file, except the xcf files that had already been saved as version 7. Then I did git pull to bring GIMP (but not babl or gegl) up to date again. And now I can only save, close, and then reopen an 8-bit integer gamma image. Saving any other precision xcf file produces the error message as soon as the file is closed and then reopened. Checking with exiftool shows: ~/edit/test-xcf-version $ exiftool -s -XCFVersion -FileModifyDate *.xcf new-8i-gamma.xcf XCFVersion : 0 FileModifyDate : 2014:03:12 07:25:14-04:00 new-32f-gamma.xcf XCFVersion : Unknown (v007) FileModifyDate : 2014:03:12 07:24:09-04:00 2 image files read Previously created xcf files show variously XCFVersion : Unknown (v006) XCFVersion : Unknown (v005) Opening and then resaving a version 5 or 6 xcf file under a new name produces version 7, that can't be reopened. Is this a bug that affects everyone, or is there something wrong with my installation? Is there any chance of opening my version 7 xcf files from two days ago? I'm running 64-bit Gentoo. Just prior to the version 7 problem I had done a complete Gentoo update. Also I had checked the GIMP log and then updated glib to glib from git. I also tried glib-2.39.91. glib/babl/gegl/gimp are all in a prefix defined by the following: export INSTALL_PREFIX=/home/elle/code/gimp291/run export SRC_DIR=/home/elle/code/gimp291/build export PATH=$INSTALL_PREFIX/bin:$PATH export PKG_CONFIG_PATH=$INSTALL_PREFIX/lib/pkgconfig:$PKG_CONFIG_PATH export LD_LIBRARY_PATH=$INSTALL_PREFIX/lib:$LD_LIBRARY_PATH Thanks in advance for any help in retrieving my version 7 xcf files, or at least in figuring out how to avoid creating new version 7 xcf files. Elle ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] XCF error: unsupported XCF file version 7 encountered
On Wed, 2014-03-12 at 07:59 -0400, Elle Stone wrote: I updated glib/babl/gegl/gimp from git a couple of days ago. Then I opened an existing xcf file, worked on it, saved it, and closed GIMP. The next day I couldn't open the xcf file. The error message is: XCF error: unsupported XCF file version 7 encountered Oops, sorry, fixed :) commit 9a8aa70b85000963c14c6cae8326475d5b6f3e35 Author: Michael Natterer mi...@gimp.org Date: Wed Mar 12 15:21:21 2014 +0100 xcf: forgot to register a loader for XCF version 7 app/xcf/xcf.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] XCF error: unsupported XCF file version 7 encountered
On 03/12/2014 10:27 AM, Michael Natterer wrote: On Wed, 2014-03-12 at 07:59 -0400, Elle Stone wrote: I updated glib/babl/gegl/gimp from git a couple of days ago. Then I opened an existing xcf file, worked on it, saved it, and closed GIMP. The next day I couldn't open the xcf file. The error message is: XCF error: unsupported XCF file version 7 encountered Oops, sorry, fixed :) commit 9a8aa70b85000963c14c6cae8326475d5b6f3e35 Author: Michael Natterer mi...@gimp.org Date: Wed Mar 12 15:21:21 2014 +0100 xcf: forgot to register a loader for XCF version 7 app/xcf/xcf.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) That fixed the problem. Thanks! ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Soft proofing and the GIMP Display Filters and Color Management settings
On 03/11/2014 02:39 PM, Omari Stephens wrote: That said, I think your question touches on something that I'm pretty ignorant about, which is how color profiles deal with different numbers and types of channels. How monitors can use more than three channels (some already do) to make colors is easy to visualize: http://ninedegreesbelow.com/photography/all-the-colors.html#some Some cameras also use more than three colors (sensor lens cap colors) to capture colors. Hopefully the printer people will correct me if I'm speaking nonsense here. CMYK printer profiles have four channels because ink produces color subtractively, but not perfectly, as inks are not as narrow pass reflective as one might like. So using C+M+Y to make black produces a muddy black and uses a lot of ink, which is sloppy to print. So the fourth color is black. More than four colors of ink gives smoother color reproduction and also may extend the available color gamut, depending on the inks. The corresponding ICC profile is a Lookup Table profile, which basically says r% ink-1 + s% ink-2 + t% ink-3 + u% ink-4 + . . . + z% ink-n (where r, s, t, u, . . . z are arbitrary percentages) equals a particular location in the CIELAB reference color space, for all possible combinations of various percentages of the n available inks. I know there is a thing called a GRAY profile, but I have no idea what makes it special or different than a standard profile. Is it basically an RGB profile with R==G==B? Yes in effect, no as far as the actual grayscale profile goes. A grayscale profile only has a single channel that holds luminance information in the form of a curve that goes from 0 to max white. Any RGB matrix profile with an equivalent tone reproduction curve will match the grayscale profile as long as R=G=B for all pixels in the RGB image. Each channel in the RGB image will match the single channel in the grayscale image. I've never seen a LUT grayscale profile. But for matrix grayscale profiles, the only information needed to define the profile is the white point, the black point (which is zero for all the matrix Grayscale profiles I've ever seen), and the tone reproduction curve (aka tone response curve). RGB matrix profiles also need red, green, and blue colorant tags. From a practical point of view, less disk storage is required for a grayscale image, compared to an RGB image with R=G=B for all three channels. Does GIMP uses less RAM and/or CPU power to process a grayscale image, compared to an RGB image where R=G=B? In the New GEGL World, converting between different channel layouts is going to be a reality, and we should at least put _some_ thought into what that means for color management. Of course, this is way out of my depth, and I have no idea. I'm also curious as to what gegl n-channel editing might be like. Soft proofing to an n-channel printer is a one use case for n-channel editing, when the goal is to convert to the n-channel ICC profile and tweak the channels while soft proofing. Hopefully again the printer people will correct me if I'm speaking nonsense. Dan Margulis gives examples of image editing in an artificial CMYK matrix color space, requiring four channels. Would there be a use case for editing in n-space (as opposed to soft proofing to an n-space output profile), where n is greater than 4? LCMS2 already accomodates n-channel ICC profile conversions. The GIMP lcms.c plugin doesn't, but support could be added. Elle ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Soft proofing and the GIMP Display Filters and Color Management settings
On Thu, Mar 13, 2014 at 1:27 AM, Elle Stone wrote: Would there be a use case for editing in n-space (as opposed to soft proofing to an n-space output profile), where n is greater than 4? You mean, like CMYK + PANTONE 877C? Alexandre ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Soft proofing and the GIMP Display Filters and Color Management settings
El mié, 12-03-2014 a las 17:27 -0400, Elle Stone escribió: On 03/11/2014 02:39 PM, Omari Stephens wrote: Hopefully the printer people will correct me if I'm speaking nonsense here. CMYK printer profiles have four channels because ink produces color subtractively, but not perfectly, as inks are not as narrow pass reflective as one might like. So using C+M+Y to make black produces a muddy black and uses a lot of ink, which is sloppy to print. So the fourth color is black. That's spot on. Another reason is that black ink (carbon based) is cheaper than color inks (and 1 ink pass is cheaper than three pases, and it dries faster). However, because blank ink isn't perfect either, a pure black pass doesn't look deep enough in large areas and will look rather like dark gray than like black, so it's common to add a little C, M and Y to get a rich black. More than four colors of ink gives smoother color reproduction and also may extend the available color gamut, depending on the inks. The corresponding ICC profile is a Lookup Table profile, which basically says r% ink-1 + s% ink-2 + t% ink-3 + u% ink-4 + . . . + z% ink-n (where r, s, t, u, . . . z are arbitrary percentages) equals a particular location in the CIELAB reference color space, for all possible combinations of various percentages of the n available inks. The color profile also contains additional information like black generation, and TAC (Total Area Coverage percentage, a maximum ink coverage recommended for the media used). If you go beyond that value the media will take longer to dry, dot gain could saturate and mud details, etc. In the New GEGL World, converting between different channel layouts is going to be a reality, and we should at least put _some_ thought into what that means for color management. Of course, this is way out of my depth, and I have no idea. I'm also curious as to what gegl n-channel editing might be like. Soft proofing to an n-channel printer is a one use case for n-channel editing, when the goal is to convert to the n-channel ICC profile and tweak the channels while soft proofing. Hopefully again the printer people will correct me if I'm speaking nonsense. Dan Margulis gives examples of image editing in an artificial CMYK matrix color space, requiring four channels. Margulis is a respected name, but I'd take what he says with a grain of salt. The last time I checked he still insisted that doing creative editing in device CMYK is a great idea and that color management failed, something that contradicts the direction of the entire graphic industry for the last 15 years. Would there be a use case for editing in n-space (as opposed to soft proofing to an n-space output profile), where n is greater than 4? If you have to treat one of the CMYK primaries as a spot color, or if you need an extra spot color, then yes. It's indeed useful and a quite common requirement in the print industry. For instance, if you have a color that can't be achieved mixing CMYK inks (saturated greens, oranges, blues, etc.), an extra print pass is used, inking with a specially formulated ink that reproduces the exact color you need. That's what a spot color means. When you want to get red mixing 100% yellow and 100% magenta (and you want that exact combination) you're using both yellow and magenta as they were spot channels. It has nothing to do with CMYK, because you're overriding color management and using an arbitrary mix, not a colorimetric translation. Perhaps this is not a popular point of view, but in my opinion, using CMYK just because you want to tweak channels manually (as if it was possible to predict the printed output of that procedure) is a bad idea. If you want to work on a computer screen and send the output to print, the most reliable way to get the color appearance properly translated is a solid color managed workflow. Spot plates only have to be color corrected for previewing purposes, but they won't be separated in individual channels. They are extra channels, completely separated from the CMYK process colors. The only interaction with the CMYK channels is defining overprinting/knockout. Gez ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Soft proofing and the GIMP Display Filters and Color Management settings
[ resending this to the list, at Gez's request :) ] On Wed, 2014-03-12 at 17:43 -0300, Gez wrote: El mié, 12-03-2014 a las 02:19 -0400, Liam R E Quin escribió: On Tue, 2014-03-11 at 15:45 -0300, Gez wrote: Note that the case I mentioned the other day as seeming to be out of scope is when you *are* the print shop, and you (sometimes) receive the cmyk files, or need to edit them. E.g. remove an impression number from the imprint page and then send to imposition... but it seems it's in scope and just not there yet. You're right, there's no free software tool fully capable for that purpose. [...] I'm curious to know how many print shops would consider using GIMP if it had native CMYK. I suspect that the majority of people ranting about the lack of CMYK are mostly designers who know just one way to send stuff to print shops, not print shops. The print shops I know generally use either mac-based tools or proprietary RIP systems, or (usually) both. But the future is longer than the now. [...] Ok, good point. I missed the segment of users who work with huge scans completely. On the other hand, is 8-bit enough for the type of work you do? I scan at 8bpp 2400dpi, or at 16bpp 1800 or 2100dpi right now; when I scan an A3 page at 16bpp and 2400dpi, as I did for http://www.fromoldbooks.org/DehioBezold-Kirchliche/pages/001-600dpi/ as an experiment, Gimp quickly reached over 15G of memory, and I needed to use discard undo history after every operation, so I quickly scaled the image down. For the rest of that book I'll be scanning the individual figures. Like you, I do prefer the higher bit depths, so it's a compromise. [...] Anyway, rather than bitdepth, my comment was about giving the artists a framework to create freely without worrying (much) about the constraints of input/output colorspaces. It's impossible to have that with 8 bpc. And correct me if I'm wrong, but I suspect that using proofing filters on non-linear 8bpc carries a lot of problems and the result can't be completely reliable. No, I think it's probably fine. Most commercial RIPs these days deal with at least 10 and more likely 16bpp. Maybe we can have the flexibility and power just keeping two modes: 16 bit integer for memory-conservative tasks and 32 bit float for high quality stuff. That would rule out editing GIF animations and also make preparing images for the Web or for use n mobile devices very hard. [...] lots of good stuff deleted, because... Anyway, this is just an idea. It's not a small change and I'm not suggesting that it has to be done the way I said. I think this is an interesting topic to discuss since seems more suitable for non-destructive editing than the current approach. Yes. Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org freenode/#xml ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Soft proofing and the GIMP Display Filters and Color Management settings
El mié, 12-03-2014 a las 02:19 -0400, Liam R E Quin escribió: On Tue, 2014-03-11 at 15:45 -0300, Gez wrote: Note that the case I mentioned the other day as seeming to be out of scope is when you *are* the print shop, and you (sometimes) receive the cmyk files, or need to edit them. E.g. remove an impression number from the imprint page and then send to imposition... but it seems it's in scope and just not there yet. You're right, there's no free software tool fully capable for that purpose. The Separate+ plugin offers a rudimentary solution for that. The resulting layered composite is far from ideal (ugly would be a better description) but it kind of works. Krita, although has native CMYK mode, it doesn't offer the tools (at least not yet) for that kind of job. Early binding is still here. I can live without it, but of course that it wouldn't be the case if I was a print-shop. I'm curious to know how many print shops would consider using GIMP if it had native CMYK. I suspect that the majority of people ranting about the lack of CMYK are mostly designers who know just one way to send stuff to print shops, not print shops. From a user point of view having all the imported stuff converted automatically to a high quality internal model (high bit depth linear scRGB?) and having per-image output/proof settings seems more straightforward and less error prone than the current mixture of profiles. Are you going to pay for the extra memory I'll need? I only have 32G and already with 2.9 I sometimes am swapping. No, but I can make you some coffee while you wait :-p Ok, good point. I missed the segment of users who work with huge scans completely. On the other hand, is 8-bit enough for the type of work you do? Although I'm still using 8 bpc for my work because I do it with GIMP 2.8, I have a really hard time trying to keep good quality after a few rounds of edits. Maybe defaulting to 32bpc is too resource-intensive for a lot of works, but wouldn't make more sense to have a higher quality default for editing and keeping 8 bpc just as an output bit depth? Anyway, rather than bitdepth, my comment was about giving the artists a framework to create freely without worrying (much) about the constraints of input/output colorspaces. It's impossible to have that with 8 bpc. And correct me if I'm wrong, but I suspect that using proofing filters on non-linear 8bpc carries a lot of problems and the result can't be completely reliable. Maybe we can have the flexibility and power just keeping two modes: 16 bit integer for memory-conservative tasks and 32 bit float for high quality stuff. Economy of system resources is important, but I'm sure that image quality is far more important in a image manipulation program. It may or may not be a problem for keeping legacy compatibility, but I can imagine how simplified the UI and common workflows would be (no bit-depth modes, no assign/convert to profile, no profile-mismatch warnings, simplified CM preferences, etc). You might not always be able to do round-tripping, because a colour in the input image's colour model might be out of gamut for the working profile. I don't know how big an issue that would be. Similarly you'd end up using colours that wouldn't come out at all right on your output device. The warnings are there for a reason... scRGB exceeds the gamut of the usual profiles, following what I proposed in the previous message, if you go -for instance- AdobeRGB - scRGB - AdobeRGB with enough precision that shouldn't be a problem and RGB - CMYK roundrip is impossible anyway. I'm not an expert by any means and I might be wrong, but that doesn't seem to contradict what I said. And regarding you'd end up using colours that wouldn't come out at all right on your output device, that's exactly what soft-proofing (the topic of this thread) would prevent. If you have in the workflow I presented, say an AdobeRGB image as input, it would be converted to scRGB. All its colours would fall inside the scRGB gamut, so no problem. If you save back to AdobeRGB without changing anything, color shouldn't change. If you save to sRGB, colors would have to be converted using a rendering intent, because the output gamut is smaller. You could soft-proof your editing against sRGB to see how colors would be affected with the selected rendering intent. The good thing about this is that your XCF file would store unmodified color information, and that would allow to save later to AdobeRGB, Prophoto or whatever you want. Now, if you were obligated to convert your imported image to a working profile (like you are now), and that profile has a smaller gamut than the original image, your imported image is hopelessly degraded. You're always tied to the color gamut of your working RGB profile. Anyway, this is just an idea. It's not a small change and I'm not suggesting that it has to be done the way I said. I think this is an interesting topic to discuss since seems
Re: [Gimp-developer] Soft proofing and the GIMP Display Filters and Color Management settings
El mié, 12-03-2014 a las 23:35 -0400, Liam R E Quin escribió: [ resending this to the list, at Gez's request :) ] Sorry for the accidental private mail :) Anyway, rather than bitdepth, my comment was about giving the artists a framework to create freely without worrying (much) about the constraints of input/output colorspaces. It's impossible to have that with 8 bpc. And correct me if I'm wrong, but I suspect that using proofing filters on non-linear 8bpc carries a lot of problems and the result can't be completely reliable. No, I think it's probably fine. Most commercial RIPs these days deal with at least 10 and more likely 16bpp. Notice that I'm talking about processing only. The output bitdepth should be the usual for each file format (for instance, although commercial RIPs no longer choke with 16bpc files, it's still recommended to send 8 bit and probably sending more won't make any difference, at least for offset). Maybe we can have the flexibility and power just keeping two modes: 16 bit integer for memory-conservative tasks and 32 bit float for high quality stuff. That would rule out editing GIF animations and also make preparing images for the Web or for use n mobile devices very hard. Why? Again, processing in high bit depth, soft-proofing against the target colorspace, saving to the destination bitdepth and profile. The project file keeps data and color latitude, the exported files are converted to the desired parameters. You can do exactly that with Blender's compositor, and it can save JPGs or PNG for the web. If an 8-bpc buffer can be displayed, the it's probably possible to generate an indexed projection on the fly, pretty much like gimp-2.9 does now. Gez. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
