Re: Multi-sampling and "2400x4800 dpi" scanners



Good afternoon LjL,

ljlbox@xxxxxxxxxxxxx wrote:

> Gordon Moat ha scritto:
>
> > ljlbox@xxxxxxxxxxxxx wrote:
> >
> > [snip]
> >
> > > I don't want to get *too* technical.
> >
> > Though you want to hack the driver. ;-)
>
> Programming is my field, optics isn't. Not that I'm terribly good at
> that either (in fact I haven't hacked the driver succesfully so far),
> but off hand I can't think of anything I'm terribly good at.

Perhaps you might want to look at the firmware. The code might be simpler, and you
may be able to affect a change in less attempts.

I had a project working on a future full frame digital camera a few months ago.
The programmer on that sub-contracting me to help with the colours aspects of the
software, and with user interface development. I admit I could never do the
programming end of it, and it is something which simply does not interest me.
Colour models are another realm, and I enjoyed that aspect. Wish I could tell you
more about the project, but I signed a confidentiality agreement.

>
>
> >> [snip]
> >
> > If it is moving the optics, and not the CCD, then it has a three or four row
> > CCD with RGB filtering over it. If it is moving the CCDs, then it could be
> > several. Of course, you could crack it open and find out. ;-)
>
> Well, I dunno, but it looks like it's moving everything through the
> glass.

If you can figure out how to easily get it apart, you might discover a bit more.
However, dust could then become an issue. It would make a nice opportunity to
clean the other side of the glass.

>
> In any case, I'm not really interested in the CCD layout, except for
> its - ehm - staggeredness, in that the 2400dpi are obtained with two
> shifted 1200dpi CCDs.
>
> > > But let's just pretend for a moment that it's 2400 dpi optical, period.
> >
> > You would be lucky for it to be much better than half that, but for sake of
> > discussion . . . . . . .
>
> Well, if you can suggest a simple method for measuring real resolution,
> I would be happy to try and find out. Well, I wouldn't necessarily be
> *happy*, on a second thought.

Ted Harris wrote an article in the May/June 2005 issue of View Camera about
scanners. He used a USAF1951 test target and a T4110 step wedge; might be
something to try out. Really well written and presented article, though it would
have been nice to include larger sample images.

>
> But anyway, yes, let's just pretend for the sake of discussion.
>
> > > What I want to do is scan at 4800 dpi in the *vertical* direction, i.e.
> > > run the motor at "half-stepping". My scanner can do that.
> > >
> > > The problem is twofold:
> > >
> > > 1) (the less important one) My scanner's software insists on
> > > interpolating horizontally in order to fake 4800 dpi on both the x and
> > > y axis, and I don't know how to "revert" this interpolation to get the
> > > original data back (just downsampling with Photoshop appears to lose
> > > something). But as you said, the interpolation algorithm varies between
> > > scanners, so I'll have to find out what mine does, I suppose -- or,
> > > hopefully, just manage to hack the open-source driver I'm using to
> > > support 2400x4800 with no interpolation.
> >
> > Make that a three fold problem . . . how and what do you plan to use to view
> > that image? In PhotoShop, you would view 2400 by 4800 as a rectangle; if all
> > the information was 2400 by 2400 viewing, then you have a square; if you want
> > a square image and have 2:1 ratio of pixels then your square image will be
> > viewed like a stretched rectangle. This is similar to a problem that comes up
> > in video editing for still images; video uses non-square pixels, so the
> > square pixel still images need to be altered to fit a non-square video
> > display.
>
> But keeping the image at a 2:1 ratio is not what I plan to do.
> What I plan to do is to take it back to a 1:1 ratio by downsampling on
> the y axis: this way I get a 2400x2400 dpi picture, which is less noisy
> than the same picture taken directly at 2400x2400 dpi from the scanner.

So you want to capture a stacked rectangle in one dimension, then compress the
long end to display a square. Sounds like some pretty hefty algorithm to avoid
creating artefacts in the final image file. Wouldn't that actually reduce the edge
sharpness and resolution of any diagonals in the source image?

>
>
> My main doubt was, what is the "best" or the "right" algorithm to do
> the downsampling? I usually just use (bi)cubic resampling when I want
> to resize something; but in this case, I've got some specific
> information about the original data -- i.e. that each line is shifted
> by half a pixel from the previous line (a quarter of a pixel actually,
> since the CCD is staggered, but I think this shouldn't be important as
> long as I want to keep the final image at 2400x2400).

I think Bart van der Wolf had a short test page of several algorithms. You might
want to search archives, or contact him about that. Few people ever suggest using
bilinear, though there are some images that work better using that. It would seem
that having an option to use more than one algorithm would be of greater benefit
that forcing just one to work. Of course, the programming would be much more hefty
to do that.

>
>
> I just thought that this knowledge might have allowed me to choose an
> appropriate downsampling algorithm, instead of just using whatever
> Photoshop offers.

In a production environment, what we do is Scan Once, Output Many workflow.
Basically scanning at the highest resolution, then later using that file to match
output requirements on a case by case basis. Time constraints sometimes mean just
scanning at the output resolution needed for a project, though that can mean that
later on you would need to scan the same image in a different manner for another
project.

Ideally you try to do as much as you can prior to dumping the image file into
PhotoShop. Nearly all operations in PhotoShop are destructive editing. The other
issue is that getting the scan optimal reduces billing time in PhotoShop, though
that is more a commercial workflow necessity.

>
>
> > > 2) (the more important one) I, of course, don't want a 2:1 ratio image.
> > > I just want 2400x2400, and use the "extra" 2400 I've got on the y axis
> > > as one would use multi-sampling on a scanner supporting it. Yes, to get
> > > better image quality and less noise, as you said.
> > > But the question is, how to do it *well*?
> >
> > Or how to actually still view it as a square image.
>
> By downsampling.

Resize on one axis. Still images sent to video NLEs need a conversion to allow
them to display properly, i.e. you want a picture with a round basketball to still
look like a round basketball when displayed on a video monitor or television.

>
> After all, it's the same with scanners that can do "real"
> multi-sampling, only that
> 1) lines do not exhibit a sub-pixel shift, since the CCD is kept in the
> same positing for each sample
> 2) the scanner firmware, or the driver, hides it all to the user and
> just gives out a ready-to-use 1:1 ratio image

Just a guess, but I would think the firmware would be the place to find these
instructions. Seems that if you found your information there, then it might just
be as simple as removing that portion of it, if it does in fact work the way you
suspect.

>
>
> > [snip]
> >
> > I have not heard of anyone outside of Canon still using a staggered idea. I
> > think Microtek may have tried it, or possibly UMAX.
>
> Well, Epson certainly does it in (most of) their flatbeds.

Interesting. Just a side note, the 4870 Photo was in that test group from View
Camera magazine. While Epson state it is a 4800 ppi scanner, the best Ted Harris
got was 2050 ppi. The interesting thing I found was that Dmax tested was
substantially less than Epson claims. Rather than attempt to repeat the article
here, it might be worth it for you to order a copy, or get an old issue of this.

My feeling is that working on the actual Dmax would be more beneficial to final
image quality than playing with the resolving ability. You can try simple things
like using drum scanner oil on the flat bed, though clean-up is another issue.
There have been some good articles in Reponses Photo (French) in the past about
this method, and sometimes in a few other publications.

>
>
> > In order to really do
> > something different with that, much like the video example above, it seems
> > you would need to get the electronic signal directly off the CCD prior to any
> > in-scanner processing of the capture signal. Basically that means hacking
> > into the scanner. I don't see how that would be practical; even if you came
> > up with something, you still have a low cost scanner with limited optical
> > (true) resolution and colour abilities.
>
> But I don't think the data that come out of my scanner are very much
> adulterated (at least if I disable color correction, set gamma=1.0 and
> such stuff).

Sort of like a RAW capture from a digital camera.

>
>
> Well, when I scan at "4800 dpi" from Windows, they're certainly
> adulterated in the sense that interpolation is used on the x axis, in
> order to get a 1:1 ratio, apparent 4800x4800 dpi image.

I don't think overscanning or interpolation is all bad. Kai Hammann and a few
others have written about this for a few scanning devices. Basically what I have
found in practice is that overscanning can allow a smoother tonal transition of
colour in large areas of colour, such as sky in landscape images. Overscanning
might not improve true resolution, but it can often make the colour output just a
bit smoother. If you have not guessed it by now, I am more inclined to favour
colour quality over outright resolution.

>
>
> But I know (really, I'm not just assuming) that this interpolation is
> done in the *driver*, not in the scanner; so assuming that I can hack
> the Linux driver to support 4800 dpi vertically, horizontal
> interpolation becomes a non-issue: after all, it's easier to *not*
> interpolate than to interpolate!
>
> by LjL
> ljlbox@xxxxxxxxxx

Sounds like you are working with SANE. Maybe the driver would do it, but I still
think a look at the firmware might show you another option. Anyway, best of luck,
and enjoy your project.

Ciao!

Gordon Moat
A G Studio
<http://www.allgstudio.com>


.



Relevant Pages

  • Re: Multi-sampling and "2400x4800 dpi" scanners
    ... > The KLI-10203 is a tri-linear CCD (check the FIRST line of the data ... > application) this can be set to match whatever the scanner width is - on ... that resolution is based on actual tests of scanners ... What you are missing is that not all scanning systems in flat beds use a "pass" in ...
    (comp.periphs.scanners)
  • Re: Multi-sampling and "2400x4800 dpi" scanners
    ... Without optical scaling it resolves 3600ppi, with optical scaling (as would be used in a scanner application) this can be set to match whatever the scanner width is - on the 8.5in flatbed scanner configuration that the OP is referencing, it would produce around 1200ppi. ... A colour CCD with a total of 8400 elements would only be capable of ... MAKE A 3400PIXEL LONG TRILINEAR (10200 TOTAL CELLS) CCD AND NEVER HAVE!! ... 3200ppi resolution requires a scan width of no greater than 3.2" - ...
    (comp.periphs.scanners)
  • Re: Multi-sampling and "2400x4800 dpi" scanners
    ... Without optical scaling it resolves 3600ppi, with optical scaling (as would be used in a scanner application) this can be set to match whatever the scanner width is - on the 8.5in flatbed scanner configuration that the OP is referencing, it would produce around 1200ppi. ... but it has no effect on the fact that this device will produce a resolution of 1200ppi on an 8.5" scan width. ... that the 10200pixel CCD is only capable of 3400ppi! ... The MTF of your example Kodak array is around 60% at Nyquist, ...
    (comp.periphs.scanners)
  • Re: Multi-sampling and "2400x4800 dpi" scanners
    ... > twice the horizontal resolution, such as 2400x4800 dpi. ... So in theory an 8400 element linear CCD should be able to resolve 2800 ... and scanner optics will affect resolution. ...
    (comp.periphs.scanners)
  • Re: Sprintscan 35+, 10 bits vs 8 bits
    ... most scanning programs preview at what they consider "enough" resolution. ... You're still stuck in the scanner program with inadequate and limited set of editing tools. ... In this case, you're obviously right (though, you know, people make compromises for speed, storage space and all, and I don't think mine is so terrible a compromise if done carefully). ...
    (comp.periphs.scanners)