Pages: 1 ... 3 4 [5]   Go Down

Author Topic: Lumejet Process Overview  (Read 7680 times)

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 14236
    • http://www.digitaldog.net/
Re: Lumejet Process Overview
« Reply #80 on: March 05, 2018, 09:03:05 PM »

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, ifor 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. 
What isn't yet clear to me is why I'd send images to him and how it would answer my questions.
Quote
Colour spaces are a continuum.

Meaning what?
Quote
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.
I agree and have stated this already. How would that address the discrepancy in his text about describable colors?  Is my post (last one #79) answered by sending files to him for output?



Logged
Andrew Rodney
Author ďColor Management for Photographers"

Mark D Segal

  • Contributor
  • Sr. Member
  • *
  • Offline Offline
  • Posts: 11622
    • http://www.markdsegal.com
Re: Lumejet Process Overview
« Reply #81 on: March 05, 2018, 09:23:00 PM »

Huw and you, in post 67 have already agreed on a number of 12 million for discernible colours. So that one is for now settled. The remaining question about how many colours are needed for smooth tonal gradations in whatever gamut size is still on the table. I wonder if there is a mathematical answer to it, or is it primarily empirical and image-dependent.

What you get having some prints made is giving a tangible perspective to all the math issues.

I think Huw was clear that this process is for people who don't want to spend their time making their own prints with inkjet printers on their desks, but prefer to outsource to a high quality service provider. I think it's pretty obvious that people who need prints larger than what they provide, and/or assured greater longevity than they can provide, and/or uncompressed colours beyond their gamut potential would send their printing elsewhere, but those for whom those constraints don't matter would be very pleased with the quality of the output. I don't think any one is pretending that this is be-all and end-all of printing processes. It is a high quality option for a certain clientele - it's a wide world full of people with different requirements. 
Logged
Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....."

amolitor

  • Contributor
  • Sr. Member
  • *
  • Offline Offline
  • Posts: 293
Re: Lumejet Process Overview
« Reply #82 on: March 05, 2018, 09:26:40 PM »

Honestly, if they can build a genuine book block with real C prints that don't stick together, that would be something worth knowing about.

It's a big world and there are many things in it, but books and photographic prints are not, as far as I know, two great tastes that have been
put together particularly well in the past.
Logged

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 14236
    • http://www.digitaldog.net/
Re: Lumejet Process Overview
« Reply #83 on: March 05, 2018, 09:41:24 PM »


Huw and you, in post 67 have already agreed on a number of 12 million for discernible colours. So that one is for now settled. The remaining question about how many colours are needed for smooth tonal gradations in whatever gamut size is still on the table. I wonder if there is a mathematical answer to it, or is it primarily empirical and image-dependent.
Consider this set of images; I believe indeed it's image dependent and Huw has mentioned smooth gradients:
Huw was indeed clear that this process isn't for someone like me with two Epson printers which makes me wonder why the suggestion in post #70 and then #77 was recommend I do so.
Logged
Andrew Rodney
Author ďColor Management for Photographers"

Stephen Ray

  • Full Member
  • ***
  • Offline Offline
  • Posts: 139
Re: Lumejet Process Overview
« Reply #84 on: March 05, 2018, 10:55:38 PM »

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? And higher bit depth does nothing to address that. Now why would that be so? Further, you've stated this to us: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?


This is cut and pasted from my old Kodak LVT manual...

<<Each pixel in an image is represented by three 8-bit bytes or 24-bits of information. Each 8-bit byte represents a color in each pixel. When an image is printed, the 8-bit code is used to ďlook upĒ a corresponding 12-bit code stored in a calibrated look-up-table. There are 4,096 12-bit codes available, but only 256 are used at a time for each color input. The 12-bit code is then fed into a Digital-to-Analog Converter which converts the 12-bit information to a corresponding voltage. This voltage controls the modulators that regulate the exposure of the photographic material on the drum.>>

<<For calibration purposes, the exposure time is fixed and density is a function of the light available to the photographic material (represented by the 8-bit code). The aim values that are used are based on the concept of ďequal lightnessĒ for Ektachrome and color paper material. This concept allows for a uniform sampling of the 3D color space of the photographic material. For all other materials, the aims are set up to produce a facsimile of the Ektachrome output of the same file.>>

Maybe this helps the conversation.
Logged

hrwilliams

  • Newbie
  • *
  • Offline Offline
  • Posts: 21
Re: Lumejet Process Overview
« Reply #85 on: March 06, 2018, 03:42:26 AM »

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!



Iím sorry - owing to time differences I have been absent when all the interesting stuff was going on.

I made a comment earlier in this thread agreeing to agree on 12 million discernible colours. Please donít hold me to that in the sense that none of us knows whether the figure is 12 or 15 or 16 million and my guess is that it varies between individuals. A master of wine, for instance, can discern many more scents than I can. Can we agree that it is in the low double-digits but not fight over whether itís 12 or 16 million for a few minutes? I absolutely agree that the concept of 4 billion colours is moot - thatís over 2 orders of magnitude greater than the range of discernible colours that a human can see.

However in the interests of allowing me to learn from this, please let me post a question (genuinely) to try to clarify my understanding.

Imagine I paint a gradient by varying only one channel all the way from 0 - 256, while not varying the other two input channels. Without having done the maths, presumably any two adjacent points will have Lab differences that are so small that it is very hard to tell the difference between them. Or at least it must be possible to paint gradients that have this property at some points on the gradient. So if we imagine a section of that gradient where there are say n points. Point 1 has a given value. Point 2 has one channel changed by 1 value and the other two remain the same, and so on up to point n which is the first point that is discernibly different to the eye from point 1. Then my question (and this is a genuine one) is Ďwhat colour is point n-1í? It is much closer to point n than it is to point 1. So Lab should tell me that it is indistinguishable from point n, which is completely adjacent to it. And yet it is also apparently indistinguishable from point 1, which itself IS distinguishable from point n. How does that work? To me the fact that I canít tell the difference between two adjacent points doesnít mean they arenít different colours - it just means that they arenít distinguishable by my eyes. Is it not possible that actually someone else might see the differences between points slightly differently? To take a slightly facetious analogy: try alternating sips of whiskey and water. Pretty soon you canít tell the difference. You can see it; you know itís there; but you canít taste it because your brain desensitises. Does the same thing happen with colour?

At this point Iím sure itís obvious Iím not a colour scientist - for which I apologise. Iím a mechanical/ manufacturing engineer, so I have some ability to understand technical arguments, but my career was in finance. Iím trying hard to catch up!
Logged

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 14236
    • http://www.digitaldog.net/
Re: Lumejet Process Overview
« Reply #86 on: March 06, 2018, 11:05:05 AM »


Lets start at square one so I can put this all into perspective in one post (much of this is redundant but it seems necessary).
Ground rule #1
Color, is a perceptual property. So if you can't see it it's not a color. Color is not a particular wavelength of light. It is a cognitive perception, the excitation of photoreceptors followed by retinal processing and ending in the our visual cortex, within our brains. As such, colors are defined based on perceptual experiments. I've placed text from experts to back this up:


Fairchild's "Color Appearance Models". Page 1!
Like beauty, color is in the eye of the beholder. For as long as human scientific inquiry has been recorded, the nature of color perception has been a topic of great interest. Despite tremendous evolution of technology,fundamental issues of color perception remain unanswered. Many scientific attempts to explain color rely purely on the physical nature of light and objects. However, without the human observer, there is no color.
Further on the same page:
It is common to say that certain wavelengths of light, or certain objects are a give color. This is an attempt to relegate color to the purely physical domain. It is more correct to state those stimuli are perceived to be a certain color when viewed under specific conditions.
Page 1 paragraph 2 of Digital Color Management by Giorgianni and Madden:
But color itself is a perception and perceptions only exist in the mind.
Page 11 of The GATF Practical guide to Color Management:
Although extensive research has been conducted, we still not completely understand what happens in the brain when we "see" color. The visual sensation known as color occurs when light excites photoreceptors in the eye called cone cells.
Page 75 of Understanding Color Management by Sharma:
Color is an impression that we form in our brains.


You write: "To me the fact that I canít tell the difference between two adjacent points doesnít mean they arenít different colours - it just means that they arenít distinguishable by my eyes".


No it measns they are the same color! Repeat: IF they are not distinguishable by your eyes, they ARE the same color. Unless you do not wish to believe what color is, based on the color scientsts above, based on the colorimetry your company uses (deltaE) and which Mark provided in his article. I believe those color scientists. And when I view the two sRGB values on-screen, on a very good reference display, they appear the same color. Because again, do not confuse a color number with a color you cannot see or in this case, two numbers that appear to be the same color and who's dE PROVE it.


Ground rule #2. Color numbers, device values are not necessarily and often not colors! I provided one such example with R0/G255/B0 in ProPhoto RGB. It isn't a color, we can't see it, it falls outside human vision. We can give numbers to wavelengths in the infrared spectrum and we still can't see them; they are in visible to us. They are not colors. In my PDF (URL posted already), the last and critical sentence I wrote was this: Donít confuse a color number, a device value, as a color you can see!


As to the number of colors we can see (not numbers based on encoding of digital values), we seem to agree that 12 million is a good one. It could be a bit more or less but for this discussion 12 millon on the nose is fine. What it isn't is 16.7million let alone billons of colors! Billions of numbers perhaps but not billions of colors. That's marketing speak from many companies that wish to convince their customers that more is better. You even stated this was a goal and a difficult one but really, it's not at all important in terms of color (what we can see). It's just dividing up that pie into finer slices. The 16.7 million number we hear so often is just math based on computer encoding of numbers (3 to the 8th) so why it has no direct relationship to colors (again, what we humans can see) should be obvious now. Just as the number of miles between Santa Fe and New York has no relationship to how many miles per gallon my car would get driving there!


Huw writes: "Imagine I paint a gradient by varying only one channel all the way from 0 - 256, while not varying the other two input channels. Without having done the maths, presumably any two adjacent points will have Lab differences that are so small that it is very hard to tell the difference between them".


The adjacent points can and DO vary over color space! I provided an example of two triplets in sRGB where the only difference was one value in one channel and the color difference (distance) was a tiny dE 2000 of 0.01; an invisible difference. But I can take other values in sRGB that vary by only 1 value in one channel and the dE is larger. More than 1? That would require a lot of comparisons of triplets in the software I've used to show you the two sRGB values already. If you consider the 12 million visible colors versus the 16.7 million numbers, there's 4.7 million numbers missing here which should tell you a lot about numbers that are not colors.


So this varies. But what is important are these facts:
1. Your device, no device, produces 16.7 million colors. Your device and many devices can produce 16.7 million of the same colors.Your output device, everyone's output device will produce ONE color from TWO of the sRGB triplets I provided. No matter the encoding. Because they ARE the same color.
2. Those who state their devices produce that billions of colors let alone 16.7 million colors are simply using marketing speak in an attempt to make others believe more is better.
3. When the differences in two numbers is less than a dE of one, they are the same color. Doesn't matter how you divide up those two sets of triplets. Finer encoding doesn't change the dE values when the two are perceptually the same color.


Yes, you and I may see colors differently and the 12 million value can differ but ALL this colorimetry is based on the Standard Observer (a theoretical model of human vision). And even accounting for our differences in color perception, it's moot and we simply should not associate the number of colors we (or the standard observer) can see with the encoding of computer numbers! Just like distance in miles and miles per gallon if I can use that quick analogy.


Now 98% of your customers and 99% of other companies customers may believe that these devices can produce 16.7 million or billions of colors. That's simply untrue and wrong! And I don't expect marketing folks to correct this. They didn't when providing spec's for camera resolution by including pixels that were not used to create an image. Or when they provided Dynamic Range of scanners without telling us when they start measuring past a level that's noise. What I expect and hope for, are educated readers who can see through the marketing hype because they actually understand (in this case) the color science behind the claims. I'm not a color scientist, I'm a photographer by training and degree. But nothing I've written requires any formal training in color science. It does help to know some actual color scientists and learn from them and provide them with articles (like my PDF on color numbers) for peer review. So, the above and below from me is in direct reply to post #37 where this question came up:


"4 billion unique colors possible for each printed pixel-Is this even meaningful"?
No, and it isn't possible. Now the reasons why have been outlined.


Now if you wish, we can go into this idea around color accuracy. Let me suggest before hand, we need reference and measured values and we need more than just grays although I totally agree gray's for this task are absolutely necessary to view.
« Last Edit: March 06, 2018, 01:03:56 PM by digitaldog »
Logged
Andrew Rodney
Author ďColor Management for Photographers"

hrwilliams

  • Newbie
  • *
  • Offline Offline
  • Posts: 21
Re: Lumejet Process Overview
« Reply #87 on: March 06, 2018, 02:30:55 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?

I think this is a pretty good summary of what I was trying to convey.
 
To take the blocks/ process steps:
 
We take 8-bit (24-bit) colour data, along with the dataís colour space (.icc) and pass it into our RIP (ColorGATE).The RIP resamples the data within the file and converts the input 24-bit colour with its colour profile into the CIELAB profile connection space (PCS). The output deviceís profile (the media specific.icc for our printer) is then used along with the selected rendering intent is used to convert from the PCS to the device specific RGB values in 24-bit colour. The result is a 24-bit colour (.bmp) at 400dpi.

The embedded printer driver convert from (.bmp)  to print-specific data for driving the LEDs. The 24-bit pixel colour is channelised into its 8-bit composite data. On a per channel basis (R,G,B), the media specific calibration data is applied. In simplistic terms, this calibration data is a lookup table that has 0-255 on its input, that selects a 10/11 bit calibrated output value per input value. E.g. Input R=250 could lookup an output value of 967(10bit) or 1897(11bit). These 10/11 bits per channel are then re-combined to form  the 32-bit  time pulse exposure value for that pixel.
 
Why do we need all these bits? Well, the answer is that you, as a photographer, want a linear CIELAB response in your print. If 0,0,0 is paper white, and 256, 256, 256 is DMax, then 128,128,128 should be half-way there, and 64,64,64 should be 25% density and so on.
 
As I said in an earlier post, one of the problems that we have to contend with is that AgX photo paper is non-linear. Sometimes, a 1% increase in energy from the LED will generate a 1% increase in density of the colour on the paper. At other times, the ratio is completely different. It varies all along the curve, with some areas being particularly sensitive and others particularly insensitive.  This variation is also subtly different between the three channels.
 
Finally, achieving a neutral gray at different points involves mixing different ratios of C, M and Y dyes on the paper. As I said, as a user, you want a linear increase in the RGB values in your image file to produce a linear response (As measured in CIELAB with a D50 illuminant) on the paper - ie if input values imply a doubling of density, thatís what you want to see on the paper. So we need to map linear data from the image file to non-linear inputs to the LEDs in order to achieve the correct linear response on the paper (as far as possible).
 
Having the extra bits in the LED control levels allows us to achieve more precise control of the LEDs to achieve the best possible grey. This is not about using the extra bits to achieve a different colour; itís about using that extra sensitivity to fine tune the relationship between the 3 channels at each point in the curve to achieve the most neutral possible gray. Understanding how each different paper reacts all along the gray line is what enables us to build our target files for each paper which is (as I said in one of my first posts) something that not even Fuji appears to have done. Our target files are designed to deliver a linear neutral grey when measured in CIELAB with a D50 illuminant.
 
Once we have the correct mapping to produce a neutral grey line that generates linear outputs from linear RGB 8-bit inputs we can extrapolate that to the rest of the colour space. So you have a look-up table that takes 8-bit input values and generates outputs in 10-bit or 11-bit for the LEDs for the whole of the paper gamut. Again, the key is to turn linear 8-bit inputs into linear 8-bit outputs on the printed page, but to do this you have to have non-linear mapping to 10/11-bits for the LEDs and the relationship between the three channels will not always be what you expect.
 
There are a number of factors that complicate this still further:
 
First, as many will know, where is even a point on the paper where if you pump too much energy in, it will actually become lighter (Ďsolarisationí). The response of the paper at this point is unpredictable. Fuji Professional paperís limit point is, I think, a DMax of 2.5. Above this, you start to get solarisation. So understanding the DMax for the paper is fundamental to the calibration.

Solarisation info for anyone interested:
https://books.google.co.uk/books?id=WEkzDwAAQBAJ&pg=PA126&lpg=PA126&dq=solarisation+silver+halide&source=bl&ots=qvKPEdlg6-&sig=X3i9EifRJOOi6RvC8aF4Tw1Xzmg&hl=en&sa=X&ved=0ahUKEwjBisro09fZAhWHOsAKHZTeBWEQ6AEIUDAH#v=onepage&q=solarisation%20silver%20halide&f=false


Next, there is the question of cross-talk. In order to activate yellow dyes in the paper, you pump in blue light. However the magenta dye is also very slightly sensitive to this blue light and a tiny amount is also activated. At first, this is unnoticeable, but as you approach DMax in the blue/ yellow channel, the rate of yellow density increase begins to roll off. At the same time, the magenta dye has been activated and starts to become much more sensitive in its response to the blue light and more of this magenta leaks out. This is a known Ďfeatureí of Fuji papers and results in a slightly orangey tone to very deep yellows. We have spent a good deal of time trying to minimise this.

Then there is the matter of the LEDs themselves. They are all slightly different and they all have slightly different power outputs. We need to account for that - for a given time pulse, each LED will give out different energy. They each also vary slightly in output wavelength and we have to deal with that, too. So we do control every LED individually and this is a crucial part of the calibration process.
 
So to summarise, the fact that we have 32 bits to play with in terms of LED input values is not aimed at producing more than 2^24 output combinations (ie 8-bit). It is all about mapping 2^24 input RGB values to 2^32 LED input values to allow those LEDs to generate 2^24 output values so that what you see on the paper is what you expect to see from the screen. We are using the fact that we have finer grain control in two areas: (i) in the gray balance; and (ii) in the LED balance to ensure that each LED is balanced relative to its peers. We need the extra bits to do this accurately.
 
Logged

hrwilliams

  • Newbie
  • *
  • Offline Offline
  • Posts: 21
Re: Lumejet Process Overview
« Reply #88 on: March 06, 2018, 02:37:56 PM »

Honestly, if they can build a genuine book block with real C prints that don't stick together, that would be something worth knowing about.

It's a big world and there are many things in it, but books and photographic prints are not, as far as I know, two great tastes that have been
put together particularly well in the past.

The answer to that is that we can build you a genuine book block with real C prints that wonít stick together provided you are careful with them. They WILL stick together if they get wet, including a splash. If that happens, you need to dab it off and leave the book to dry, open on that page. It shouldnít be a problem in normal use. Fuji does have some papers with fingerprint-resistant coatings (the HDX Premium range) which we use. These are also less prone to sticking, I believe, but the coating does definitely reduce colour vibrancy and gamut so better to use where print quality is not at an absolute premium.
Logged

photodan19

  • Newbie
  • *
  • Offline Offline
  • Posts: 6
Re: Lumejet Process Overview
« Reply #89 on: March 25, 2018, 06:41:25 PM »

(I donít know if the following should be the start of a new thread or not, so I took the easy path and posted as a continuation). 

I placed a couple of orders for L-Type single prints with Lumejet and received my orders in California via the post office with each one arriving in just about 12 calendar days (pretty darn good considering the international distance).  They were for color prints on Fuji DPII matte and luster papers (they have other papers; and the sample softcover true-photo book looked excellent).   I had some of the prints done via their recommended no-extra-cost mounting on acid-free board and they are really great.

I am very pleased with the quality of the prints and the very reasonable cost. The color balance and contrast of the prints are close to viewing soft-proofing in Lightroom via my calibrated NEC monitor, and the presentation of fine details is superior.  I was also very pleased with the prompt, friendly, and helpful personal responses to my questions.

With my best quality high-res files printed on the matte paper (at 400 PPI) I was astounded at the quality in the following sense.  I can now finally obtain a digitally produced print showing the finest details but yet looking smooth and natural, no matter how closely I look at the print. I have not yet tweaked my sharpening to perhaps get the most out of this particular process, but even so the results are superior to what Iíve been able to obtain elsewhere.

The L-Type prints on matte paper give me a look that is very similar to what I used to get from analog contact and low-enlargement prints on N-surface paper from large format (4x5Ē and 8x10Ē) color negs - seemingly almost infinite detail presented in a beautifully natural / smooth manner.  I can now get prints that are better than ever before, thanks to digital file post-processing techniques combined with the L-Type printing process.

I did not test color gamut, nor did I directly compare to inkjet prints, as I donít have such a printer and when I tried a couple commercial inkjet labs at least a couple of years ago I didnít see a paper (even the smooth ones) that I liked for most of my purposes, and there were other things I didnít like about the prints although some were very nice in many respects. The one exception was when I had large photos of paintings printed on Hahnemuhle William Turner paper - they came out great and the textured paper provided a nice look. 

Time and technology marches on and perhaps there are now papers and inkjet printers available at some commercial labs that would be able to provide my preferred print look. However, even assuming optimistically that is the case my current research indicates that the prints would be much more expensive (by multiples of the L-Type print prices for most sizes).

I donít have prints made that often, but when I do I will be using Lumejet for a significant percentage of them.  Thanks again to Mark Segal and Luminous Landscape for the original article.

Dan


Logged

elliot_n

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 575
Re: Lumejet Process Overview
« Reply #90 on: March 25, 2018, 07:12:31 PM »


The L-Type prints on matte paper give me a look that is very similar to what I used to get from analog contact and low-enlargement prints on N-surface paper from large format (4x5Ē and 8x10Ē) color negs - seemingly almost infinite detail presented in a beautifully natural / smooth manner.


Very interesting. Thanks for the review.

Logged

Mark D Segal

  • Contributor
  • Sr. Member
  • *
  • Offline Offline
  • Posts: 11622
    • http://www.markdsegal.com
Re: Lumejet Process Overview
« Reply #91 on: March 25, 2018, 07:34:32 PM »

........... Thanks again to Mark Segal and Luminous Landscape for the original article.

Dan

You are welcome. I'm pleased you are happy with their work. That's the proof of the pudding.
Logged
Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....."
Pages: 1 ... 3 4 [5]   Go Up