FAQ
Hi,

I want to use go.image/tiff read/write very large tiff image (2~GB).
The image.Decode/image.Encode can't work with large image.

And the large tiff general use Tiled/PlanarConfiguration/Gray16/... format.
If image larger than 4GB, even use bigtiff format.

So i desinge some new api for read/write large tiff/bigtiff image,
it only support one image(ifd) in a tiff file.

// ImageMode represents the mode of the image.
type ImageMode int

const (
ImageMode_Bilevel ImageMode = iota
ImageMode_Paletted
  ImageMode_Gray
ImageMode_GrayInvert
ImageMode_RGB
  ImageMode_RGBA
ImageMode_NRGBA
)

// Options are the encoding parameters.
type Options struct {
Width int
Height int
Mode ImageMode

BigTiff bool
BigEndian bool

// Compression is the type of compression used.
  Compression CompressionType
// Predictor determines whether a differencing predictor is used;
// if true, instead of each pixel's color, the color difference to the
  // preceding one is saved. This improves the compression for certain
// types of images and compressors. For example, it works well for
  // photos with Deflate compression.
Predictor bool
}

// File is defined as an incomplete type to hide the
// library's internal data structures from clients.
type File struct {
Opt Options // read only
f *os.File
}

// Open opens the named tiff or bigtiff file for reading.
func Open(name string) (*File, error) {
return nil, nil
}

// Create creates the named tiff or bigtiff file,
// truncating it if it already exists.
func Create(name string, opt Options) (*File, error) {
return nil, nil
}

// Close closes the File.
func (tif *File) Close() {
//
}

// GetField get fiels value with tag.
func (tif *File) GetField(tag int) ([]byte, error) {
return nil, nil
}

// SetField set fiels value with tag.
// Change some read only fiels will return error.
func (tif *File) SetField(tag int, data []byte) error {
return nil
}

// DelField delete fiels with tag.
// Delete some read only fiels will return error.
func (tif *File) DelField(tag int) error {
return nil
}

// Decode reads a sub image to dst.
func (tif *File) Deocde(pos image.Point, dst image.Image) error {
  return nil
}

// Encode write a sub image from src.
func (tif *File) Encode(pos image.Point, src image.Image) error {
  return nil
}


--
chaishushan
http://my.oschina.net/chai2010
https://bitbucket.org/chai2010

--

---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Chai2010 at Sep 3, 2013 at 6:04 am
    Include Gray16 mode.

    // ImageMode represents the mode of the image.
    type ImageMode int

    const (
    ImageMode_Bilevel ImageMode = iota
      ImageMode_Paletted
    ImageMode_Gray
    ImageMode_GrayInvert
    * ImageMode_Gray16*
    * ImageMode_Gray16Invert*
    ImageMode_RGB
      ImageMode_RGBA
    ImageMode_NRGBA
    )


    2013/9/3 chai2010 <chaishushan@gmail.com>
    Hi,

    I want to use go.image/tiff read/write very large tiff image (2~GB).
    The image.Decode/image.Encode can't work with large image.

    And the large tiff general use Tiled/PlanarConfiguration/Gray16/... format.
    If image larger than 4GB, even use bigtiff format.

    So i desinge some new api for read/write large tiff/bigtiff image,
    it only support one image(ifd) in a tiff file.

    // ImageMode represents the mode of the image.
    type ImageMode int

    const (
    ImageMode_Bilevel ImageMode = iota
    ImageMode_Paletted
    ImageMode_Gray
    ImageMode_GrayInvert
    ImageMode_RGB
    ImageMode_RGBA
    ImageMode_NRGBA
    )

    // Options are the encoding parameters.
    type Options struct {
    Width int
    Height int
    Mode ImageMode

    BigTiff bool
    BigEndian bool

    // Compression is the type of compression used.
    Compression CompressionType
    // Predictor determines whether a differencing predictor is used;
    // if true, instead of each pixel's color, the color difference to the
    // preceding one is saved. This improves the compression for certain
    // types of images and compressors. For example, it works well for
    // photos with Deflate compression.
    Predictor bool
    }

    // File is defined as an incomplete type to hide the
    // library's internal data structures from clients.
    type File struct {
    Opt Options // read only
    f *os.File
    }

    // Open opens the named tiff or bigtiff file for reading.
    func Open(name string) (*File, error) {
    return nil, nil
    }

    // Create creates the named tiff or bigtiff file,
    // truncating it if it already exists.
    func Create(name string, opt Options) (*File, error) {
    return nil, nil
    }

    // Close closes the File.
    func (tif *File) Close() {
    //
    }

    // GetField get fiels value with tag.
    func (tif *File) GetField(tag int) ([]byte, error) {
    return nil, nil
    }

    // SetField set fiels value with tag.
    // Change some read only fiels will return error.
    func (tif *File) SetField(tag int, data []byte) error {
    return nil
    }

    // DelField delete fiels with tag.
    // Delete some read only fiels will return error.
    func (tif *File) DelField(tag int) error {
    return nil
    }

    // Decode reads a sub image to dst.
    func (tif *File) Deocde(pos image.Point, dst image.Image) error {
    return nil
    }

    // Encode write a sub image from src.
    func (tif *File) Encode(pos image.Point, src image.Image) error {
    return nil
    }


    --
    chaishushan
    http://my.oschina.net/chai2010
    https://bitbucket.org/chai2010

    --
    chaishushan
    http://my.oschina.net/chai2010
    https://bitbucket.org/chai2010

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Nigel Tao at Sep 3, 2013 at 6:59 am

    On Tue, Sep 3, 2013 at 3:57 PM, chai2010 wrote:
    I want to use go.image/tiff read/write very large tiff image (2~GB).
    The image.Decode/image.Encode can't work with large image.
    The image.Decode function does not mandate that the returned Image is
    entirely in-memory. The common implementations (e.g. image.RGBA) are,
    but the image.Image interface does not require that.

    Also, it may already be possible to support very large in-memory
    images if you are on 64-bit Go, and obviously have enough memory.

    So i desinge some new api for read/write large tiff/bigtiff image,
    You are of course free to do that. It may be worth committing your
    code to a separate repository (e.g. your own github or code.google.com
    project) while you explore your API design, before trying to commit
    directly to the go.image sub-repo, especially if your new design will
    have performance or other regressions. For example...

    // Open opens the named tiff or bigtiff file for reading.
    func Open(name string) (*File, error) {
    return nil, nil
    }
    ...I would consider this a regression, as you could no longer decode a
    TIFF image from an arbitrary io.Reader (e.g. from an HTTP connection),
    only from an OS file.

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Chai2010 at Sep 8, 2013 at 2:49 am
    I update the large image api at:
    https://codereview.appspot.com/13333046/


    2013/9/3 Nigel Tao <nigeltao@golang.org>
    On Tue, Sep 3, 2013 at 3:57 PM, chai2010 wrote:
    I want to use go.image/tiff read/write very large tiff image (2~GB).
    The image.Decode/image.Encode can't work with large image.
    The image.Decode function does not mandate that the returned Image is
    entirely in-memory. The common implementations (e.g. image.RGBA) are,
    but the image.Image interface does not require that.

    Thanks for you explain.
    I add a new tiff.Image struct for out-memory image.
    The tiff.Image also match the image.Image interface.
    So the tiff.Decode can return tiff.Image for large image.

    Also, it may already be possible to support very large in-memory
    images if you are on 64-bit Go, and obviously have enough memory.
    I use the Win7/64, but a only have 4GB memory.
    I can't Decode a large tiff image (2~GB).

    So i desinge some new api for read/write large tiff/bigtiff image,
    You are of course free to do that. It may be worth committing your
    code to a separate repository (e.g. your own github or code.google.com
    project) while you explore your API design, before trying to commit
    directly to the go.image sub-repo, especially if your new design will
    have performance or other regressions. For example...
    I don't want commit the new api to go.image now.
    I just hope the tiff api can support very large image.
    But i am a newbie, i need some help for api design(for very large image).

    I thought the go.image need support the image.RegisterFormat func,
    and has some special type/func for it's special feature.

    // Open opens the named tiff or bigtiff file for reading.
    func Open(name string) (*File, error) {
    return nil, nil
    }
    ...I would consider this a regression, as you could no longer decode a
    TIFF image from an arbitrary io.Reader (e.g. from an HTTP connection),
    only from an OS file.
    For large image read/write/update, we need io.ReadWriteSeeker.
    It is not a good idea to read a very large tiff from HTTP (we could save as
    a temp file).
    Of course, tiff.Decode should support read from an HTTP connection(but
    still can't read very large image) .

    Thanks.

    --
    chaishushan
    http://my.oschina.net/chai2010
    https://bitbucket.org/chai2010

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Chai2010 at Sep 8, 2013 at 3:29 am
    I changed the io.ReadWriteSeeker to io.Reader and io.Writer.
    But we need temp file for ReadAt and WriteAt large tiff image.


    2013/9/8 chai2010 <chaishushan@gmail.com>
    I update the large image api at:
    https://codereview.appspot.com/13333046/


    2013/9/3 Nigel Tao <nigeltao@golang.org>
    On Tue, Sep 3, 2013 at 3:57 PM, chai2010 wrote:
    I want to use go.image/tiff read/write very large tiff image (2~GB).
    The image.Decode/image.Encode can't work with large image.
    The image.Decode function does not mandate that the returned Image is
    entirely in-memory. The common implementations (e.g. image.RGBA) are,
    but the image.Image interface does not require that.

    Thanks for you explain.
    I add a new tiff.Image struct for out-memory image.
    The tiff.Image also match the image.Image interface.
    So the tiff.Decode can return tiff.Image for large image.

    Also, it may already be possible to support very large in-memory
    images if you are on 64-bit Go, and obviously have enough memory.
    I use the Win7/64, but a only have 4GB memory.
    I can't Decode a large tiff image (2~GB).

    So i desinge some new api for read/write large tiff/bigtiff image,
    You are of course free to do that. It may be worth committing your
    code to a separate repository (e.g. your own github or code.google.com
    project) while you explore your API design, before trying to commit
    directly to the go.image sub-repo, especially if your new design will
    have performance or other regressions. For example...
    I don't want commit the new api to go.image now.
    I just hope the tiff api can support very large image.
    But i am a newbie, i need some help for api design(for very large image).

    I thought the go.image need support the image.RegisterFormat func,
    and has some special type/func for it's special feature.

    // Open opens the named tiff or bigtiff file for reading.
    func Open(name string) (*File, error) {
    return nil, nil
    }
    ...I would consider this a regression, as you could no longer decode a
    TIFF image from an arbitrary io.Reader (e.g. from an HTTP connection),
    only from an OS file.
    For large image read/write/update, we need io.ReadWriteSeeker.
    It is not a good idea to read a very large tiff from HTTP (we could save
    as a temp file).
    Of course, tiff.Decode should support read from an HTTP connection(but
    still can't read very large image) .

    Thanks.


    --
    chaishushan
    http://my.oschina.net/chai2010
    https://bitbucket.org/chai2010

    --
    chaishushan
    http://my.oschina.net/chai2010
    https://bitbucket.org/chai2010

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Nigel Tao at Sep 9, 2013 at 1:05 am

    On Sun, Sep 8, 2013 at 12:49 PM, chai2010 wrote:
    I update the large image api at:
    https://codereview.appspot.com/13333046/
    It's not clear to me why you need separate Tiff and Image types. I
    would have a Decode function return an image.Image, which could be an
    image.RGBA for non-tiled images and a tiff.TiledImage for tiled
    images.

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Chai2010 at Sep 9, 2013 at 1:49 am
    The tiff.Tiff can support more tiff features,
    it can read/write/update tiff image and read/write all tiff tags.
    But the tiff.Tiff have no more memory cache,
    so it does not support the `(m *Image) At(x, y int) color.Color` method,
    (all in memory is not a priority).

    And the image.Image is a read only interface.
    The tiff.Image match the image.Image interface, it can have some memory
    cache,
    so it is read friendly for very large image.

    If we update very large tiff image by tiff.Image type,
    the tiff.Image will need all read/write/update method,
    it is too complex.

    In my designed api, the tiff.Tiff is embedded in tiff.Image type.
    If we need update very large tiff image, we can update every tile by
    tiff.Image.TileImage(idx),
    and then write the tile by tiff.Image.Tiff.EncodeTile(idx, tile).

    If we use tiff.TiledImage for tiled images,
    then we also need tiff.StripedImage for striped images.
    If the striped/tiled images are small,
    we can just use image.RGBA type (all in memory).

    Thanks for your reply.



    2013/9/9 Nigel Tao <nigeltao@golang.org>
    On Sun, Sep 8, 2013 at 12:49 PM, chai2010 wrote:
    I update the large image api at:
    https://codereview.appspot.com/13333046/
    It's not clear to me why you need separate Tiff and Image types. I
    would have a Decode function return an image.Image, which could be an
    image.RGBA for non-tiled images and a tiff.TiledImage for tiled
    images.


    --
    chaishushan
    http://my.oschina.net/chai2010
    https://bitbucket.org/chai2010

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedSep 3, '13 at 5:58a
activeSep 9, '13 at 1:49a
posts7
users2
websitegolang.org

2 users in discussion

Chai2010: 5 posts Nigel Tao: 2 posts

People

Translate

site design / logo © 2021 Grokbase