Luminous Landscape Forum
Raw & Post Processing, Printing => Printing: Printers, Papers and Inks => Topic started by: ralph257 on August 13, 2017, 12:04:24 pm
-
While listening to a lecture on "Fine Art Printing" given by a member of my photo club
he proceeded to tell us that since Epson Stylus pro printers were native resolution 360
it is wise to only send the printer files of that rez so the printer does not upscale or downscale them.
Now, My understanding is Inkjets don't print pixels they print dots, and inkjets print Stochastically and dither
as opposed to printing on a line screen as offset does.
It seems as though their is much confusion in this regard
Where is the best source both for terminology and understanding of these problems? :-\
-
Page 130 of Jeff Schewe's "The Digital Print".
-
While listening to a lecture on "Fine Art Printing" given by a member of my photo club
he proceeded to tell us that since Epson Stylus pro printers were native resolution 360
it is wise to only send the printer files of that rez so the printer does not upscale or downscale them.
Now, My understanding is Inkjets don't print pixels they print dots, and inkjets print Stochastically and dither
as opposed to printing on a line screen as offset does.
It seems as though their is much confusion in this regard
Where is the best source both for terminology and understanding of these problems? :-\
In my opinion, Jeff Schewe's book "The Digital Print" is a good place to start. It will answer a lot of your printing questions, including the one you have posted here.
Gary
WOOPS!!! Sorry Mark, I guess we were both writing simultaneously with the same information.
-
it is already ordered and I await delivery
But why do ppl confuse this issue so?
-
In my opinion, Jeff Schewe's book "The Digital Print" is a good place to start. It will answer a lot of your printing questions, including the one you have posted here.
Gary
WOOPS!!! Sorry Mark, I guess we were both writing simultaneously with the same information.
Fun we both we went to the same place at the same time!
-
it is already ordered and I await delivery
But why do ppl confuse this issue so?
Well, it's not really confusion - it's two different things that need different terminology so we know what we're talking about. PPI, pixels per inch, is the resolution of the photo. The printer needs a fixed input resolution from which to do its work, (for example the 360 nozzles per inch of an Epson printhead). The printer needs to reproduce image pixel values by mixing and spreading ink dots to render each pixel's colour values, and that's where the ink droplets, dithering and screening business comes in.
-
I should add another excellent source of information on all this - very detailed - Chapter Two of Harald Johnson's "Mastering Digital Printing - Second Edition". It's older (2004), but the basics on this stuff don't change. (Disclaimer: I made a pro bono contribution to this book on testing scanner resolution for print quality).
Amazon-Mastering Digital Printing (https://www.amazon.com/s/ref=nb_sb_noss?url=search-alias%3Daps&field-keywords=Johnson+Mastering+Digital+Printing+second+edition)
-
I should add another excellent source of information on all this - very detailed - Chapter Two of Harald Johnson's "Mastering Digital Printing - Second Edition". It's older (2004), but the basics on this stuff don't change. (Disclaimer: I made a pro bono contribution to this book on testing scanner resolution for print quality).
Amazon-Mastering Digital Printing (https://www.amazon.com/s/ref=nb_sb_noss?url=search-alias%3Daps&field-keywords=Johnson+Mastering+Digital+Printing+second+edition)
Yes again Mark, we are on the same wavelength I believe. However, I had forgotten about this book(first edition), which resides on a shelve just above my work station. Probably the first digital printing book I purchased, 2004 I think. Excellent reference source as well.
Gary
-
Well, it's not really confusion - it's two different things that need different terminology so we know what we're talking about. PPI, pixels per inch, is the resolution of the photo. The printer needs a fixed input resolution from which to do its work, (for example the 360 nozzles per inch of an Epson printhead). The printer needs to reproduce image pixel values by mixing and spreading ink dots to render each pixel's colour values, and that's where the ink droplets, dithering and screening business comes in.
Epson and Canon printer drivers need a fixed resolution to make their error diffusion algorithms work, but it doesn't have to be that way:
http://blog.kasson.com/the-last-word/lets-do-away-with-resampling-for-printing/
Jim
-
The printer needs a fixed input resolution from which to do its work, (for example the 360 nozzles per inch of an Epson printhead). The printer needs to reproduce image pixel values by mixing and spreading ink dots to render each pixel's colour values, and that's where the ink droplets, dithering and screening business comes in.
As a matter of programming in their current drivers, that appears to be correct, but:
Epson and Canon printer drivers need a fixed resolution to make their error diffusion algorithms work, but it doesn't have to be that way:
I need to read Jim's blog post, but it has struck me as odd the way printer manufacturers insist on, say, using the printhead's 5760x1440 ink dots per ink to render precisely 360x360 image pixels per inch, i.e., to insist on using a 16x4 dot array of positions into which to place one (or none) dot of one of the of the 4, 6, 10, whatever ink colors, and thereby simulate continuous tone for each pixel. There may have been a time when computing hardware was slow enough that this simplification (or at least this degree of pre-processing) was necessary for good function. But if I decide in any particular case that image fine detail isn't that important and smooth tonality is, why can't I, say, choose to use the physically-available 5760x1440 ink dots to render 240x240 pixels per inch with 24x6 ink dots per pixel? Or going in the other way, as as been suggested around here and elsewhere, if I decide that fine detail is more important than smooth tonality for a specific image, then I may want to use 5760x1440 ink dots to render 720x720 pixels per inch with 8x2 ink dots per pixel--why not? Defaults and recommendations are all fine. But I don't see any good reason not to let knowledgeable users select at least any evenly-divisible value along this continuum, based on their personal preferences and the needs of the particular image being printed.
-
Epson and Canon printer drivers need a fixed resolution to make their error diffusion algorithms work, but it doesn't have to be that way:
http://blog.kasson.com/the-last-word/lets-do-away-with-resampling-for-printing/
Jim
But if the resampling is done by their driver how do they get the colors into linear space which is needed for proper driver resampling? The driver doesn't have that info does it?
-
In terms of why you can't just build your own matrix? Well, at any given pixel representation you have to not only decide what size dot (if the printer has variable dot sizes) of each colour and its placement to build that pixel representation, but also how it affects the representation of the colour pixel next to it (which means all around it), and to minimise metamerism and so on. The LUT that the printers have available in terms of matching combinations to achieve not only the individual pixel representation but also the total effect of all the represented pixels is huge. It's in the hundreds of billions of possibilities. Then it depends on the output resolution you want (trading accuracy against speed), whether you're printing uni or bi directional (again accuracy with speed), considering the media and the drying times and so on.
If you open that up to "any matrix you like" means not only increasing the combinations and the processing needed to render that image, but also an expectation that users know what the impact is of changing the matrix. It also impacts on the physical precision and movement of paper and print heads to achieve those results and, if there's a print quality issue, the problem of trying to diagnose whether it's the custom matrix or something else doing it.
Jim's article addresses some of these complexities, but I think it misses the vast amount of data involved in the LUT for the colour decisions. The more variables, the bigger that becomes and the more choices that need to be made. And, most importantly, where is the evidence to suggest that the current iterations aren't already quite optimal compared to others that might be proposed? In other words, if you allow change, what is the return on investment? How much better (if at all) would a print be compared to the cost in time, money, computing power, and so on?
Even RIP vendors don't venture outside of these realms, and if you have seen the time taken to RIP large images on even the fastest hardware you'll realise that it's still processor intensive and produces very large rasterised image files.
-
I need to read Jim's blog post, but it has struck me as odd the way printer manufacturers insist on, say, using the printhead's 5760x1440 ink dots per ink to render precisely 360x360 image pixels per inch, i.e., to insist on using a 16x4 dot array of positions into which to place one (or none) dot of one of the of the 4, 6, 10, whatever ink colors, and thereby simulate continuous tone for each pixel.
The halftoning algorithm used by Epson (and, I presume, Canon) is more sophisticated than that, using error diffusion with blue noise added to break up the "worms". Thus, the "target" image from which the error is computed is sampled coarsely compared to the marking engine resolution, but the error is computed at each marking-engine-addressable point.
Jim
-
But if the resampling is done by their driver how do they get the colors into linear space which is needed for proper driver resampling? The driver doesn't have that info does it?
First off, it is not clear at all that resampling is best done in a linear space. That's how Lr did it in their earlier releases, and that was the source of some of their (now fixed) printing problems.
Second, if your resampling algorithm is nearest neighbor (NN), which is the algorithm used by Epson in their driver, you get the same answer no matter what nonlinearity you choose. NN is a meataxe resampling algorithm but that doesn't keep Epson from using. it.
Jim
-
In terms of why you can't just build your own matrix? Well, at any given pixel representation you have to not only decide what size dot (if the printer has variable dot sizes) of each colour and its placement to build that pixel representation, but also how it affects the representation of the colour pixel next to it (which means all around it), and to minimise metamerism and so on. The LUT that the printers have available in terms of matching combinations to achieve not only the individual pixel representation but also the total effect of all the represented pixels is huge. It's in the hundreds of billions of possibilities. Then it depends on the output resolution you want (trading accuracy against speed), whether you're printing uni or bi directional (again accuracy with speed), considering the media and the drying times and so on.
Sounds like you're assuming clustered dot ordered dither halftoning. That's been out of favor for at least 20 years. Ulichney's "Digital Halftoning" was published in 1988, and pretty much shut the door on those techniques for high-quality output.
Jim
-
Jim's article addresses some of these complexities, but I think it misses the vast amount of data involved in the LUT for the colour decisions. The more variables, the bigger that becomes and the more choices that need to be made.
The assumption is that you can convert from colors to colorants before halftoning, using LUTs derived from experimental prints. Thus, you don't have to do things like Kubelka-Munk at the resolution of the marking engine. There may be small scale color errors, but you count on the chromaticity portion of the eye's CSF to average that out.
http://blog.kasson.com/the-last-word/chromaticity-csfs/
Jim
-
First off, it is not clear at all that resampling is best done in a linear space. That's how Lr did it in their earlier releases, and that was the source of some of their (now fixed) printing problems.
Second, if your resampling algorithm is nearest neighbor (NN), which is the algorithm used by Epson in their driver, you get the same answer no matter what nonlinearity you choose. NN is a meataxe resampling algorithm but that doesn't keep Epson from using. it.
Jim
Resampling in other than linear space can create varying levels of moire as it introduces harmonics which reflect downward of off Nyquist. Ideally, resampling upward should not alter the spectral components of images. There are resampling techniques that try to fill in higher frequency information based on assumptions about what natural images contain. There be dragons.
Caveat. Most of what I have done is, for instance, creating specialized charts of different sizes that will produce the same spectral characteristics when photographed at an appropriately scale distance. Images that are output referred are already munged (non linear intrinsically) and linear space up-sampling them is a different beast unless one can somehow revert them to scene referred, upsample, then convert back to output referred. Yuck. At that point it's really more a question of artistic objective.
-
Sounds like you're assuming clustered dot ordered dither halftoning. That's been out of favor for at least 20 years. Ulichney's "Digital Halftoning" was published in 1988, and pretty much shut the door on those techniques for high-quality output.
I'm not assuming anything really.
http://www.epson.com.au/downloads/pdf/epsonhdrinktech-54final.pdf
I can't find the article that mentioned the LUT was several hundred billion combinations in size, but that was the figure. The proposition of opening up the matrix size to the user really doesn't address the complexity of the LUT being employed, among other things, and I said it also doesn't provide commentary on the expected benefits versus the various costs.
It might be a wonderful idea, but so far the tangible benefits haven't been presented.
-
The assumption is that you can convert from colors to colorants before halftoning, using LUTs derived from experimental prints. Thus, you don't have to do things like Kubelka-Munk at the resolution of the marking engine. There may be small scale color errors, but you count on the chromaticity portion of the eye's CSF to average that out.
http://blog.kasson.com/the-last-word/chromaticity-csfs/
I'm not sure test prints really encapsulate the dimensions of the LUT in play here. At some point you obviously need to test, but I don't believe there's a suitable series of prints to be used to create LUTs of this complexity.
The examples on your blog are excellent, but also simple. You're not looking at multiple colour variations with an expectation of consistent rendering on a reflective (rather than transmissive) media across multiple substrates, inks, and lighting conditions.
-
The assumption is that you can convert from colors to colorants before halftoning, using LUTs derived from experimental prints. Thus, you don't have to do things like Kubelka-Munk at the resolution of the marking engine. There may be small scale color errors, but you count on the chromaticity portion of the eye's CSF to average that out.
http://blog.kasson.com/the-last-word/chromaticity-csfs/
Jim
Interesting study. Not sure if you intended this but Lab(50,-35,0) should be balanced by Lab(50,28,0) to average out as neutral: lab(50,0,0). I don't think it matters much for what you are showing. Just that you can't just add equal amounts of *a and -*a and have them cancel.
-
Page 130 of Jeff Schewe's "The Digital Print".
Or:
https://www.digitalphotopro.com/technique/photography-workflow/the-right-resolution/ (https://www.digitalphotopro.com/technique/photography-workflow/the-right-resolution/)
The people at Epson say that the print driver doesn’t do the re-sampling, and since the application sending the print doesn’t do the resampling unless asked to do so, the resampling must be happening in the print pipeline. I’ve tried, unsuccessfully, to get confirmation from Apple and Microsoft about their respective print engine activities regarding the resampling of the image data. So I really don’t know where or how the resampling is being done. But I’m convinced some sort of resampling is being done. Is it an optimal resampling algorithm, or is it something done for speed? I don’t know, but I suspect, at best, it’s a compromise in favor of speed. I’m pretty sure there are better, optimized resampling algorithms that could do a superior job. In fact, Adobe Photoshop Lightroom resampling is a hybrid Bicubic algorithm that interpolates between Bicubic and Bicubic Smoother for upsampling and Bicubic and Bicubic Sharper for downsampling.
-
I'm not sure test prints really encapsulate the dimensions of the LUT in play here. At some point you obviously need to test, but I don't believe there's a suitable series of prints to be used to create LUTs of this complexity.
When I make LUTs, I used several thousand color patches and read them with an iSis XL
Jim
-
The examples on your blog are excellent, but also simple. You're not looking at multiple colour variations with an expectation of consistent rendering on a reflective (rather than transmissive) media across multiple substrates, inks, and lighting conditions.
Every time you change halftoning algorithm, inkset, media, or -- to some extent -- print illumination, you need to make new LUTs.
Jim
-
Resampling in other than linear space can create varying levels of moire as it introduces harmonics which reflect downward of off Nyquist. Ideally, resampling upward should not alter the spectral components of images. There are resampling techniques that try to fill in higher frequency information based on assumptions about what natural images contain. There be dragons.
Caveat. Most of what I have done is, for instance, creating specialized charts of different sizes that will produce the same spectral characteristics when photographed at an appropriately scale distance. Images that are output referred are already munged (non linear intrinsically) and linear space up-sampling them is a different beast unless one can somehow revert them to scene referred, upsample, then convert back to output referred. Yuck. At that point it's really more a question of artistic objective.
Some time ago, I did a lot of work lots and lots of help from Bart van der Wolf and Nicholas Robidoux on downsampling. I can provide references and we can talk about the proper nonlinearity for the computations if you wish, but that would be series thread drift.
But, as I said earlier, if you use NN, as the Epson driver does, it doesn't make any difference. Resample a PPRGB image directly or convert it to a linear space with the same primaries and WP, resample, and convert it back and you're going to get the same answer.
Jim
-
Or:
https://www.digitalphotopro.com/technique/photography-workflow/the-right-resolution/ (https://www.digitalphotopro.com/technique/photography-workflow/the-right-resolution/)
The people at Epson say that the print driver doesn’t do the re-sampling, and since the application sending the print doesn’t do the resampling unless asked to do so, the resampling must be happening in the print pipeline. I’ve tried, unsuccessfully, to get confirmation from Apple and Microsoft about their respective print engine activities regarding the resampling of the image data. So I really don’t know where or how the resampling is being done. But I’m convinced some sort of resampling is being done. Is it an optimal resampling algorithm, or is it something done for speed? I don’t know, but I suspect, at best, it’s a compromise in favor of speed. I’m pretty sure there are better, optimized resampling algorithms that could do a superior job. In fact, Adobe Photoshop Lightroom resampling is a hybrid Bicubic algorithm that interpolates between Bicubic and Bicubic Smoother for upsampling and Bicubic and Bicubic Sharper for downsampling.
Here is an old test I did that proves that the Epson resampling is NN:
http://blog.kasson.com/technical/injet-printing-on-epson-part-3/
Jim
-
Some time ago, I did a lot of work lots and lots of help from Bart van der Wolf and Nicholas Robidoux on downsampling. I can provide references and we can talk about the proper nonlinearity for the computations if you wish, but that would be series thread drift.
I'm curious about this but, yeah, it's thread drift. I'll PM.
But, as I said earlier, if you use NN, as the Epson driver does, it doesn't make any difference. Resample a PPRGB image directly or convert it to a linear space with the same primaries and WP, resample, and convert it back and you're going to get the same answer.
No disagreement. I didn't mean to suggest that in regards to printer NN interpolation.
Jim
-
Here is an old test I did that proves that the Epson resampling is NN:
http://blog.kasson.com/technical/injet-printing-on-epson-part-3/
Jim
I just checked the Canon. It's also NN.
-
I just checked the Canon. It's also NN.
Thanks, Doug. Good to know.
Jim
-
Or:
https://www.digitalphotopro.com/technique/photography-workflow/the-right-resolution/ (https://www.digitalphotopro.com/technique/photography-workflow/the-right-resolution/)
The people at Epson say that the print driver doesn’t do the re-sampling, and since the application sending the print doesn’t do the resampling unless asked to do so, the resampling must be happening in the print pipeline. I’ve tried, unsuccessfully, to get confirmation from Apple and Microsoft about their respective print engine activities regarding the resampling of the image data. So I really don’t know where or how the resampling is being done. But I’m convinced some sort of resampling is being done. Is it an optimal resampling algorithm, or is it something done for speed? I don’t know, but I suspect, at best, it’s a compromise in favor of speed. I’m pretty sure there are better, optimized resampling algorithms that could do a superior job. In fact, Adobe Photoshop Lightroom resampling is a hybrid Bicubic algorithm that interpolates between Bicubic and Bicubic Smoother for upsampling and Bicubic and Bicubic Sharper for downsampling.
Andrew,
GREAT to see you post here!!!
Rand
-
Andrew,
GREAT to see you post here!!!
Rand
Ditto!!!
-
Thanks, Doug. Good to know.
Jim
A decade ago I used the Qimage Ultimate resolution targets to check whether the HP Z3100 driver etc had a decent anti-aliasing routine on downsampling. It did not, aliasing was very visual, NN resampling most likely. An old message on that subject;
https://groups.yahoo.com/neo/groups/QuadtoneRIP/conversations/messages/7073
Met vriendelijke groet, Ernst
http://www.pigment-print.com/spectralplots/spectrumviz_1.htm
March 2017 update, 750+ inkjet media white spectral plots
-
Here is an old test I did that proves that the Epson resampling is NN:
http://blog.kasson.com/technical/injet-printing-on-epson-part-3/ (http://blog.kasson.com/technical/injet-printing-on-epson-part-3/)
Jim
Sorry, I'm not clear on the meaning of NN.
-
Sorry, I'm not clear on the meaning of NN.
Nearest neighbor
-
Nearest neighbor
Ah thanks, I should have figured that out. :o
So this agrees with Schewe's text and the idea one should resample using something much better then send the data to the print driver.
But what's producing this NN? Jeff states it's the OS pipeline if we are to believe what Epson wrote (it's not the driver).
-
Oh, and like others, I don't see the 340PPI example Jim.
-
Ah thanks, I should have figured that out. :o
So this agrees with Schewe's text and the idea one should resample using something much better then send the data to the print driver.
But what's producing this NN? Jeff states it's the OS pipeline if we are to believe what Epson wrote (it's not the driver).
This isn't a new discussion and usually the point at which it gets stuck for lack of vendor transparency. What's the big secret? There are only four places where resampling can happen: the application, the CMM in the OS, the printer driver, or the printer firmware. Between Adobe/Apple/MS/Epson why can't they just come out with a coherent story-line on how this works and where the operation is performed? I'm not sure what it buys us to know for sure, but at least to satisfy curiosity about the tools we are using, and perhaps helpful for some diagnostics here and there, who knows.
-
Between Adobe/Apple/MS/Epson why can't they just come out with a coherent story-line on how this works and where the operation is performed?
Because I'm pretty sure no one person actually knows the answer because each component; the application, the print driver and the OS are all being done by groups of people who are only responsible for subcomponents and don't know or understand the entire pipeline. Also not that the Mac and Windows pipelines are different and I think the drivers for each OS are different.
But, for the purposes of our discussion, it's 360/300 PPI for Epson/Canon or HP and 720/600 PPI for certain driver configs. That's pretty much proven, right :~)
-
Because I'm pretty sure no one person actually knows the answer because each component; the application, the print driver and the OS are all being done by groups of people who are only responsible for subcomponents and don't know or understand the entire pipeline. Also not that the Mac and Windows pipelines are different and I think the drivers for each OS are different.
But, for the purposes of our discussion, it's 360/300 PPI for Epson/Canon or HP and 720/600 PPI for certain driver configs. That's pretty much proven, right :~)
Jeff, there must be people who have a good overall command of what happens where. This has to be essential for each company to know what it needs to design and how to design it.
I agree the answer to the original concern is what you say above.
-
But, for the purposes of our discussion, it's 360/300 PPI for Epson/Canon or HP and 720/600 PPI for certain driver configs. That's pretty much proven, right :~)
It's 360/720 or 300/600 (P20000/10000) for Epson.
My understanding is that in OS X, the OS renders and uses a unique interpolation algorithm similar to bi-cubic or bi-linear (it's done via Quartz Compositor). In Windows, it's done by the driver and is based on NN.
Also, in the Settings dialogue, don't choose "Processed by Printer" - that's not to do with resolution directly, but it makes a decision about whether to send RGB to the printer for conversion to ESC/P or whether to do it on the computer within the driver. Sending it to the printer means the RGB is sent as a JPG (i.e. lossy compression). So don't do that :-)
-
Oh, and like others, I don't see the 340PPI example Jim.
Andrew, I'm sorry about that. There was a WordPress upgrade that rendered some in-line images unviewable. I really should go back and re-do the test.
Jim
-
It's 360/720 or 300/600 (P20000/10000) for Epson.
My understanding is that in OS X, the OS renders and uses a unique interpolation algorithm similar to bi-cubic or bi-linear (it's done via Quartz Compositor). In Windows, it's done by the driver and is based on NN.
Also, in the Settings dialogue, don't choose "Processed by Printer" - that's not to do with resolution directly, but it makes a decision about whether to send RGB to the printer for conversion to ESC/P or whether to do it on the computer within the driver. Sending it to the printer means the RGB is sent as a JPG (i.e. lossy compression). So don't do that :-)
Phil, which "Settings" dialogue do you have in mind here: is it in the printing application or in the driver? (Unfortunately, there are "settings" all over the place!)
-
My understanding is that in OS X, the OS renders and uses a unique interpolation algorithm similar to bi-cubic or bi-linear (it's done via Quartz Compositor). In Windows, it's done by the driver and is based on NN.
That's my broad understanding too, although I can't comment on the specific algorithms used. QuadToneRIP expects 720ppi as input and its author Roy Harrington has said that on OS X, QuadToneRIP requests that resolution and the printing pipeline delivers it. This resampling must be done in the printing pipeline, since there's no reason for Photoshop, Lightroom, Print Tool etc to do it. On Windows the OS doesn't resample and so Roy has said that QuadToneRIP has to do it itself if it receives an image in something other than 720ppi. Given this I'd expect the Epson or Canon drivers would perform this function if you were printing through the driver.
[Clarification: The Epson Windows driver resizes to 360ppi, and only to 720ppi under the finest detail setting. 300 / 600 ppi for Canon. QTR always operates on 720ppi.]
-
Phil, which "Settings" dialogue do you have in mind here: is it in the printing application or in the driver? (Unfortunately, there are "settings" all over the place!)
Yeah, fair question. Under "Speed and Progress" (which appears in slightly different places depending on the driver and the operating system - but that tab is the one you're after). By default, it's all good. It would only be an issue if someone has gone in and changed the settings themselves for some reason (generally with the idea that the driver/computer is released earlier from the print job - not really necessary these days).
-
Yeah, fair question. Under "Speed and Progress" (which appears in slightly different places depending on the driver and the operating system - but that tab is the one you're after). By default, it's all good. It would only be an issue if someone has gone in and changed the settings themselves for some reason (generally with the idea that the driver/computer is released earlier from the print job - not really necessary these days).
For OSX 10.11.x whether the SC-P5000 driver or ACPU, which accesses the same driver, there is no such tab.
-
For OSX 10.11.x whether the SC-P5000 driver or ACPU, which accesses the same driver, there is no such tab.
Sorry - Windows only!
-
Ah - fine, so I'm not missing anything. :-)
(I remember that tab from my pre-2010 Windows days. I think most of those functions are distributed around other tabs in the Mac Driver).
-
First off, it is not clear at all that resampling is best done in a linear space. That's how Lr did it in their earlier releases, and that was the source of some of their (now fixed) printing problems.
Second, if your resampling algorithm is nearest neighbor (NN), which is the algorithm used by Epson in their driver, you get the same answer no matter what nonlinearity you choose. NN is a meataxe resampling algorithm but that doesn't keep Epson from using. it.
Jim
Interesting post by a fellow that photographed a team of young women wearing narrow, vertically striped shirts. When he prints it he says he gets moire. Quite believable. There's an example of downsizing in Photoshop using gamma=1 as well as standard sRGB. It illustrates production of moire in Photoshop alone without gamma correction or switching to a gamma=1 space.
https://www.dpreview.com/forums/post/60143219