[
https://issues.apache.org/jira/browse/IMAGING-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17218669#comment-17218669
]
Bruno P. Kinoshita commented on IMAGING-271:
--------------------------------------------
Hi [~gwlucas] ,
Very well written proposal!
>The proposed approach would allow an application to "append" data to a TIFF
>file making multiple calls to output methods. The TIFF specification calls for
>files to be organized into "sections" (strips or tiles). This class will
>permit an application to write data to the TIFF file a section at a time.
Sounds like a good idea!
> I have attached a stub Java class to provide an example of the proposed
> design. This example is intended to promote discussion and help identify
> relevant features for the initial implementation.
Looks good, and impressive comments. I just didn't understand why we couldn't
use OutputStreams too? (I see your comment further down your proposal, so will
comment there too).
>Some guiding principles and concepts for design:
>1 Simplicity. The greatest strength of the TIFF file format, its versatility,
>is also its greatest weakness. The need to support such a large variety of
>data formats and operations leads to a complicated API that is sometimes
>difficult to use. The proposed design limits some of the output functionality
>in order to maintain a simpler API.
Q1: Is this writer replacing the existing one?
Q2: If yes, then could it happen that later on we have to add more features to
the TIFF writers, and we are limited by this new design? And in which case we
could end up having to re-complicate it?
Q3: If not, then could having to maintain two writers create any issues?
>2 Essential features only. Currently, I have limited resources to devote to
>this implementation. My intention is to implement only those functions that
>make the class viable. So the challenge here will be determining what those
>features are. Comments are welcome. On the other hand, I am striving for a
>design that will facilitate future development to add other features as they
>are identified by the user community.
Sounds good to me, though I'd copy the two questions above here. But if this is
a new writer, then no issues I think.
>3 Operates on files, and only files. The current Commons Imaging API supports
>output to various kinds of Java OutputStreams, including memory and socket
>streams. This class is purposely designed to write to random-access files.
>This consideration is particularly important to support cases where the
>ultimate size of the output content cannot be determined a priori.
Related to a comment I made further up. Wouldn't it be easy to support streams?
I thought that since it's a writer that will be memory efficient, and won't
need a BufferImage, it would be using IO streams to send the data whenever it
needed to write something?
> Proposed new class for memory-efficient TIFF image writing
> ----------------------------------------------------------
>
> Key: IMAGING-271
> URL: https://issues.apache.org/jira/browse/IMAGING-271
> Project: Commons Imaging
> Issue Type: New Feature
> Components: Format: TIFF
> Affects Versions: 1.0-alpha3
> Reporter: Gary Lucas
> Priority: Major
> Attachments: TiffImageWriterAppender.java
>
>
> I am proposing to implement a new class for writing TIFF images in a
> memory-efficient manner. This class will permit the creation of large-scale
> TIFF images without undue requirements for memory. It will also support the
> creation of TIFF files containing multiple images (in TIFF terminology,
> "directories").
> I am posting this Jira item to request suggestions for the design of the
> class as well as to identify requirements from potential users.
> The current TIFF image-writer classes operate on an entire BufferedImage and
> actually make a copy of the image data before writing it to an output stream.
> They do not permit the creation of output images "a piece at a time". So
> for very large images, they can require considerable use of memory.
> The proposed approach would allow an application to "append" data to a TIFF
> file making multiple calls to output methods. The TIFF specification calls
> for files to be organized into "sections" (strips or tiles). This class will
> permit an application to write data to the TIFF file a section at a time.
> I have attached a stub Java class to provide an example of the proposed
> design. This example is intended to promote discussion and help identify
> relevant features for the initial implementation.
> Some guiding principles and concepts for design:
> # Simplicity. The greatest strength of the TIFF file format, its
> versatility, is also its greatest weakness. The need to support such a large
> variety of data formats and operations leads to a complicated API that is
> sometimes difficult to use. The proposed design limits some of the output
> functionality in order to maintain a simpler API.
> # Essential features only. Currently, I have limited resources to devote to
> this implementation. My intention is to implement only those functions that
> make the class viable. So the challenge here will be determining what those
> features are. Comments are welcome. On the other hand, I am striving for a
> design that will facilitate future development to add other features as they
> are identified by the user community.
> # Operates on files, and only files. The current Commons Imaging API
> supports output to various kinds of Java OutputStreams, including memory and
> socket streams. This class is purposely designed to write to random-access
> files. This consideration is particularly important to support cases where
> the ultimate size of the output content cannot be determined a priori.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
