Pages: 1 2 3 [4] 5   Go Down

Author Topic: Lumejet Process Overview  (Read 21070 times)

hrwilliams

  • Newbie
  • *
  • Offline Offline
  • Posts: 21
Re: Lumejet Process Overview
« Reply #60 on: March 05, 2018, 05:50:28 am »

I've generally heard about 12 million but the point is, it's not anything like 16.7 or billions: IF you can't see it, it's not a color. So the bit (no pun intended) about such massive numbers of device values is, they are all not all colors (assuming we agree upon 12 million and marketing states billions, there's more we can't see than we can by a massive margin). Yet marketing from many, many companies keep trying to get customers to believe more is better. As for billions of device values, I'd be love anyone to demonstrate on a print that has more than 8-bits per color encoding of image data AFTER editing versus the high bit version produces any visual difference on the print. Bit depth is about editing overhead and again, I'd love to see someone demonstrate on a print, even with fine gradations that more than 8-bits per color of a final edited image is inferior to sending higher a bit cousin.

I completely agree with you in almost all respects. There was a typo in my original response where I said '1million to 14 million' - I mean to type 12 million, so apologies. Let's agree on 12 million discernible colours by a good human eye as a starting point. That is different to saying that the 4 billion theoretical combinations of R,G and B values that you can achieve using 32 bits of data re not all colours. Every single one of those combinations, fed into RGB LEDs and thus into pixels on the paper, produces a visible dot on the page. So all 4 billion combinations produce 4 billion dots. The point, as you say, is that many of those dots will look the same as each other or will not be discernible by the human eye from each other (though I'm still not convinced that the 12 million different colours you see are necessarily the same as the 12 million colours I see).

But imagine a colour whose values in some imaginary, simplified, visible RGB colour space are 1,1,1. Then imagine that the next discernible colour (varying one channel only) is 4,1,1. You and I might both agree that 2,1,1 and 3,1,1 are not discernible from 1,1,1 but they are still colours, and if I replace my two points of 1,1,1 and 4,1,1 with different points of 2,1,1 and 5,1,1 I will produce two perfectly visible (and probably discernible) dots. So one reason for having as many data points as possible is to achieve smooth gradations as you move along a tonal curve, and eliminate any stepping.

Now you are completely correct in saying that 8-bit colour is perfectly adequate in print. In fact, that's all we actually use in terms of our print engine - each of the LEDs is fed with 8-bit colour information from the RIP and that produces 16.8 million visible output combinations (some of which may still be indiscernible to the human eye). But each of our LEDs is controllable to either 11 bits or 10 bits (giving us 32bits in total). So the critical extra step that we undertake is in mapping the 24-bit data we get from an 8-bit RGB colour space to the 32-bit range of allowable inputs to our R,G and B LEDs. The thing is that silver halide paper is non-linear: a 1% increase in energy in, say, the red spectrum will typically not produce a 1% increase in density - and the relationship between energy increase and density increase varies all the way across the range in each of the three channels. It also differs for each paper we use. So having the 2/3 extra bits in each channel allows us to make very fine adjustments to the energy inputs of each channel at critical points in the energy curve in order to get the best possible calibration and colour profile for our printer. So, for example, about 18 months ago we were sent a test file to print by a very prominent camera manufacturer. That file consisted largely of a very pale grey sky that shaded from essentially paper-white to a very slightly darker grey, and had great subtlety throughout the mix of clouds shown. Our early attempts to print that produced a certain lack of smoothness in tonal gradation as we approached the media white point, and an inability to show all the subtlety in the clouds. We spent a good deal of time re-characterising our LED calibration in order to reproduce the correct amount of detail in those low-energy areas of the image (and we have repeated the effort at different points along the curve). I guess one of the key differentiators we would claim is that we are in a position to do this - just like (presumably) the R&D departments of any major printer manufacturer, but unlike the average print service company that has to take the printer it has purchased in the form in which it was provided - whether or not the calibration basis is as good as it should be.

So in summary I think I would say that the point about 4 billion colours could be much better phrased. We aim to produce 16.7 million different colour values on the page (2^24 combinations from 8-bit per channel colour). But to produce these accurately and smoothly, particularly in difficult areas of the gamut, we use the extra 'detail' available from the 32 bits of input data we have available for our LEDs, which gives us 4 billion potential colour combinations. And the mapping of the 24-bit space to the 32-bit space is one of the critical steps in producing the most accurate possible printer.
Logged

elliot_n

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1219
Re: Lumejet Process Overview
« Reply #61 on: March 05, 2018, 07:37:46 am »

Huw, I'm puzzled by the motivation for your research into refining the digital c-type process. You say that you were driven by a desire to render text better on a c-type, but who wants to print text on a c-type? There are countless other printing options for nice crisp text. I can see that a photographer might occasionally want to put an image caption on the border of a print – but fifteen years research to optimise that? Just curious :)
Logged

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20646
  • Andrew Rodney
    • http://www.digitaldog.net/
Re: Lumejet Process Overview
« Reply #62 on: March 05, 2018, 10:29:12 am »

That is different to saying that the 4 billion theoretical combinations of R,G and B values that you can achieve using 32 bits of data re not all colours.
Most, the same colors.  :D
Quote
So all 4 billion combinations produce 4 billion dots.
That be true if the image had 4 billion pixels all R0/B0/G0 or any one triplet. So what?
Quote
I'm still not convinced that the 12 million different colours you see are necessarily the same as the 12 million colours I see).
If you can't see it, it's not a color. Color is a perceptual property.
Quote
Now you are completely correct in saying that 8-bit colour is perfectly adequate in print.
Then all that talk of billions of colors device values is marketing. If I can't see the difference, so what?
Quote
each of the LEDs is fed with 8-bit colour information from the RIP and that produces 16.8 million visible output combinations
Visible output combinations; you want to consider that again based on previous text?
IF we can't see 16.7 million colors, how can we see 16.7 million visible output combinations? If I make an document for you to print that is 1000x1000 pixels, and every value is R34/B90/B123 is that one color or 1,000,000 visible output combinations let alone that many colors? I would suggest that document contains ONE color; R34/B90/B123. And if that color were instead R0/G255/B0 in ProPhoto RGB, it wouldn't even be a color (it would map to a color at some point after conversion to the print color space).
Quote
We aim to produce 16.7 million different colour values on the page (2^24 combinations from 8-bit per channel colour).
That may be your aim, but I suspect that's simply not the case. But I'm open to hear how we can see (an agreed upon value of 12 million colors for this discussion) AND 16.8 million visible output combinations. Further I challenge anyone here to output a document of any kind, after all edits in both 8-bit per color and high bit (what some may call 16-bit encoding even when it usually isn't) to any printer and illustrate the higher bit depth was visible superior. Seems that may not be possible with your device as it sounds like your front end (what you're calling a RIP) fed the LED's 8-bit per color data. If that understanding is correct, then all this talk of high bit encoding producing billions of colors is moot (and wrong), no?
Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20646
  • Andrew Rodney
    • http://www.digitaldog.net/
Re: Lumejet Process Overview
« Reply #63 on: March 05, 2018, 10:35:46 am »

And the mapping of the 24-bit space to the 32-bit space is one of the critical steps in producing the most accurate possible printer.
Accuracy in terms of color? I think not. Some other kind of accuracy (placement of dots), perhaps. For lurkers:

Delta-E and color accuracy

In this 7 minute video I'll cover: What is Delta-E and how we use it to evaluate color differences. Color Accuracy: what it really means, how we measure it using ColorThink Pro and BableColor CT&A. This is an edited subset of a video covering RGB working spaces from raw data (sRGB urban legend Part 1).

Low Rez: https://www.youtube.com/watch?v=Jy0BD5aRV9s&feature=youtu.be
High Rez: http://digitaldog.net/files/Delta-E%20and%20Color%20Accuracy%20Video.mp4
Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".

hrwilliams

  • Newbie
  • *
  • Offline Offline
  • Posts: 21
Re: Lumejet Process Overview
« Reply #64 on: March 05, 2018, 04:58:42 pm »

Most, the same colors.  :D That be true if the image had 4 billion pixels all R0/B0/G0 or any one triplet. So what? If you can't see it, it's not a color. Color is a perceptual property.

Forgive me, but I think we are talking about cross purposes on the question of whether you can see a colour. Every single colour that can be generated by our printer is, by definition, visible. It may be that 500 near-adjacent RGB combinations all generate pixels that you (or I) cannot tell apart, but they are still all valid visbible colours - just not separable by your or my eyes (I’m not sure it’s been proven that someone else couldn’t be more sensitive in one part of the gamut and less sensitive in another). Obviously there are vast tracts of the LAB colour space that are completely invisible/ theoretical, but so long as we are using 8-bit inputs on 3 channels and printing those on paper, I think we can agree that every possible combination of those RGB values will be visible on the page.

I completely concede the point about 4 billion colours being marketing speak - it is indeed 4 billion input combinations into our LEDs (11 bits into two of the channels and 10 into the other). I will revisit how we present this. I hope you will forgive me, though, on the grounds that every other manufacturer makes at least the equivalent claim (I believe I read a figure into the trillions in the past couple of days from one of them).
Logged

hrwilliams

  • Newbie
  • *
  • Offline Offline
  • Posts: 21
Re: Lumejet Process Overview
« Reply #65 on: March 05, 2018, 05:03:00 pm »

Further I challenge anyone here to output a document of any kind, after all edits in both 8-bit per color and high bit (what some may call 16-bit encoding even when it usually isn't) to any printer and illustrate the higher bit depth was visible superior. Seems that may not be possible with your device as it sounds like your front end (what you're calling a RIP) fed the LED's 8-bit per color data. If that understanding is correct, then all this talk of high bit encoding producing billions of colors is moot (and wrong), no?
Again, I concede the moot point. Marketing speak re 4 billion colours is just that. 4 billion possible LED input values are fed / mapped to 16 million output values from the RIP. In other words, we take 8 bit data from Photoshop et al, and map those 8 bits to a small portion of the 4 billion input values to the LEDs to try to make the LEDs generate the most accurate possible colours. We do not believe that 16-bit/ channel inputs add anything to the accuracy of printing and agree that no one could tell the difference. On the other hand, having the full 32bits to play with in the LED inputs definitely gives us extra flexibility and accuracy in the calibration of the machine.
Logged

hrwilliams

  • Newbie
  • *
  • Offline Offline
  • Posts: 21
Re: Lumejet Process Overview
« Reply #66 on: March 05, 2018, 05:08:26 pm »

Accuracy in terms of color? I think not. Some other kind of accuracy (placement of dots), perhaps. For lurkers:

Delta-E and color accuracy

In this 7 minute video I'll cover: What is Delta-E and how we use it to evaluate color differences. Color Accuracy: what it really means, how we measure it using ColorThink Pro and BableColor CT&A. This is an edited subset of a video covering RGB working spaces from raw data (sRGB urban legend Part 1).

Low Rez: https://www.youtube.com/watch?v=Jy0BD5aRV9s&feature=youtu.be
High Rez: http://digitaldog.net/files/Delta-E%20and%20Color%20Accuracy%20Video.mp4

I’m sorry but this is one point on which I must disagree with you. This is nothing to do with placement of dots, and everything to do with colour accuracy. The thing is this - the most difficult thing for any RGB printer (ie one with no K channel) to achieve is gray line neutrality. At every point along the gray line, a balance between the three input channels must be achieved to achieve colour neturality. The thing is the paper behaves entirely non-linearly in terms of the relationship between input energy and colour on the page for each channel along the curve. So at some points, a 1% increase in input energy into the relevant LED produces a 1% increase in intensity of the image. At other points, the 1% increase in energy input might produce a much greater (or lesser) increase in intensity of the printed image. If we only had 8 bits of input into each LED channel then we would find it much harder to achieve grey balance at different points on the density curve. Having 2 or 3 more bits on each channel effectively gives us more sensitivity where we most need it to achieve the balance as well as we can. We take a number of points all along that gray line to calibrate the machine, but they are not evenly spaced - in some areas they are very close together; in other areas much farther apart. The 32 bits of input data to the LEDs are therefore crucial.
Logged

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20646
  • Andrew Rodney
    • http://www.digitaldog.net/
Re: Lumejet Process Overview
« Reply #67 on: March 05, 2018, 05:14:06 pm »

Forgive me, but I think we are talking about cross purposes on the question of whether you can see a colour. Every single colour that can be generated by our printer is, by definition, visible.
Then it can't possibly print more than 12 million colors by your own agreement as to what we can see!
Let's examine your own text, two examples below:

Quote
I mean to type 12 million, so apologies. Let's agree on 12 million discernible colours by a good human eye as a starting point.
We agree and now the important bits <g>:
Quote
Then imagine that the next discernible colour (varying one channel only) is 4,1,1.
It then is the next discernible color, period.
Quote
You and I might both agree that 2,1,1 and 3,1,1 are not discernible from 1,1,1 but they are still colours, (AR:the same colors, not disernabile as two different colors) and if I replace my two points of 1,1,1 and 4,1,1 with different points of 2,1,1 and 5,1,1 I will produce two perfectly visible (and probably discernible) dots.
Visible as the same color dots. They are the same color if they are not visibly discernible. 1/1/1 is either discernible from 2/1/1 or it isn't. Dividing this into 2.23/1.16/1.19 (finer encoding) doesn't make that now more or less discernible; it either is or it isn't discernible; perceptually by the human observer. 
Quote
So one reason for having as many data points as possible is to achieve smooth gradations as you move along a tonal curve, and eliminate any stepping.
IF it can be seen, it can be seen! Two non discernible numbers are one color and no, it's not smoother IF they are not discernible from each other. Below are two differing sRGB device values. 1/255/240 and 2/255/240. They are the same color because they appear identical (as the deltaE values show the differences are invisible by a huge margin). Doesn't matter if this sRGB document with two values is encoded in 8-bits per color, 16-bits per color or a finer encoding (1.01/255.0.0/240.1.2 vs 2.01/255.00/240.1.2); the two numbers ARE the same color. Print them anyway you wish, they will appear as the same color no matter the encoding precision. Place each next to each other on a print, within a gradient; they appear as the same color. Two sets of device values are either visibly different (on your device or any other) or they are not. With the sRGB values below, no device on this planet will produce two differing visible colors without a bug; the two values are a dE of 0.01! NO encoding will change that!

Analogy: I have a 3lb apple pie baked into a nine inch dish. I can divided that pie into 8 pieces or 16 pieces or a billion pieces. It's still a 3lb nine inch pie. No matter how I divide it up, this doesn't alter it's size and weight. Same with color numbers. More numbers divided up doesn't produce more colors. Two values, two hundred values can all be the same color perceptually. You make a print with those numbers and they all appear the same to the observer.

« Last Edit: March 05, 2018, 05:21:27 pm by digitaldog »
Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".

hrwilliams

  • Newbie
  • *
  • Offline Offline
  • Posts: 21
Re: Lumejet Process Overview
« Reply #68 on: March 05, 2018, 05:17:36 pm »

Huw, I'm puzzled by the motivation for your research into refining the digital c-type process. You say that you were driven by a desire to render text better on a c-type, but who wants to print text on a c-type? There are countless other printing options for nice crisp text. I can see that a photographer might occasionally want to put an image caption on the border of a print – but fifteen years research to optimise that? Just curious :)

The honest answer is that what looked like a brilliant idea almost 20 years ago might look a little different now (and I have only been involved for two of them!). There was a time when digital images (or scans) were still being projected onto negatives which were then developed as normal (our founder had one such business) and when inkjet first came in it was a tremendously expensive process in many ways, when silver halide was a well-known and relatively cheap medium. But silver halide produced soft text for the simple reason that it was mostly imaged inexactly (e.g. often through an enlarger lens) - so people running silver halide based businesses could see the threat from inkjet, etc, but couldn’t work out how to address the really obvious disadvantage - the need to print sharp text and graphics like inkjet could. Over the years, obviously, inkjet has made amazing advances, particularly in photo printing. Silver halide printing has not advanced nearly as much and most machine manufacturers have given up for good - or concentrate entirely on high-volume/ moderate accuracy machines. We still think there is a place for really accurately imaged silver halide and we believe that the technology developed over the past 15+ years probably takes things almost as far as it is possible to do (though we do have a wide format high-speed print concept in the very early stages of development). The thing is that silver halide is still a really beautiful medium and it has a feel all of its own. Some people love it; others prefer inkjet - I think there’s a place for both in the world, even for the most demanding photographers. Incidentally, I saw the most stunning inkjet print today of really complex architects drawings. I am trying to find what the printer was. I would say that they beat us on the overall quality of line, but our text (even so small that it was completely unreadable without a loupe) was much better - more even, less blotchy, and in the really small details (e.g where multiple lines intersect) our technology resolved the lines at least as well and in some cases better. I will try to post scans over the next few days so you can see what I mean, if that’s of interest.
Logged

Kevin Raber

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1339
  • Kevin Raber
    • Kevin Raber
Re: Lumejet Process Overview
« Reply #69 on: March 05, 2018, 05:23:16 pm »

Andrew, you should send a few images in.  I sent a ton in and was really surprised.  I'll have a video and article on it as soon as I can get it written.  They make it easy to order so give it a try and then you can share your findings.
Logged
Kevin Raber
kwr@rabereyes.com
kevin@photopxl.com
rockhopperworkshops.com
photopxl.com

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20646
  • Andrew Rodney
    • http://www.digitaldog.net/
Re: Lumejet Process Overview
« Reply #70 on: March 05, 2018, 05:30:50 pm »

I’m sorry but this is one point on which I must disagree with you. This is nothing to do with placement of dots, and everything to do with colour accuracy.
I didn't know if it had anything to do with placement of dot or not because you didn't say color accuracy, only accuracy.
Now that we are on the same page as speaking of actual color accuracy, and considering you've told us the RIP sends 8-bits per color data to the printer, how can a higher encoding have anything to do with color accuracy?
Quote
The thing is this - the most difficult thing for any RGB printer (ie one with no K channel) to achieve is gray line neutrality.
And higher bit depth does nothing to address that.
Quote
If we only had 8 bits of input into each LED channel then we would find it much harder to achieve grey balance at different points on the density curve.
Now why would that be so? Further, you've stated this to us:
Quote
each of the LEDs is fed with 8-bit colour information from the RIP and that produces 16.8 million visible output combinations
So in one breath, you're telling us for better color accuracy you need more bits (makes zero sense to me) and then you tell us the LED is feed 8-bit per color. I send you a 8-bit per color JPEG or TIFF, it is what it is; you're not getting more bits right? AND you're telling us when the rubber meets the road, the LED only gets 8-bits per color anyway.
But you may be able to explain how high bit data and 8-bit per data in any way produces more accurate color. What's the dE difference IF your device dealt with 8-bits vs. more than 8-bits and why would it make any difference?
Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20646
  • Andrew Rodney
    • http://www.digitaldog.net/
Re: Lumejet Process Overview
« Reply #71 on: March 05, 2018, 05:33:43 pm »

Andrew, you should send a few images in.  I sent a ton in and was really surprised.
Moot. I'm surprised by a lack of technical understanding conveyed here about this print process.
Your suggestion is akin to someone saying "We only accept sRGB for our printers and the prints look really good". They may indeed look good, but that tells me nothing about what I may get from the printer if I sent a larger color gamut to the printer and COMPARED it to the sRGB version.
So, does the higher bit depth produce more accurate color as we're told and IF so how?
Does the printer produce billions of colors when some here are under the agreement we can only see 12 million?
Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".

amolitor

  • Contributor
  • Sr. Member
  • *
  • Offline Offline
  • Posts: 607
Re: Lumejet Process Overview
« Reply #72 on: March 05, 2018, 05:42:24 pm »

My guess is that they've got 11 bits on 2 of the LEDs and 10 on the other, and the device values they present to the device produce specific electrical values at the LED and that's that. We could imagine that maybe it's linear or whatever. Point is, there's some sort of mapping from 32 bit device values to the characteristics of the dot on paper, and I bet that mapping is fixed. I assume that 0,0,0 is a damn good imitation of the paper's DMax, and actually I bet there's a whole lot of device value space that smushes down to the paper Dmax. Ditto 2048,2048,1024 being paper white.

Since they're got an enormous amount of room in that device's space, even if it is a fixed mapping and maybe not even a very nice mapping, they can still fit whatever mapping you like onto it.

So, among other things, they can manage a perfectly neutral middle grey.

Who knows, maybe they can custom map each of the 576 LEDs to compensate for variability in the LEDs themselves. With that much room to play with, why not?
Logged

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20646
  • Andrew Rodney
    • http://www.digitaldog.net/
Re: Lumejet Process Overview
« Reply #73 on: March 05, 2018, 06:30:59 pm »

My guess is that they've got 11 bits on 2 of the LEDs and 10 on the other, and the device values they present to the device produce specific electrical values at the LED and that's that.
Bits from what/where? I send them a document to print that's 24-bit color. Now what; interpolating more bits? I do the same in Photoshop (convert 24-bit data to 48-bits); what did I gain?
Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".

amolitor

  • Contributor
  • Sr. Member
  • *
  • Offline Offline
  • Posts: 607
Re: Lumejet Process Overview
« Reply #74 on: March 05, 2018, 07:01:41 pm »

From anywhere!

I am speculating, of course. But I assume the machine takes 32 bits of stuff and turns it into a little teeny dot, in a pretty fixed way. Further back up the pipeline,
though, they have some choices as to which 32 bits they want to send.

My knowledge of the exact terminology of color science and printing is very very close to zero, but as a former mathematician, engineer, and all around not-quite-idiot, I can imagine that you have, I dunno, a 24 bit value in your picture file which, along with your color space indications and... some other metadata?... means some color. That 24 bit value gets mapped around in the print pipeline to produce some sort  of value or set of values that corresponds to physical blotches of ink, or in this case, a 32 bit "MAKE UM LEDS SO BRIGHT OK THX" value.

By having a huge numerical space with massive amounts of redundancy in the machine, at that last stage, they give themselves room to work, and (presumably)  rarely find themselves in a situation where the input specifies a certain color, the paper can actually RENDER that color, but precision has been lost and bits thrown away and, bugger it, it's still not going to happen.

So, anyways. I get the value in having loads of "digital space" at the print head. If it costs nothing to build it in, it's going to keep options open down the road.
Logged

Mark D Segal

  • Contributor
  • Sr. Member
  • *
  • Offline Offline
  • Posts: 12512
    • http://www.markdsegal.com
Re: Lumejet Process Overview
« Reply #75 on: March 05, 2018, 08:04:18 pm »

.................and in the really small details (e.g where multiple lines intersect) our technology resolved the lines at least as well and in some cases better. I will try to post scans over the next few days so you can see what I mean, if that’s of interest.

Yes Huw, it is of interest, and thanks ever so much for hanging in with this discussion. I think we are all learning from it.
Logged
Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....."

Mark D Segal

  • Contributor
  • Sr. Member
  • *
  • Offline Offline
  • Posts: 12512
    • http://www.markdsegal.com
Re: Lumejet Process Overview
« Reply #76 on: March 05, 2018, 08:10:27 pm »

Andrew, you should send a few images in.  I sent a ton in and was really surprised.  I'll have a video and article on it as soon as I can get it written.  They make it easy to order so give it a try and then you can share your findings.

Really good idea. As my article shows, this is a case where the numbers and the math can take you only so far - you need to examine real photographic results side by side to get a feel for what's going on. I would recommend particularly to Andrew - sending them several photos that have nicely graduated skies. Print them as you would conventionally in your Epson 3880 or whatever printer you are now using. Then reprep the files softproofing with their profiles to emulate your Epson softproof as closely as the gamut difference allows, get them to 400 PPI and send them in. It could also be of interest to send them a couple of B&Ws with nice tonal gradations. Remember there is a size limitation of about 12" width.
Logged
Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....."

amolitor

  • Contributor
  • Sr. Member
  • *
  • Offline Offline
  • Posts: 607
Re: Lumejet Process Overview
« Reply #77 on: March 05, 2018, 08:19:52 pm »

Huw, while we have you here, can you talk a little about the books?

It looks to me like you're printing panoramic prints on Fuji paper, and then folding and gluing them with Imaging Solutions equipment, correct?

This, essentially, take a wide C print and folds it in half, with printed surface facing printed surface. In my experience, photographic prints are
not terribly happy face-to-face, especially if even a small amount of dampness is involved. I actually hand built some layflat books using actual prints,
and the pages stuck together like the dickens. I tipped in tissue to cope with the problem (I was using two prints, one verso and one recto
so this was feasible).

Do you use a coating or something to allay these problems? Or are the specific papers you've specced for the process particularly well suited to this
face-to-face application?
Logged

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20646
  • Andrew Rodney
    • http://www.digitaldog.net/
Re: Lumejet Process Overview
« Reply #78 on: March 05, 2018, 08:38:09 pm »

Really good idea.
How so? How would it answer a single question I have asked about color numbers and color output of this device?
I have both a P800 and a 3880. AFAIK, and please correct me if I'm wrong, both printers produce a wider color gamut than Lumejet. Both provide far more options for papers. Both provide a print that's far more archival. Both can produce a much larger print. What would I gain by having output from the process? How would it answer my question about higher bit depth producing more color accuracy? Would having them produce prints clear up what in my mind is text which seems at odds:

Quote
hrwilliams wrote:

"...each of the LEDs is fed with 8-bit colour information from the RIP and that produces 16.8 million visible output combinations"


"I mean to type 12 million, so apologies. Let's agree on 12 million discernible colours by a good human eye as a starting point".
Which is it (which value is visibly discernible)?

Somewhere, 4.8 MILLION colors (I have stated, device values, NOT colors) have been gone a-missing if we agree to agree on that 2nd sentence just above.
We can skip some nitpickng that this isn't a function of the eye per se!
Peer review is a bitch. But it's necessary on a site which asks us to pay for content. Even if the payment is tiny and well worthwhile mostly. Let's not forget the very first post here which I happen to be finding to be accurate thus far:
http://forum.luminous-landscape.com/index.php?topic=123382.msg1028733#msg1028733
But I am open minded and want to separate the facts from the marketing hype of which the later is a possibility thus far.....
 


 
Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".

Mark D Segal

  • Contributor
  • Sr. Member
  • *
  • Offline Offline
  • Posts: 12512
    • http://www.markdsegal.com
Re: Lumejet Process Overview
« Reply #79 on: March 05, 2018, 08:54:36 pm »

Moot. I'm surprised by a lack of technical understanding conveyed here about this print process.
Your suggestion is akin to someone saying "We only accept sRGB for our printers and the prints look really good". They may indeed look good, but that tells me nothing about what I may get from the printer if I sent a larger color gamut to the printer and COMPARED it to the sRGB version.
So, does the higher bit depth produce more accurate color as we're told and IF so how?
Does the printer produce billions of colors when some here are under the agreement we can only see 12 million?

Andrew,

Huw was clear about the gamut constraints of their process - as was I in the review - that compared say to the Epson SC-P5000 I'm using, they are indeed gamut limited. I published a number of gamut comparisons for output options, but not working spaces. Attached is one I had prepared comparing Adobe RGB(1998) with Lumejet Luster paper. Clearly, for photos with colours that would fill or even exceed ARGB(98), there's going to be a lot of gamut compression printing those photos through the Lumejet process. So one is in the hands of Rendering Intents and good profiles to see how all that works. This is where having a range of comparison prints made really helps appreciate relative image acceptability/quality. 

Colour spaces are a continuum. In a manner of speaking they get populated with encoded colour values to go to the printer. No matter what the bit depth, any values that exceed the printer/paper gamut are going to be compressed. Higher bit depth means slicing and dicing the colours into smaller differences between them (your three pound apple pie with more slices). At what point do you stop seeing differences and therefore at what point does this matter to the quality of tonal gradations? Again, need to see results.
« Last Edit: March 05, 2018, 09:05:13 pm by Mark D Segal »
Logged
Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....."
Pages: 1 2 3 [4] 5   Go Up