[
https://issues.apache.org/jira/browse/IMAGING-159?focusedWorklogId=540528&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-540528
]
ASF GitHub Bot logged work on IMAGING-159:
------------------------------------------
Author: ASF GitHub Bot
Created on: 23/Jan/21 13:40
Start Date: 23/Jan/21 13:40
Worklog Time Spent: 10m
Work Description: gwlucastrig commented on pull request #116:
URL: https://github.com/apache/commons-imaging/pull/116#issuecomment-766068067
I need a bit more time to review this, but one thing occurs to me right
away. In the TIFF standard, there are a number of special data formats and
bit-packing sequences (T4 fax, etc.) that are unique to TIFF and some that are
similar to other formats. Also, I am not sure that Commons Imaging supports
all the TIFF options. So having an enumerated type specific to the TIFF
package makes sense for that purpose because it serves as a kind of
documentation of what is done (values included in the enumeration) and what
still needs to be done (values not found in the enumeration). I'm not sure
about compression type (LZW versus Zip, etc.), but that could be the same kind
of thing.
On the other hand, there are other a few options that are common to all or
many graphics formats (indexed color model versus RGB versus CMYK, etc.). So I
would agree that those go in the common package.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 540528)
Time Spent: 20m (was: 10m)
> There should be a Parameters class
> ----------------------------------
>
> Key: IMAGING-159
> URL: https://issues.apache.org/jira/browse/IMAGING-159
> Project: Commons Imaging
> Issue Type: Improvement
> Components: imaging.*
> Affects Versions: 1.0-alpha2
> Reporter: Benedikt Ritter
> Assignee: Bruno P. Kinoshita
> Priority: Major
> Labels: github
> Fix For: 1.0-alpha3
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently options for image I/O are defined as Maps. The leads to the problem
> that our code has to validate parameter types when they are used:
> {code:java}
> final Object value = params.get(PARAM_KEY_COMPRESSION);
> if (value != null) {
> if (!(value instanceof Number)) {
> throw new ImageWriteException(
> "Invalid compression parameter, must be numeric: "
> + value);
> }
> compression = ((Number) value).intValue();
> }
> {code}
> This can be simplified if we define a Parameters class that provides
> additional methods like {{public int getInt(String key)}}. The implementation
> could then look up the value from the map through an exception if it is null
> or not a number.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
