Which free software could acquire 48 bits color depth pictures from a scanner ?

Discussion in 'Scanners' started by Guilbert STABILO, Nov 16, 2008.

  1. Are you referring specifically to RGB image manipulations, or
    calculations in general? Because many implementations use an extra two
    to four extra bits in running calculations as opposed to the data
    precision.

    I also don't understand why someone would use flotaing point
    calculations on an RGB image. You'd get much faster processing by
    using integer arithmetic, which is all that's needed in this case. Odd
    bits of accessory floating point such as bicubic interpolations should
    be handled in a compartmentalised ad hoc basis within a framework of
    integrals.
     
    Chris Malcolm, Nov 18, 2008
    #81
    1. Advertisements

  2. Guilbert STABILO

    hank growins Guest

    Study the Lanczos-8 algorithm. This is why PhotoShop can't use this more
    advanced resizing/rotation method, due their 16-bit math platform all these
    years.
     
    hank growins, Nov 18, 2008
    #82
    1. Advertisements

  3. Thanks, I am going to have a look. Anyway, I know I am not going to buy
    (I do not have enough money) and it my scan jobs will take me more than
    30 days.



    calculations on an 8 bit per channel image.

    OK the pictures are displayed using the 8 bits color depth and the
    calculation are made with a 32 or 64 bits depth definition. That's what I
    am looking for : I want to process my pictures without destroying too
    much information.



    Thanks, I have a look too but I prefer free or better free & open-source
    graphical applications.



    I recognize that I did not think of it (low picture dynamic range).
    The reason why I am looking for 16 bits is the following one : I changed
    the colour curves and noticed that many color levels were destroyed by
    the curve change. I was told that a 16 bits depth encoding would allow to
    apply successive image processings without destroying too much
    information.



    You said it, I have major changes to apply to my pictures (using
    curves).
    then it will.

    Exactly.
    Thanks for the soft name.
    including the internal image format, is still restricted to using 8-bit
    depth images.

    OK so GIMP will not help me because I suppose that the scanned pictures
    will be transfered in 8 bits (so the 16 bits color depth will be
    destroyed).
    direction, so while it might happen before 2.8 is released it isn't yet
    obvious.

    I read that GIMP 3.0 would handle at least 16 bits pictures (I even read
    32 bits but I am not sure I understood correctly).



    ordinary pictorial photography? For normal photography, you'd have to be
    doing some huge changes to the image for this to make any difference like
    fixing wildly underexposed shots.

    Depending on the pictures (old films), perhaps I will have to do huge
    change so first I want to scan them with the maximum color depth then
    process them later. Moreover, I do not own the films so I have a limited
    time for scanning.



    You are the second person talking about Cinepaint so it seems to be a
    good software :)
    I went on the Web site and only saw the source code downloads (I am using
    Windows XP).
    I suppose I will have to build it (no problem, I am a software engineer
    ;-)). Anyway, I am going to Google for it because I am sure somebody
    already did the Windows build.


    Thanks everybody for all your useful & interesting comments.
     
    Guilbert STABILO, Nov 18, 2008
    #83
  4. I got the CinePaint 0.16 Windows build from SourceForge just here:

    http://sourceforge.net/project/showfiles.php?group_id=57007

    .... but it seems that it does not recognize my Canon CS5200F scanner
    whereas GIMP does. When I ask it to display the input devices, CinePaint
    says "No input device". I suppose there is a more recent version of the
    sofware. I going to dig further !
     
    Guilbert STABILO, Nov 18, 2008
    #84
  5. Guilbert STABILO

    Eric Stevens Guest

    My understanding was that many of the real-world implimentations of
    floating point emulators could give errors of one kind or another.
    Generally not large errors but errors nevertheless.



    Eric Stevens
     
    Eric Stevens, Nov 18, 2008
    #85
  6. Guilbert STABILO

    Eric Stevens Guest

    I was thinking of finite element calculations and I should have
    written when models are large and complex. Finite element models
    divide objects into cells and calculate from one cell to the next. The
    opening conditions for one cell are the closing conditions for the
    previous cell. Errors in the calculation of the properties of the
    first cell are passed on into the second - which then generates its
    own additional errors and passes the lot on to the third. Accumulated
    errors of 10~20% were not unknown.



    Eric Stevens
     
    Eric Stevens, Nov 18, 2008
    #86
  7. The problem isn't hardware implementation versus software emulation, the
    problem is the concept of floating point arithmetic in itself.
    The number of "real numbers" as defined by mathematicians is infinite,
    the number of possible representations on a real-world computer is very
    limited. Therefore almost all real numbers can only be approximated on a
    real computer, no matter if in hard- or software.

    Trivial paper experiment:
    take 1, divide by 3 (to whatever precision you like), multiply by 3, and
    contrary to idealized mathematics you will NOT get 1 again:

    1: 1
    2: 0.333333333
    3: 0.999999999

    If the naive programer tries to compare the result to 1 then he will get
    a nasty surprise. Another well-known example are operations involving
    numbers of vastly different order of magnitude, e.g. adding a very tiny
    number to a very large number.

    jue
     
    Jürgen Exner, Nov 18, 2008
    #87
  8. Guilbert STABILO

    Ray Fischer Guest

    YES! In fact it is common in software to write routines with
    GREATER accuracy than can be provided by the hardware.
     
    Ray Fischer, Nov 19, 2008
    #88
  9. Guilbert STABILO

    Ray Fischer Guest

    The Apple //e, with its 8-bit 6502 processor clocked at 1MHz only had
    instructions for adding eight bits. No mulitply, no floating point, no
    divide, of ANY size. No 32-bit math instructions.

    But algorithms can be expressed in software even easier than they can
    be expressed in hardware, and so Pascal supported 32-bit integer math
    as well as floating point math on that 6502. It just wasn't very
    fast.
     
    Ray Fischer, Nov 19, 2008
    #89
  10. Guilbert STABILO

    Ray Fischer Guest

    And I'm a software engineer who knows about implementing math routines
    using nothing more than integer add instructions.
    No. You just need to know how floating point calculations introduce
    errors.
     
    Ray Fischer, Nov 19, 2008
    #90
  11. Guilbert STABILO

    Ray Fischer Guest

    But that is true regardless of whether the floating-point math is done
    in software or hardware.
     
    Ray Fischer, Nov 19, 2008
    #91
  12. Guilbert STABILO

    Ray Fischer Guest

    I know why.

    Do you?
     
    Ray Fischer, Nov 19, 2008
    #92
  13. Guilbert STABILO

    Ray Fischer Guest

    The amount of error has nothing at all to do with whether the
    processor is 8-bit or 64-bit. It has everything to do with the
    specific implemenation of the floating point routines and the ordering
    of operations done by the compiler.
     
    Ray Fischer, Nov 19, 2008
    #93
  14. Guilbert STABILO

    Ray Fischer Guest

    And even when the coprocessor was absent the computer could do the
    exact same calculations using software.
     
    Ray Fischer, Nov 19, 2008
    #94
  15. Guilbert STABILO

    Ray Fischer Guest

    And what are your software qualifications?
    You're a liar
    Then stop doing so.
    Stop lying.
    Stupid asshole.
     
    Ray Fischer, Nov 19, 2008
    #95
  16. Guilbert STABILO

    Mark Thomas Guest

    What a surprise that it ended up at this level.

    I just wish it had got there sooner to save all the trouble.
     
    Mark Thomas, Nov 19, 2008
    #96
  17. Guilbert STABILO

    PhilAdmore Guest

    And what did we learn from this kiddies?

    If you don't have enough math-processing bit-depth then it can't adequately
    handle the color bit-depth of contemporary digital photography formats due to
    rounding errors. As what was originally stated and started this monotonous
    diatribe of who knows how to compute and who does not. This is also why
    PhotoShop has been a 16-bit math platform until CS4, even now except for a few
    operations that they updated to 32-bit math (sure, it can run on a 64-bit
    system, that doesn't mean it is operating at 64-bit math level).

    Note the similar painful upgrade of PaintShopPro 9 to X to XI to XII, where
    still not all filters and operations can be used on 16-bit depth color images,
    the new owners (Corel) can't rewrite the old routines in 32-bit math because
    they either don't care or they're just not intelligent enough. The same holds
    true for PhotoShop's recent crippled 32-bit math incorporation. If it was not
    32-bit math all these years it could have incorporated the advanced Lanczos-8
    algorithms long ago, a simple 32-bit math routine that ensures the most retained
    detail between resizings, rotations, perspective distortions, and lens
    corrections. Until PhotoShop can include Lanczos routine by default, it's still
    a lowly 16-bit math package with its detail-blurring Bicubic nonsense from last
    century.

    Photoline and other 32-bit math editors (even freeware IrfanView) have had
    Lanczos routines as part of their basic processes for many many years, why not
    PhotoShop? Because PhotoShop is still mostly a lowly 16-bit math platform.

    Deal with it.

    Case closed.

    Hundreds of nails in the coffin.

    Dead and buried ... long ago.
     
    PhilAdmore, Nov 19, 2008
    #97
  18. Guilbert STABILO

    Ray Fischer Guest

    And how are rounding erors an issue?
    And note that there is no output device that can represent
    16-bits/channel of color information.
    Or because nobody cares.
    Now tell us why 32-bit math is important.
    That doesn't even make any sense. They can use any math that they
    think is worth the trouble.
    They're not likely to spend the effort just to allow some clueless
    people to check off a "feature" that they don't even understand.
     
    Ray Fischer, Nov 19, 2008
    #98
  19. Guilbert STABILO

    Walt-Kasner Guest

    Only the most lame of amateurs wouldn't know why you'd choose Lanczos routines.

    Let us educate yet another pretend-photographer moron troll ....

    http://www.all-in-one.ee/~dersch/interpolator/interpolator.html
     
    Walt-Kasner, Nov 19, 2008
    #99
  20. Guilbert STABILO

    Walt-Kasner Guest

    Only the most lame of amateurs wouldn't know why you'd choose Lanczos routines.

    Let us educate yet another pretend-photographer moron troll ....

    http://www.all-in-one.ee/~dersch/interpolator/interpolator.html


    p.s. In case you are as stupid as you've already revealed yourself to be,
    Sinc-256 is the same as Lanczos-8.

    I wouldn't want you to make an even bigger fool of yourself than you already
    have by having to ask what the data and tests on that page have to do with the
    discussion.
     
    Walt-Kasner, Nov 19, 2008
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.