[jira] [Commented] (CSV-141) Handle malformed CSV files

[Damjan Jovanovic (Jira)]

[ 
https://issues.apache.org/jira/browse/CSV-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17654605#comment-17654605
 ] 

Damjan Jovanovic commented on CSV-141:
--

That seems like a standard warning when saving though, similar to what 
OpenOffice gives you on any CSV file, regardless of the content?

I've now updated my PR with another setting for the "EOF reached before 
encapsulated token finished".

> Handle malformed CSV files
> --
>
> Key: CSV-141
> URL: https://issues.apache.org/jira/browse/CSV-141
> Project: Commons CSV
>  Issue Type: Wish
>  Components: Parser
>Affects Versions: 1.0
>Reporter: Nguyen Minh
>Priority: Minor
> Fix For: 1.x
>
> Attachments: image-2023-01-04-14-00-57-158.png
>
>
> My java application has to handle thousands of CSV files uploaded by the 
> client phones everyday. So, there some CSV files have the wrong format which 
> I'm not sure why.
> Here is my sample CSV. Microsoft Excel parses it correctly, but both Common 
> CSV and OpenCSV can't parse it. Open CSV can't parse line 2 (due to '\' 
> character) and Common CSV will crash on line 3 and 4:
> "1414770317901","android.widget.EditText","pass sem1 _84*|*","0","pass sem1 
> _8"
> "1414770318470","android.widget.EditText","pass sem1 _84:*|*","0","pass sem1 
> _84:\"
> "1414770318327","android.widget.EditText","pass sem1 
> "1414770318628","android.widget.EditText","pass sem1 _84*|*","0","pass sem1
> Line 3: java.io.IOException: (line 5) invalid char between encapsulated token 
> and delimiter
>   at org.apache.commons.csv.CSVParser$1.getNextRecord(CSVParser.java:398)
>   at org.apache.commons.csv.CSVParser$1.hasNext(CSVParser.java:407)
> Line 4: java.io.IOException: (startline 5) EOF reached before encapsulated 
> token finished
>   at org.apache.commons.csv.CSVParser$1.getNextRecord(CSVParser.java:398)
>   at org.apache.commons.csv.CSVParser$1.hasNext(CSVParser.java:407)



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (CSV-141) Handle malformed CSV files

[Damjan Jovanovic (Jira)]

[ 
https://issues.apache.org/jira/browse/CSV-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17652125#comment-17652125
 ] 

Damjan Jovanovic edited comment on CSV-141 at 12/27/22 5:43 AM:


This kind of patch:
{code:java}
// code placeholder
diff --git a/src/main/java/org/apache/commons/csv/Lexer.java 
b/src/main/java/org/apache/commons/csv/Lexer.java
index fd60b5ac..177f56d6 100644
--- a/src/main/java/org/apache/commons/csv/Lexer.java
+++ b/src/main/java/org/apache/commons/csv/Lexer.java
@@ -378,9 +378,15 @@ final class Lexer implements Closeable {
                     }
                 }
             } else if (isEndOfFile(c)) {
-                // error condition (end of file before end of token)
-                throw new IOException("(startline " + startLineNumber +
-                        ") EOF reached before encapsulated token finished");
+                if (allowTrailingText) {
+                    token.type = EOF;
+                    token.isReady = true; // There is data at EOF
+                    return token;
+                } else {
+                    // error condition (end of file before end of token)
+                    throw new IOException("(startline " + startLineNumber +
+                            ") EOF reached before encapsulated token 
finished");
+                }
             } else {
                 // consume character
                 token.content.append((char) c); {code}
gets the EOF-implicitly-closes-encapsulated-field feature to work too, and 
successfully parses the CSV snippet in the original comment in the same way as 
Excel.

I am not sure whether this should be activated by the same flag 
(allowTrailingText) as my PR, or whether it should be a separate setting users 
can toggle on and off. [~ggregory]?


was (Author: damjan):
This kind of patch:
{code:java}
// code placeholder
diff --git a/src/main/java/org/apache/commons/csv/Lexer.java 
b/src/main/java/org/apache/commons/csv/Lexer.java
index fd60b5ac..177f56d6 100644
--- a/src/main/java/org/apache/commons/csv/Lexer.java
+++ b/src/main/java/org/apache/commons/csv/Lexer.java
@@ -378,9 +378,15 @@ final class Lexer implements Closeable {
                     }
                 }
             } else if (isEndOfFile(c)) {
-                // error condition (end of file before end of token)
-                throw new IOException("(startline " + startLineNumber +
-                        ") EOF reached before encapsulated token finished");
+                if (allowTrailingText) {
+                    token.type = EOF;
+                    token.isReady = true; // There is data at EOF
+                    return token;
+                } else {
+                    // error condition (end of file before end of token)
+                    throw new IOException("(startline " + startLineNumber +
+                            ") EOF reached before encapsulated token 
finished");
+                }
             } else {
                 // consume character
                 token.content.append((char) c); {code}
gets the EOF-implicitly-closes-unquoted-field feature to work too, and 
successfully parses the CSV snippet in the original comment in the same way as 
Excel.

I am not sure whether this should be activated by the same flag 
(allowTrailingText) as my PR, or whether it should be a separate setting users 
can toggle on and off. [~ggregory]?

> Handle malformed CSV files
> --
>
> Key: CSV-141
> URL: https://issues.apache.org/jira/browse/CSV-141
> Project: Commons CSV
>  Issue Type: Wish
>  Components: Parser
>Affects Versions: 1.0
>Reporter: Nguyen Minh
>Priority: Minor
> Fix For: 1.x
>
>
> My java application has to handle thousands of CSV files uploaded by the 
> client phones everyday. So, there some CSV files have the wrong format which 
> I'm not sure why.
> Here is my sample CSV. Microsoft Excel parses it correctly, but both Common 
> CSV and OpenCSV can't parse it. Open CSV can't parse line 2 (due to '\' 
> character) and Common CSV will crash on line 3 and 4:
> "1414770317901","android.widget.EditText","pass sem1 _84*|*","0","pass sem1 
> _8"
> "1414770318470","android.widget.EditText","pass sem1 _84:*|*","0","pass sem1 
> _84:\"
> "1414770318327","android.widget.EditText","pass sem1 
> "1414770318628","android.widget.EditText","pass sem1 _84*|*","0","pass sem1
> Line 3: java.io.IOException: (line 5) invalid char between encapsulated token 
> and delimiter
>   at org.apache.commons.csv.CSVParser$1.getNextRecord(CSVParser.java:398)
>   at org.apache.commons.csv.CSVParser$1.hasNext(CSVParser.java:407)
> Line 4: java.io.IOException: (startline 5) EOF reached before encapsulated 
> token finished
>   at org.apache.commons.csv.CSVParser$1.getNextRecord(CSVParser.java:398)
>   

[jira] [Commented] (CSV-141) Handle malformed CSV files

[Damjan Jovanovic (Jira)]

[ 
https://issues.apache.org/jira/browse/CSV-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17652125#comment-17652125
 ] 

Damjan Jovanovic commented on CSV-141:
--

This kind of patch:
{code:java}
// code placeholder
diff --git a/src/main/java/org/apache/commons/csv/Lexer.java 
b/src/main/java/org/apache/commons/csv/Lexer.java
index fd60b5ac..177f56d6 100644
--- a/src/main/java/org/apache/commons/csv/Lexer.java
+++ b/src/main/java/org/apache/commons/csv/Lexer.java
@@ -378,9 +378,15 @@ final class Lexer implements Closeable {
                     }
                 }
             } else if (isEndOfFile(c)) {
-                // error condition (end of file before end of token)
-                throw new IOException("(startline " + startLineNumber +
-                        ") EOF reached before encapsulated token finished");
+                if (allowTrailingText) {
+                    token.type = EOF;
+                    token.isReady = true; // There is data at EOF
+                    return token;
+                } else {
+                    // error condition (end of file before end of token)
+                    throw new IOException("(startline " + startLineNumber +
+                            ") EOF reached before encapsulated token 
finished");
+                }
             } else {
                 // consume character
                 token.content.append((char) c); {code}
gets the EOF-implicitly-closes-unquoted-field feature to work too, and 
successfully parses the CSV snippet in the original comment in the same way as 
Excel.

I am not sure whether this should be activated by the same flag 
(allowTrailingText) as my PR, or whether it should be a separate setting users 
can toggle on and off. [~ggregory]?

> Handle malformed CSV files
> --
>
> Key: CSV-141
> URL: https://issues.apache.org/jira/browse/CSV-141
> Project: Commons CSV
>  Issue Type: Wish
>  Components: Parser
>Affects Versions: 1.0
>Reporter: Nguyen Minh
>Priority: Minor
> Fix For: 1.x
>
>
> My java application has to handle thousands of CSV files uploaded by the 
> client phones everyday. So, there some CSV files have the wrong format which 
> I'm not sure why.
> Here is my sample CSV. Microsoft Excel parses it correctly, but both Common 
> CSV and OpenCSV can't parse it. Open CSV can't parse line 2 (due to '\' 
> character) and Common CSV will crash on line 3 and 4:
> "1414770317901","android.widget.EditText","pass sem1 _84*|*","0","pass sem1 
> _8"
> "1414770318470","android.widget.EditText","pass sem1 _84:*|*","0","pass sem1 
> _84:\"
> "1414770318327","android.widget.EditText","pass sem1 
> "1414770318628","android.widget.EditText","pass sem1 _84*|*","0","pass sem1
> Line 3: java.io.IOException: (line 5) invalid char between encapsulated token 
> and delimiter
>   at org.apache.commons.csv.CSVParser$1.getNextRecord(CSVParser.java:398)
>   at org.apache.commons.csv.CSVParser$1.hasNext(CSVParser.java:407)
> Line 4: java.io.IOException: (startline 5) EOF reached before encapsulated 
> token finished
>   at org.apache.commons.csv.CSVParser$1.getNextRecord(CSVParser.java:398)
>   at org.apache.commons.csv.CSVParser$1.hasNext(CSVParser.java:407)



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CSV-141) Handle malformed CSV files

[Damjan Jovanovic (Jira)]

[ 
https://issues.apache.org/jira/browse/CSV-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17652116#comment-17652116
 ] 

Damjan Jovanovic commented on CSV-141:
--

I've made a patch for this and added a pull request at 
[https://github.com/apache/commons-csv/pull/295]

but now I see there's another problem with the CSV snippet in the original 
comment.

 

In Excel, a field with EOF before the closing quote:

a,"b

is acceptable, it becomes:

a,b

 

whereas in commons-csv, it's an error (EOF reached before encapsulated token 
finished), and in Apache OpenOffice, the entire line is silently lost.

This is something that should also be fixed, at least when using 
CSVFormat.EXCEL.

 

> Handle malformed CSV files
> --
>
> Key: CSV-141
> URL: https://issues.apache.org/jira/browse/CSV-141
> Project: Commons CSV
>  Issue Type: Wish
>  Components: Parser
>Affects Versions: 1.0
>Reporter: Nguyen Minh
>Priority: Minor
> Fix For: 1.x
>
>
> My java application has to handle thousands of CSV files uploaded by the 
> client phones everyday. So, there some CSV files have the wrong format which 
> I'm not sure why.
> Here is my sample CSV. Microsoft Excel parses it correctly, but both Common 
> CSV and OpenCSV can't parse it. Open CSV can't parse line 2 (due to '\' 
> character) and Common CSV will crash on line 3 and 4:
> "1414770317901","android.widget.EditText","pass sem1 _84*|*","0","pass sem1 
> _8"
> "1414770318470","android.widget.EditText","pass sem1 _84:*|*","0","pass sem1 
> _84:\"
> "1414770318327","android.widget.EditText","pass sem1 
> "1414770318628","android.widget.EditText","pass sem1 _84*|*","0","pass sem1
> Line 3: java.io.IOException: (line 5) invalid char between encapsulated token 
> and delimiter
>   at org.apache.commons.csv.CSVParser$1.getNextRecord(CSVParser.java:398)
>   at org.apache.commons.csv.CSVParser$1.hasNext(CSVParser.java:407)
> Line 4: java.io.IOException: (startline 5) EOF reached before encapsulated 
> token finished
>   at org.apache.commons.csv.CSVParser$1.getNextRecord(CSVParser.java:398)
>   at org.apache.commons.csv.CSVParser$1.hasNext(CSVParser.java:407)



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CSV-141) Handle malformed CSV files

[Damjan Jovanovic (Jira)]

[ 
https://issues.apache.org/jira/browse/CSV-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17652083#comment-17652083
 ] 

Damjan Jovanovic commented on CSV-141:
--

[~nhatminh12369]  "But if I open the file on Microsoft Excel, or using OpenCSV 
to parse lines 3 and 4, they work fine."

Yes, in Apache OpenOffice we found a number of CSV files that open in Excel but 
not in OpenOffice, and eventually I patched OpenOffice to open them too. We 
should get commons-csv to do the same, at least when using CSVFormat.EXCEL.

Particularly see the discussion on 
[https://bz.apache.org/ooo/show_bug.cgi?id=126805]

What Excel allows, and what is very surprising if you don't know about it, is 
this: extra text after the closing quote and before the field separator, is 
allowed, and gets appended verbatim to the field contents. Any quoting in this 
extra text is ignored.

For example:

"a" and b => a and b

"a" "b" => a "b"

"a" "b => a "b

That's the basic issue in lines 3-4 in the sample posted here.

> Handle malformed CSV files
> --
>
> Key: CSV-141
> URL: https://issues.apache.org/jira/browse/CSV-141
> Project: Commons CSV
>  Issue Type: Wish
>  Components: Parser
>Affects Versions: 1.0
>Reporter: Nguyen Minh
>Priority: Minor
> Fix For: 1.x
>
>
> My java application has to handle thousands of CSV files uploaded by the 
> client phones everyday. So, there some CSV files have the wrong format which 
> I'm not sure why.
> Here is my sample CSV. Microsoft Excel parses it correctly, but both Common 
> CSV and OpenCSV can't parse it. Open CSV can't parse line 2 (due to '\' 
> character) and Common CSV will crash on line 3 and 4:
> "1414770317901","android.widget.EditText","pass sem1 _84*|*","0","pass sem1 
> _8"
> "1414770318470","android.widget.EditText","pass sem1 _84:*|*","0","pass sem1 
> _84:\"
> "1414770318327","android.widget.EditText","pass sem1 
> "1414770318628","android.widget.EditText","pass sem1 _84*|*","0","pass sem1
> Line 3: java.io.IOException: (line 5) invalid char between encapsulated token 
> and delimiter
>   at org.apache.commons.csv.CSVParser$1.getNextRecord(CSVParser.java:398)
>   at org.apache.commons.csv.CSVParser$1.hasNext(CSVParser.java:407)
> Line 4: java.io.IOException: (startline 5) EOF reached before encapsulated 
> token finished
>   at org.apache.commons.csv.CSVParser$1.getNextRecord(CSVParser.java:398)
>   at org.apache.commons.csv.CSVParser$1.hasNext(CSVParser.java:407)



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (IMAGING-49) ExifRewriter.updateExifMetadataLossless corrupts maker notes

[Damjan Jovanovic (JIRA)]

[ 
https://issues.apache.org/jira/browse/IMAGING-49?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16245093#comment-16245093
 ] 

Damjan Jovanovic commented on IMAGING-49:
-

Please use the current snapshot. It should be fixed there.

> ExifRewriter.updateExifMetadataLossless corrupts maker notes
> 
>
> Key: IMAGING-49
> URL: https://issues.apache.org/jira/browse/IMAGING-49
> Project: Commons Imaging
>  Issue Type: Bug
> Environment: 0.97-incubator
>Reporter: Lulu winlumski
>Priority: Critical
> Fix For: 1.0
>
> Attachments: SanselanExifWriter.java, modified.jpg, original.jpg
>
>
> rewriter.updateExifMetadataLossless(jpeg, os, outputSet); 
> lead to loss of maker notes in the attached files.
> See attached files for details.
> $ exiftool -Makernotes:all original.jpg > original.txt
> $ exiftool -Makernotes:all modified.jpg > modified.txt
> $ diff -u original.txt modified.txt 
> --- original.txt  2009-10-21 02:14:11.0 +0200
> +++ modified.txt  2009-10-21 02:14:15.0 +0200
> @@ -1,66 +1,8 @@
> -Focal Type  : Zoom
> -Focal Plane X Size  : 5.84 mm
> -Focal Plane Y Size  : 4.39 mm
> -Canon Image Type: IMG:DIGITAL IXUS 60 JPEG
> -Canon Firmware Version  : Firmware Version 1.00
> +Canon Image Type: 
> +Canon Firmware Version  : 
>  File Number : 100-0877
>  Owner Name  : 
>  Canon Model ID  : PowerShot SD600 / Digital IXUS 60 / IXY 
> Digital 70
>  Thumbnail Image Valid Area  : 0 0 0 0
>  Date Stamp Mode : Off
> -My Color Mode   : Off
>  Firmware Revision   : 1.00 rev 1.00
> -Macro Mode  : Normal
> -Self Timer  : Off
> -Quality : Superfine
> -Canon Flash Mode: Red-eye reduction (Auto)
> -Continuous Drive: Single
> -Focus Mode  : Single
> -Record Mode : JPEG
> -Canon Image Size: Large
> -Easy Mode   : Full auto
> -Digital Zoom: None
> -Contrast: Normal
> -Saturation  : Normal
> -Sharpness   : 0
> -Camera ISO  : Auto
> -Metering Mode   : Evaluative
> -Focus Range : Auto
> -AF Point: Auto AF point selection
> -Canon Exposure Mode : Easy
> -Lens Type   : Unknown (-1)
> -Long Focal  : 17.4 mm
> -Short Focal : 5.8 mm
> -Focal Units : 1000
> -Max Aperture: 2.8
> -Min Aperture: 5.6
> -Flash Bits  : (none)
> -Focus Continuous: Single
> -AE Setting  : Normal AE
> -Zoom Source Width   : 2816
> -Zoom Target Width   : 2816
> -Spot Metering Mode  : Center
> -Manual Flash Output : n/a
> -Auto ISO: 148
> -Base ISO: 100
> -Measured EV : 4.19
> -Target Aperture : 2.8
> -Target Exposure Time: 1/60
> -Exposure Compensation   : 0
> -White Balance   : Auto
> -Slow Shutter: Off
> -Shot Number In Continuous Burst : 0
> -Optical Zoom Code   : 0
> -Flash Guide Number  : 0
> -Flash Exposure Compensation : 0
> -Auto Exposure Bracketing: Off
> -AEB Bracket Value   : 0
> -Control Mode: Camera Local Control
> -Focus Distance Upper: 2.56
> -Focus Distance Lower: 0
> -Bulb Duration   : 0
> -Camera Type : Compact
> -Auto Rotate : Rotate 90 CW
> -ND Filter   : Off
> -Self Timer 2: 0
> -Flash Output: 0
> This makes the library utterly useless for me. You can just as well use 
> MediaUtil which has a smaller footprint and a (somewhat) cleaner API.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (IMAGING-191) BinaryConstant implements Cloneable - why?

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IMAGING-191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic resolved IMAGING-191.
--
   Resolution: Fixed
Fix Version/s: 1.0

Thank you, it no longer does.

> BinaryConstant implements Cloneable - why?
> --
>
> Key: IMAGING-191
> URL: https://issues.apache.org/jira/browse/IMAGING-191
> Project: Commons Imaging
>  Issue Type: Bug
>Reporter: Sebb
> Fix For: 1.0
>
>
> BinaryConstant is an immutable class. 
> There seems absolutely no point in implementing Cloneable for it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IMAGING-187) Could not read block - when JPG file is saved from TIFF

[Damjan Jovanovic (JIRA)]

[ 
https://issues.apache.org/jira/browse/IMAGING-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15547048#comment-15547048
 ] 

Damjan Jovanovic commented on IMAGING-187:
--

The file contains a corrupt thumbnail. Reading the metadata attempts to read 
the thumbnail by default, causing the exception. It's possible to skip reading 
the thumbnail and avoid the exception:

Map params = new TreeMap<>();
params.put(ImagingConstants.PARAM_KEY_READ_THUMBNAILS, false);
JpegImageMetadata metadata = (JpegImageMetadata) 
Imaging.getMetadata(new File("IMG_000-tf.jpg"), params);


> Could not read block - when JPG file is saved from TIFF
> ---
>
> Key: IMAGING-187
> URL: https://issues.apache.org/jira/browse/IMAGING-187
> Project: Commons Imaging
>  Issue Type: Bug
>Affects Versions: 1.0
>Reporter: R.M.
> Attachments: IMG_000-tf.jpg
>
>
> I have got error
> java.io.IOException: Could not read block (block start: 399047, block length: 
> 6240, data length: 9926).
> when I try to read EXIF or IPTC metadata (Imaging.getMetadata(file);)
> At first the file was saved in TIFF format. Then it was open and saved to 
> final jpg format. This error I can see everytime, when I have any JPG saved 
> from TIFF.
> I tried to use PaintShopPro and painting in windows.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IMAGING-179) Adding a directory causes "APP1 Segment is too long"

[Damjan Jovanovic (JIRA)]

[ 
https://issues.apache.org/jira/browse/IMAGING-179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15469184#comment-15469184
 ] 

Damjan Jovanovic commented on IMAGING-179:
--

The way that lossless rewriting currently works is we blacklist every EXIF 
byte, and then traverse the directory structure, whitelisting bytes occupied by 
*known* tags. Every whitelisted byte can then be overwritten, since its 
contents are already known and can be rewritten.

Since images can have tags with unknown contents (such as this particular 
image's enormous "Maker Note" tag 927c using up 01008-35518) we can't whitelist 
any bytes that appear unused, as those tags can contain anything, including 
arbitrary numbers of recursive references to other directories and their tags, 
using up space elsewhere in the EXIF data, and can even be encrypted.

That only leaves growing the EXIF field, but this one is already using 65526 
bytes, leaving only another 9 bytes to use, which is not enough.

As a workaround you could try save space by deleting the thumbnail, or, if you 
don't care about unknown tags, use lossy rewriting instead (which can corrupt 
them).

We would have to parse the "Maker Note" to extract more space. This is 
manufacturer-specific :-/.

> Adding a directory causes "APP1 Segment is too long"
> 
>
> Key: IMAGING-179
> URL: https://issues.apache.org/jira/browse/IMAGING-179
> Project: Commons Imaging
>  Issue Type: Bug
>  Components: Format: JPEG
>Reporter: Simon Legner
> Attachments: 123.jpg
>
>
> SVN revision: 1696444
> The following snippet causes {{ExifRewriter$ExifOverflowException: APP1 
> Segment is too long: 65548}}
> {code:java}
> final File in = new File("123.jpg");
> final TiffImageMetadata exif = ((JpegImageMetadata) 
> Imaging.getMetadata(in)).getExif();
> final TiffOutputSet outputSet = exif.getOutputSet();
> outputSet.getOrCreateGPSDirectory().add(GpsTagConstants.GPS_TAG_GPS_IMG_DIRECTION,
>  RationalNumber.valueOf(123));
> new ExifRewriter().updateExifMetadataLossless(in, new 
> ByteArrayOutputStream(), outputSet);
> {code}
> When inspecting the EXIF data using {{jhead -exifmap 123.jpg}}, the header 
> reveals unfilled space between 47198 and 65526. Nevertheless, this space is 
> not used, but instead the GPS directory is being appended starting at offset 
> 65526.
> {code}
> Map: 8-00182: Directory
> Map: 00184-00202:   Data for tag 010f
> Map: 00204-00214:   Data for tag 0110
> Map: 00216-00224:   Data for tag 011a
> Map: 00224-00232:   Data for tag 011b
> Map: 00232-00242:   Data for tag 0131
> Map: 00244-00264:   Data for tag 0132
> Map: 00264-00280:   Data for tag 013e
> Map: 00280-00328:   Data for tag 013f
> Map: 00328-00352:   Data for tag 0211
> Map: 00352-00850: Directory
> Map: 00852-00860:   Data for tag 829a
> Map: 00860-00868:   Data for tag 829d
> Map: 00868-00888:   Data for tag 9003
> Map: 00888-00908:   Data for tag 9004
> Map: 00908-00916:   Data for tag 9102
> Map: 00916-00924:   Data for tag 9204
> Map: 00924-00932:   Data for tag 9205
> Map: 00932-00940:   Data for tag 920a
> Map: 01008-35518:   Data for tag 927c
> Map: 00940-00984:   Data for tag 9286
> Map: 35518-35548: Directory
> Map: 00984-00992:   Data for tag a302
> Map: 00992-01000:   Data for tag a404
> Map: 01000-01008:   Data for tag a500
> Map: 35568-35658: Directory
> Map: 35660-35668:   Data for tag 011a
> Map: 35668-35676:   Data for tag 011b
> Map: 35676-47197: Thumbnail
> Map: 65526- End of exif
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (IMAGING-125) Add missing Exif tags definition into ExifTagConstants

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IMAGING-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic resolved IMAGING-125.
--
Resolution: Not A Problem

"Copyright" and "Orientation" are root directory tags (TiffTagConstants).
"UniqueCameraModel" is in DngTagConstants.

> Add missing Exif tags definition into ExifTagConstants
> --
>
> Key: IMAGING-125
> URL: https://issues.apache.org/jira/browse/IMAGING-125
> Project: Commons Imaging
>  Issue Type: Improvement
>  Components: Format: TIFF
>Affects Versions: 1.0
>Reporter: Olivier Voortman
>Priority: Minor
> Fix For: Patch Needed
>
>
> There are some missing Tags in ExifTagConstants.
> Like "Copyright", "Orientation" or "UniqueCameraModel".
> See complete list on : http://www.exiv2.org/tags.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (IMAGING-181) EXIF lens metadata tags missing in Commons Imaging but recognized in exiftool

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IMAGING-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic resolved IMAGING-181.
--
Resolution: Fixed

Fixed by commit 1759477:

Add missing EXIF tags for some lens and camera metadata.

Resolving FIXED.

> EXIF lens metadata tags missing in Commons Imaging but recognized in exiftool
> -
>
> Key: IMAGING-181
> URL: https://issues.apache.org/jira/browse/IMAGING-181
> Project: Commons Imaging
>  Issue Type: Bug
>Reporter: Saurabh Khanduja
>Priority: Minor
> Fix For: 1.0
>
>
> Hi,
>  I am new to commons-imaging, so forgive any mistakes.
> I was checking exif metadata in pics captured from Iphone and noticed few 
> metadata of Unknown Type tag.
> FileName: IPhone_6_IMG_4174.JPG
> Metadata: 
> Make  : 'Apple'
> Model : 'iPhone 6'
> Orientation   : 6
> XResolution   : 72
> YResolution   : 72
> ResolutionUnit: 2
> Software  : '9.2.1'
> DateTime  : '2016:03:25 12:01:04'
> YCbCrPositioning  : 1
> ExifOffset: 204
> GPSInfo   : 1608
> ExposureTime  : 1/33 (0.03)
> FNumber   : 11/5 (2.2)
> ExposureProgram   : 2
> PhotographicSensitivity   : 250
> ExifVersion   : 48, 50, 50, 49
> DateTimeOriginal  : '2016:03:25 12:01:04'
> DateTimeDigitized : '2016:03:25 12:01:04'
> ComponentsConfiguration   : 1, 2, 3, 0
> ShutterSpeedValue : 253/50 (5.06)
> ApertureValue : 7983/3509 (2.275)
> BrightnessValue   : 4064/2511 (1.618)
> ExposureCompensation  : 0
> MeteringMode  : 5
> Flash : 24
> FocalLength   : 83/20 (4.15)
> SubjectArea   : 1526, 1140, 731, 729
> MakerNote : 65, 112, 112, 108, 101, 32, 105, 79, 83, 0, 0, 1, 77, 77, 0, 
> 11, 0, 1, 0, 9, 0, 0, 0, 1, 0, 0, 0, 4, 0, 2, 0, 7, 0, 0, 2, 46, 0, 0, 0, 
> -104, 0, 3, 0, 7, 0, 0, 0, 104, 0, 0, 2... (838)
> SubSecTimeOriginal: '081'
> SubSecTimeDigitized   : '081'
> FlashpixVersion   : 48, 49, 48, 48
> ColorSpace: 1
> ExifImageWidth: 3264
> ExifImageLength   : 2448
> SensingMethod : 2
> SceneType : 1
> ExposureMode  : 0
> WhiteBalance  : 0
> FocalLengthIn35mmFormat   : 29
> SceneCaptureType  : 0
>   Unknown Tag (0xa432): 83/20 (4.15), 83/20 (4.15), 11/5 (2.2), 11/5 
> (2.2)
>   Unknown Tag (0xa433): 'Apple'
>   Unknown Tag (0xa434): 'iPhone 6 back camera 4.15mm f/2.2'
> GPSLatitudeRef: 'N'
> GPSLatitude   : 28, 28, 1298/100 (12.98)
> GPSLongitudeRef   : 'E'
> GPSLongitude  : 77, 4, 1947/100 (19.47)
> GPSAltitudeRef: 0
> GPSAltitude   : 73641/319 (230.85)
> GPSTimeStamp  : 6, 31, 191/100 (1.91)
> GPSSpeedRef   : 'K'
> GPSSpeed  : 0
> GPSImgDirectionRef: 'T'
> GPSImgDirection   : 6757/212 (31.873)
> GPSDestBearingRef : 'T'
> GPSDestBearing: 6757/212 (31.873)
> GPSDateStamp  : '2016:03:25'
> Unknown Tag (0x1f): 65
> Compression   : 6
> XResolution   : 72
> YResolution   : 72
> ResolutionUnit: 2
> JpgFromRawStart   : 2012
> JpgFromRawLength  : 9563
> Running exiftool on same image got me, these tags. Note that Lens Info value 
> is "4.15mm f/2.2" but corresponding value above was "Unknown Tag (0xa432) 
>: 83/20 (4.15), 83/20 (4.15), 11/5 (2.2), 11/5 (2.2)".
> Lens Info   : 4.15mm f/2.2
> Lens Make   : Apple
> Lens Model  : iPhone 6 back camera 4.15mm f/2.2



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (IMAGING-181) EXIF lens metadata tags missing in Commons Imaging but recognized in exiftool

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IMAGING-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic updated IMAGING-181:
-
Summary: EXIF lens metadata tags missing in Commons Imaging but recognized 
in exiftool  (was: Unknown Metadata Tags in Commons Imaging but recognized in 
exiftool)

> EXIF lens metadata tags missing in Commons Imaging but recognized in exiftool
> -
>
> Key: IMAGING-181
> URL: https://issues.apache.org/jira/browse/IMAGING-181
> Project: Commons Imaging
>  Issue Type: Bug
>Reporter: Saurabh Khanduja
>Priority: Minor
> Fix For: 1.0
>
>
> Hi,
>  I am new to commons-imaging, so forgive any mistakes.
> I was checking exif metadata in pics captured from Iphone and noticed few 
> metadata of Unknown Type tag.
> FileName: IPhone_6_IMG_4174.JPG
> Metadata: 
> Make  : 'Apple'
> Model : 'iPhone 6'
> Orientation   : 6
> XResolution   : 72
> YResolution   : 72
> ResolutionUnit: 2
> Software  : '9.2.1'
> DateTime  : '2016:03:25 12:01:04'
> YCbCrPositioning  : 1
> ExifOffset: 204
> GPSInfo   : 1608
> ExposureTime  : 1/33 (0.03)
> FNumber   : 11/5 (2.2)
> ExposureProgram   : 2
> PhotographicSensitivity   : 250
> ExifVersion   : 48, 50, 50, 49
> DateTimeOriginal  : '2016:03:25 12:01:04'
> DateTimeDigitized : '2016:03:25 12:01:04'
> ComponentsConfiguration   : 1, 2, 3, 0
> ShutterSpeedValue : 253/50 (5.06)
> ApertureValue : 7983/3509 (2.275)
> BrightnessValue   : 4064/2511 (1.618)
> ExposureCompensation  : 0
> MeteringMode  : 5
> Flash : 24
> FocalLength   : 83/20 (4.15)
> SubjectArea   : 1526, 1140, 731, 729
> MakerNote : 65, 112, 112, 108, 101, 32, 105, 79, 83, 0, 0, 1, 77, 77, 0, 
> 11, 0, 1, 0, 9, 0, 0, 0, 1, 0, 0, 0, 4, 0, 2, 0, 7, 0, 0, 2, 46, 0, 0, 0, 
> -104, 0, 3, 0, 7, 0, 0, 0, 104, 0, 0, 2... (838)
> SubSecTimeOriginal: '081'
> SubSecTimeDigitized   : '081'
> FlashpixVersion   : 48, 49, 48, 48
> ColorSpace: 1
> ExifImageWidth: 3264
> ExifImageLength   : 2448
> SensingMethod : 2
> SceneType : 1
> ExposureMode  : 0
> WhiteBalance  : 0
> FocalLengthIn35mmFormat   : 29
> SceneCaptureType  : 0
>   Unknown Tag (0xa432): 83/20 (4.15), 83/20 (4.15), 11/5 (2.2), 11/5 
> (2.2)
>   Unknown Tag (0xa433): 'Apple'
>   Unknown Tag (0xa434): 'iPhone 6 back camera 4.15mm f/2.2'
> GPSLatitudeRef: 'N'
> GPSLatitude   : 28, 28, 1298/100 (12.98)
> GPSLongitudeRef   : 'E'
> GPSLongitude  : 77, 4, 1947/100 (19.47)
> GPSAltitudeRef: 0
> GPSAltitude   : 73641/319 (230.85)
> GPSTimeStamp  : 6, 31, 191/100 (1.91)
> GPSSpeedRef   : 'K'
> GPSSpeed  : 0
> GPSImgDirectionRef: 'T'
> GPSImgDirection   : 6757/212 (31.873)
> GPSDestBearingRef : 'T'
> GPSDestBearing: 6757/212 (31.873)
> GPSDateStamp  : '2016:03:25'
> Unknown Tag (0x1f): 65
> Compression   : 6
> XResolution   : 72
> YResolution   : 72
> ResolutionUnit: 2
> JpgFromRawStart   : 2012
> JpgFromRawLength  : 9563
> Running exiftool on same image got me, these tags. Note that Lens Info value 
> is "4.15mm f/2.2" but corresponding value above was "Unknown Tag (0xa432) 
>: 83/20 (4.15), 83/20 (4.15), 11/5 (2.2), 11/5 (2.2)".
> Lens Info   : 4.15mm f/2.2
> Lens Make   : Apple
> Lens Model  : iPhone 6 back camera 4.15mm f/2.2



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (IMAGING-172) Microsoft tags are not seen in MS Windows Properties/Details dialog

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IMAGING-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic resolved IMAGING-172.
--
   Resolution: Fixed
Fix Version/s: 1.0

Fixed by commit 1759460:

Null-terminate the XpString tag, and store it in the root directory where
Windows looks for it instead of the EXIF directory. Also deletes the 
IPTC and XMP metadata which contains conflicting tags which Windows
uses instead when present.

Resolving FIXED.

> Microsoft tags are not seen in MS Windows Properties/Details dialog
> ---
>
> Key: IMAGING-172
> URL: https://issues.apache.org/jira/browse/IMAGING-172
> Project: Commons Imaging
>  Issue Type: Bug
>  Components: Format: JPEG
>Reporter: Alexander Radzin
> Fix For: 1.0
>
> Attachments: file-props-dialog.png
>
>
> Here is the scenario.
> 1. Add the following lines to {{MicrosoftTagTest.testRewrite()}}. 
> {code}
> OutputStream out = new FileOutputStream(new File("/temp/mytest.jpg"));
> out.write(baos.toByteArray());
> out.flush();
> out.close();
> {code}
> 2. No run the test. 
> 3. Right click on file in the file explorer, open properties dialog and 
> choose "details tab".
> No-one of 4 expected properties (author, comment, subject, title) cannot be 
> found. Title and subject look corrupted. All this happens despite of the test 
> succeeds. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (COMPRESS-327) Support in-memory processing for ZipFile

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COMPRESS-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic updated COMPRESS-327:
--
Attachment: (was: seekable-input-stream.txt)

> Support in-memory processing for ZipFile
> 
>
> Key: COMPRESS-327
> URL: https://issues.apache.org/jira/browse/COMPRESS-327
> Project: Commons Compress
>  Issue Type: New Feature
>Reporter: Brett Kail
>Priority: Minor
> Attachments: 
> 0001-Add-a-SeekableInputStream-and-some-subclasses-that-Z.patch
>
>
> ZipFile (and SevenZFile) currently require a File argument, but it would be 
> nice to support in-memory byte buffers rather than requiring temp files.  
> Perhaps create a new SeekableInputStream class (or SeekableDataInput 
> interface) and add corresponding constructors.
> For convenience, perhaps also add a utility class that wraps a ByteBuffer 
> and/or byte[] and implements the new interface.
> (The sevenz package appears to have a similar limitation, so it might make 
> sense to add the support there at the same time, but I personally don't have 
> a need for that.)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (COMPRESS-327) Support in-memory processing for ZipFile

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COMPRESS-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic updated COMPRESS-327:
--
Attachment: 0001-Add-a-SeekableInputStream-and-some-subclasses-that-Z.patch

Sorry. Here is the patch with all the files.

> Support in-memory processing for ZipFile
> 
>
> Key: COMPRESS-327
> URL: https://issues.apache.org/jira/browse/COMPRESS-327
> Project: Commons Compress
>  Issue Type: New Feature
>Reporter: Brett Kail
>Priority: Minor
> Attachments: 
> 0001-Add-a-SeekableInputStream-and-some-subclasses-that-Z.patch, 
> seekable-input-stream.txt
>
>
> ZipFile (and SevenZFile) currently require a File argument, but it would be 
> nice to support in-memory byte buffers rather than requiring temp files.  
> Perhaps create a new SeekableInputStream class (or SeekableDataInput 
> interface) and add corresponding constructors.
> For convenience, perhaps also add a utility class that wraps a ByteBuffer 
> and/or byte[] and implements the new interface.
> (The sevenz package appears to have a similar limitation, so it might make 
> sense to add the support there at the same time, but I personally don't have 
> a need for that.)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (COMPRESS-327) Support in-memory processing for ZipFile

[Damjan Jovanovic (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15008293#comment-15008293
 ] 

Damjan Jovanovic commented on COMPRESS-327:
---

It was a 30 September 2015 email entitled "[COMPRESS] generalize 
RandomAccessFile in ZipFile and SevenZFile", link here:
http://www.mail-archive.com/dev@commons.apache.org/msg49795.html

I found the names of methods in 2.x were unintuitive, and how it's supposed to 
be used is confusing. Is there any design notes or documentation?


> Support in-memory processing for ZipFile
> 
>
> Key: COMPRESS-327
> URL: https://issues.apache.org/jira/browse/COMPRESS-327
> Project: Commons Compress
>  Issue Type: New Feature
>Reporter: Brett Kail
>Priority: Minor
> Attachments: seekable-input-stream.txt
>
>
> ZipFile (and SevenZFile) currently require a File argument, but it would be 
> nice to support in-memory byte buffers rather than requiring temp files.  
> Perhaps create a new SeekableInputStream class (or SeekableDataInput 
> interface) and add corresponding constructors.
> For convenience, perhaps also add a utility class that wraps a ByteBuffer 
> and/or byte[] and implements the new interface.
> (The sevenz package appears to have a similar limitation, so it might make 
> sense to add the support there at the same time, but I personally don't have 
> a need for that.)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (COMPRESS-327) Support in-memory processing for ZipFile

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COMPRESS-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic updated COMPRESS-327:
--
Attachment: seekable-input-stream.txt

I wrote a patch precisely for this a few weeks ago (attached), but got no 
feedback when I emailed it to the dev mailing list, so have been reluctant to 
commit it.

Also the next major version of compress is supposed to support seekable 
streams, but development on it seems to have been abandoned?


> Support in-memory processing for ZipFile
> 
>
> Key: COMPRESS-327
> URL: https://issues.apache.org/jira/browse/COMPRESS-327
> Project: Commons Compress
>  Issue Type: New Feature
>Reporter: Brett Kail
>Priority: Minor
> Attachments: seekable-input-stream.txt
>
>
> ZipFile (and SevenZFile) currently require a File argument, but it would be 
> nice to support in-memory byte buffers rather than requiring temp files.  
> Perhaps create a new SeekableInputStream class (or SeekableDataInput 
> interface) and add corresponding constructors.
> For convenience, perhaps also add a utility class that wraps a ByteBuffer 
> and/or byte[] and implements the new interface.
> (The sevenz package appears to have a similar limitation, so it might make 
> sense to add the support there at the same time, but I personally don't have 
> a need for that.)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IMAGING-170) TIFF image gains significant size using TiffImageWriterLossless

[Damjan Jovanovic (JIRA)]

[ 
https://issues.apache.org/jira/browse/IMAGING-170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14802873#comment-14802873
 ] 

Damjan Jovanovic commented on IMAGING-170:
--

I am pretty sure you are using the API incorrectly. You have to use 
ExifRewriter and it's updateExifMetadataLossless() method to modify metadata 
while leaving the image alone. See 
https://svn.apache.org/repos/asf/commons/proper/imaging/trunk/src/test/java/org/apache/commons/imaging/examples/WriteExifMetadataExample.java
 for details.


> TIFF image gains significant size using TiffImageWriterLossless
> ---
>
> Key: IMAGING-170
> URL: https://issues.apache.org/jira/browse/IMAGING-170
> Project: Commons Imaging
>  Issue Type: Bug
>  Components: Format: TIFF
>Affects Versions: 1.0
> Environment: System: Fedora release 21, kernel version: 
> 3.18.7-200.fc21.x86_64, JAVA: openjdk version "1.8.0_31", IDE: Eclipse Kepler 
> 2, Build id: 20140224-0627
>Reporter: Remigiusz Malessa
>Priority: Minor
> Attachments: kwf00346.tif
>
>
> Good afternoon, 
> I am posting an issue report as suggested by mr Benedikt Ritter. It's my 
> first issue report and I've just recently started using the Commons Imaging,  
> so please go easy on me. 
> 
> Using Commons Imaging I am reading a Tiff image (will attempt to attach it to 
> this ticket), then I remove a tag (Focal Plane Resolution Unit) and then I 
> save the new TiffOutputSet to the system using TiffImageWriterLossless.
> The original image is 15MB, the new image (with the Tag removed) is 28MB.
> Here's how I do it:
> {code:title=RemoveTag.java|borderStyle=solid}
> import java.awt.image.BufferedImage;
> import java.io.File;
> import java.io.FileOutputStream;
> import java.io.IOException;
> import java.io.OutputStream;
> import java.util.HashMap;
> import java.util.List;
> import java.util.Map;
> import org.apache.camel.Exchange;
> import org.apache.commons.imaging.ImageFormats;
> import org.apache.commons.imaging.ImageReadException;
> import org.apache.commons.imaging.ImageWriteException;
> import org.apache.commons.imaging.Imaging;
> import org.apache.commons.imaging.common.ImageMetadata;
> import org.apache.commons.imaging.formats.tiff.TiffField;
> import org.apache.commons.imaging.formats.tiff.TiffImageMetadata;
> import org.apache.commons.imaging.formats.tiff.write.TiffImageWriterLossless;
> import org.apache.commons.imaging.formats.tiff.write.TiffOutputDirectory;
> import org.apache.commons.imaging.formats.tiff.write.TiffOutputSet;
> File tInputFile = new File("/home/rem/TEMP/tags.original.tif");
> File toutputFile = new File("/home/rem/TEMP/tags.new.tif");
> final BufferedImage image = Imaging.getBufferedImage(tInputFile);
> ImageMetadata tMetadata = Imaging.getMetadata(tInputFile);
> TiffImageMetadata imageMetadata = (TiffImageMetadata) tMetadata;
> outputSet = imageMetadata.getOutputSet();
> TiffOutputDirectory exifDirectory = outputSet.getExifDirectory(); 
> exifDirectory.removeField(41488);
> ImageFormats format = ImageFormats.TIFF;
> Map params = new HashMap();
> BufferedImage image = Imaging.getBufferedImage(tInputFile);
> byte[] bytes = Imaging.writeImageToBytes(image, format, params);
> TiffImageWriterLossless writerLossLess = new TiffImageWriterLossless(bytes);
> writerLossLess.write(os, outputSet);
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (COMPRESS-300) LZWInputStream has mutable protected fields; these should be accessed via getter/setter and made private

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COMPRESS-300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic updated COMPRESS-300:
--
Attachment: imaging-compress-lzw.patch

Uncommitted patch I made to commons imaging (older version, might not apply 
now). You can see what bits of compress are used. It might be possible to 
simplify the patch further.

 LZWInputStream has mutable protected fields; these should be accessed via 
 getter/setter and made private
 

 Key: COMPRESS-300
 URL: https://issues.apache.org/jira/browse/COMPRESS-300
 Project: Commons Compress
  Issue Type: Bug
Reporter: Sebb
 Attachments: COMPRESS-300-alternative.patch, COMPRESS-300.patch, 
 imaging-compress-lzw.patch


 As per the discussion on the dev list, the class LZWInputStream has some 
 non-private mutable fields.
 These should be accessed via getters/setters only (data encapsulation).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IMAGING-126) TIFF and PNG images should not be bigger than the ones created by java ImageIO

[Damjan Jovanovic (JIRA)]

[ 
https://issues.apache.org/jira/browse/IMAGING-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14260864#comment-14260864
 ] 

Damjan Jovanovic commented on IMAGING-126:
--

Guys I've gone further than that: I even have a patch to Imaging which 
implements LZW decompression using the classes in Compress, and copies those 
classes into Imaging's JAR using maven-shade-plugin to avoid a run-time 
dependency. It passed all the tests, and was even somewhat faster than 
Imaging's LZW in my preliminary benchmarks - can't remember by how much though. 
It's not committed yet because I wasn't sure if Imaging could/should depend on 
a SNAPSHOT version of Compress, and there still hasn't been any new releases of 
Compress since before my LZW changes to it were committed.


 TIFF and PNG images should not be bigger than the ones created by java ImageIO
 --

 Key: IMAGING-126
 URL: https://issues.apache.org/jira/browse/IMAGING-126
 Project: Commons Imaging
  Issue Type: Improvement
  Components: Format: PNG, Format: TIFF
Affects Versions: 1.0
 Environment: W7
Reporter: Tilman Hausherr
Priority: Minor
 Fix For: Discussion

 Attachments: Imaging_126_patch_1.patch, pdfbox-1870-devicen3-01.png, 
 pdfbox-1870-devicen3-01.tif, pdfbox-1870-devicen3.pdf-1.png, 
 pdfbox-1870-devicen3.pdf-1.tif


 I tried to use Apache Imaging for the PDFBOX project (PDFBOX-1734) because of 
 problems with setting the tiff resolution in java imageio.
 While the code is pretty nice, I found that the generated images are 
 sometimes much bigger in size than the ones generated by java imageio.
 Example:
 pdfbox-1870-devicen3-01.png 50 KB (imageio)
 pdfbox-1870-devicen3.pdf-1.png 70 KB (imaging)
 pdfbox-1870-devicen3-01.tif 401 KB (imageio)
 pdfbox-1870-devicen3.pdf-1.tif 1063 KB (imaging)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CSV-140) QuoteMode.NON_NUMERIC doesn't work with CSVPrinter.printRecords(ResultSet)

[Damjan Jovanovic (JIRA)]

[ 
https://issues.apache.org/jira/browse/CSV-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14203950#comment-14203950
 ] 

Damjan Jovanovic commented on CSV-140:
--

Well CSVPrinter.printRecords(final ResultSet resultSet) calls 
CSVPrinter.print(final Object value) just like every other CSVPrinter printing 
method, so exactly the same thing will happen that happens otherwise in 
QuoteMode.NON_NUMERIC with comma as the locale decimal separator. If numbers 
should be quoted when their decimal separator matches the field separator, 
that's QuoteMode.MINIMAL, which will check the field's contents and quote it if 
necessary. Whether QuoteMode.NON_NUMERIC should be doing the same, is a 
separate question.


 QuoteMode.NON_NUMERIC doesn't work with CSVPrinter.printRecords(ResultSet)
 --

 Key: CSV-140
 URL: https://issues.apache.org/jira/browse/CSV-140
 Project: Commons CSV
  Issue Type: Bug
  Components: Printer
Affects Versions: 1.0
Reporter: Damjan Jovanovic
Priority: Minor
  Labels: patch
 Attachments: commons-csv-getobject.patch

   Original Estimate: 1m
  Remaining Estimate: 1m

  CSVPrinter.printRecords(final ResultSet resultSet) retrieves all fields from 
 the ResultSet using ResultSet.getString(), which makes QuoteMode.NON_NUMERIC 
 unnecessarily quote numbers.
 ResultSet.getObject() could be used instead. Any reason why it wasn't?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CSV-140) QuoteMode.NON_NUMERIC doesn't work with CSVPrinter.printRecords(ResultSet)

[Damjan Jovanovic (JIRA)]

Damjan Jovanovic created CSV-140:


 Summary: QuoteMode.NON_NUMERIC doesn't work with 
CSVPrinter.printRecords(ResultSet)
 Key: CSV-140
 URL: https://issues.apache.org/jira/browse/CSV-140
 Project: Commons CSV
  Issue Type: Bug
  Components: Printer
Affects Versions: 1.0
Reporter: Damjan Jovanovic
Priority: Minor


 CSVPrinter.printRecords(final ResultSet resultSet) retrieves all fields from 
the ResultSet using ResultSet.getString(), which makes QuoteMode.NON_NUMERIC 
unnecessarily quote numbers.

ResultSet.getObject() could be used instead. Any reason why it wasn't?




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CSV-140) QuoteMode.NON_NUMERIC doesn't work with CSVPrinter.printRecords(ResultSet)

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CSV-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic updated CSV-140:
-
Attachment: commons-csv-getobject.patch

Patch. Trivial. I can apply it, it's just here for feedback.


 QuoteMode.NON_NUMERIC doesn't work with CSVPrinter.printRecords(ResultSet)
 --

 Key: CSV-140
 URL: https://issues.apache.org/jira/browse/CSV-140
 Project: Commons CSV
  Issue Type: Bug
  Components: Printer
Affects Versions: 1.0
Reporter: Damjan Jovanovic
Priority: Minor
 Attachments: commons-csv-getobject.patch

   Original Estimate: 1m
  Remaining Estimate: 1m

  CSVPrinter.printRecords(final ResultSet resultSet) retrieves all fields from 
 the ResultSet using ResultSet.getString(), which makes QuoteMode.NON_NUMERIC 
 unnecessarily quote numbers.
 ResultSet.getObject() could be used instead. Any reason why it wasn't?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (IMAGING-131) PngImageParser#getBufferedImage() doesn't respect ImageParser specification

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IMAGING-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic resolved IMAGING-131.
--
   Resolution: Fixed
Fix Version/s: 1.0

That only affects calls to PngImageParser.getBufferedImage() directly, calls 
via Imaging.getBufferedImage() always create a new params when it's null. But 
I've fixed it anyway, resolving.

 PngImageParser#getBufferedImage() doesn't respect ImageParser specification 
 

 Key: IMAGING-131
 URL: https://issues.apache.org/jira/browse/IMAGING-131
 Project: Commons Imaging
  Issue Type: Bug
  Components: Format: PNG
Affects Versions: 1.0
Reporter: fasar
Priority: Critical
  Labels: easyfix
 Fix For: 1.0

   Original Estimate: 1h
  Remaining Estimate: 1h

 ImageParser#getBufferedImage() specification tell in documentation :
 {code:title=ImageParser#getBufferedImage()|borderStyle=solid}
 /**
...
  * @param params Optional instructions for special-handling or
  *   interpretation of the input data (null objects are 
 permitted and
  *   must be supported by implementations).
   ...
  **/
 {code}
 Implementation PngImageParser#getBufferedImage() does note respect this 
 documentation. Indeed, first line of the function is : 
 {code:title=PngImageParser#getBufferedImage() line 637 |borderStyle=solid}
 if (params.containsKey(PARAM_KEY_VERBOSE)) {
 params.remove(PARAM_KEY_VERBOSE);
 }
 {code}
 I suppose It would be 
 {code:title=FIX PngImageParser#getBufferedImage()|borderStyle=solid}
 if (params!=null  params.containsKey(PARAM_KEY_VERBOSE)) {
 params.remove(PARAM_KEY_VERBOSE);
 }
 {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (IMAGING-140) ExifReWriter always writes EXIF segment before JFIF segment

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IMAGING-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic resolved IMAGING-140.
--
   Resolution: Fixed
Fix Version/s: 1.0

Thank you for your patch. Applied it so resolving fixed.

 ExifReWriter always writes EXIF segment before JFIF segment
 ---

 Key: IMAGING-140
 URL: https://issues.apache.org/jira/browse/IMAGING-140
 Project: Commons Imaging
  Issue Type: Bug
  Components: Format: JPEG
Affects Versions: 1.x, 0.97, 0.94-incubator
 Environment: All
Reporter: Gavin Shiels
  Labels: EXIF
 Fix For: 1.0

 Attachments: ExifRewriter.java.patch


 ExifRewriter.writeSegmentsReplacingExif () always writes the EXIF segment as 
 the first segment written to the output stream even when there is JFIF 
 segment present.
 The code checks for the existence of the JFIF segment and it looks like the 
 intention was then to insert the EXIF segment at index 1 but it is instead 
 always inserted at index 0, the variable 'index' is not used after being set 
 to 1. 
 'index' should be passed as the first parameter to the segments.add() call.
 {code:title=org.apache.sanselan.formats.jpeg.exifRewrite.ExifRewriter.java|borderStyle=solid}
 int index = 0;
 JFIFPieceSegment firstSegment = (JFIFPieceSegment) segments.get(index);
 if (firstSegment.marker == JFIFMarker)
 index = 1;
 
 segments.add(0, new JFIFPieceSegmentExif(JPEG_APP1_Marker,
 markerBytes, markerLengthBytes, newBytes));
 {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (IMAGING-137) Can not set EXIF_TAG_EXIF_VERSION tag

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IMAGING-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic resolved IMAGING-137.
--
   Resolution: Fixed
Fix Version/s: 1.0

exifDirectory.add(ExifTagConstants.EXIF_TAG_EXIF_VERSION, 0, 2, 2, 1);
should work now. Resolving fixed.

 Can not set EXIF_TAG_EXIF_VERSION tag
 -

 Key: IMAGING-137
 URL: https://issues.apache.org/jira/browse/IMAGING-137
 Project: Commons Imaging
  Issue Type: Bug
  Components: Format: TIFF
Affects Versions: 1.0
 Environment: java 1.7.0_55  Commons-Imaging (build date is 3/25/2014)
Reporter: Ted Troccola
  Labels: features
 Fix For: 1.0


 I am unable to set EXIF_TAG_EXIF_VERSION.
 I am using Maven with the following settings (the build date is 3/25/2014):
 dependency
   groupIdorg.apache.commons/groupId
   artifactIdcommons-imaging/artifactId
   version1.0-SNAPSHOT/version
   scopecompile/scope
/dependency
repository
   idapache.snapshots/id
   urlhttp://repository.apache.org/snapshots//url
/repository
 I get exceptions because it expects only 1 byte.
 If I debug and inspect the metadata for a JPG file with proper Exif data, it 
 shows 4 bytes (48,50,50,48). This is consistent with this reference
 Here is my code. To run, change the file names and run.
 import java.io.BufferedOutputStream;
 import java.io.File;
 import java.io.FileOutputStream;
 import java.io.IOException;
 import java.io.OutputStream;
 import java.util.List;
 import org.apache.commons.imaging.ImageReadException;
 import org.apache.commons.imaging.ImageWriteException;
 import org.apache.commons.imaging.Imaging;
 import org.apache.commons.imaging.common.IImageMetadata;
 import org.apache.commons.imaging.common.IImageMetadata.IImageMetadataItem;
 import org.apache.commons.imaging.formats.jpeg.JpegImageMetadata;
 import org.apache.commons.imaging.formats.jpeg.exif.ExifRewriter;
 import org.apache.commons.imaging.formats.tiff.TiffImageMetadata;
 import org.apache.commons.imaging.formats.tiff.constants.ExifTagConstants;
 import org.apache.commons.imaging.formats.tiff.write.TiffOutputDirectory;
 import org.apache.commons.imaging.formats.tiff.write.TiffOutputSet;
 public class ExifExample
 {
 public static void logImageMetaData(final File jpgImageFile) throws 
 ImageReadException, IOException
 {
 // Get all metadata stored in Exif format (i.e., from JPEG or TIFF).
 final IImageMetadata metadata = Imaging.getMetadata(jpgImageFile);
 if (metadata instanceof JpegImageMetadata)
 {
 final JpegImageMetadata jpegMetadata = (JpegImageMetadata) 
 metadata;
 final ListIImageMetadataItem items = jpegMetadata.getItems();
 for (int i = 0; i  items.size(); i++)
 {
 final IImageMetadataItem item = items.get(i);
 System.out.println(
 + item:  + item);
 }
 }
 }
 private static TiffOutputSet getMetadata(final File jpegImageFile) throws 
 ImageReadException, IOException, ImageWriteException
 {
 TiffOutputSet outputSet = null;
 // metadata might be null if no metadata is found.
 final IImageMetadata metadata = Imaging.getMetadata(jpegImageFile);
 final JpegImageMetadata jpegMetadata = (JpegImageMetadata) metadata;
 if (null != jpegMetadata)
 {
 // Exif might be null if no Exif metadata is found.
 final TiffImageMetadata exif = jpegMetadata.getExif();
 if (null != exif)
 {
 /* TiffImageMetadata class is immutable (read-only).
  * TiffOutputSet class represents the Exif data to write.
  *
  * Usually, we want to update existing Exif metadata by 
 changing
  * the values of a few fields, or adding a field.
  * 
  * In these cases, it is easiest to use getOutputSet() to
  * start with a copy of the fields read from the image.
  */
 outputSet = exif.getOutputSet();
 }
 }
 return outputSet;
 }
 public static void writeExifData(File jpegImageFile, File destImageFile) 
 throws IOException, ImageReadException, ImageWriteException
 {
 try (OutputStream os = new BufferedOutputStream(new 
 FileOutputStream(destImageFile)))
 {
 TiffOutputSet outputSet = new TiffOutputSet();
 // Create the Exif directory tags
 final TiffOutputDirectory exifDirectory = 
 outputSet.getOrCreateExifDirectory();
 /*
  * TODO: How do you set ExifVersion
  * 
  * Exception in thread main 
 

[jira] [Commented] (IMAGING-139) Invalid DPI value

[Damjan Jovanovic (JIRA)]

[ 
https://issues.apache.org/jira/browse/IMAGING-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14176246#comment-14176246
 ] 

Damjan Jovanovic commented on IMAGING-139:
--

with exiftool -a -g -u /path/to/250dpi.jpg I get:

 JFIF 
JFIF Version: 1.01
Resolution Unit : None
X Resolution: 1
Y Resolution: 1

so that 250 must be some kind of default in the other application?

And we should really deal with Resolution Unit = None properly, by returning 
PixelDensity instead of inches/etc.

 Invalid DPI value 
 --

 Key: IMAGING-139
 URL: https://issues.apache.org/jira/browse/IMAGING-139
 Project: Commons Imaging
  Issue Type: Bug
  Components: Format: JPEG
Affects Versions: 0.97
Reporter: prabu
 Attachments: 250dpi.jpg


 I have following code in my java program
 final String IMAGE_PATH = c:\\test\\250dpi.jpg;
 byte imageBytes[] = readImageBytes(IMAGE_PATH);
 final ImageInfo imageInfo = Sanselan.getImageInfo(imageBytes);
 final int physicalWidthDpi = imageInfo.getPhysicalWidthDpi();
 final int physicalHeightDpi = imageInfo.getPhysicalHeightDpi();
 System.out.println(physicalWidthDpi:+physicalWidthDpi);
 When i right click image it showing 250 DPI value,but above program returning 
 DPI value -1.
 Not sure why?Can u please help how to get image correct DPI value.
 Attached image for your reference.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IMAGING-126) TIFF and PNG images should not be bigger than the ones created by java ImageIO

[Damjan Jovanovic (JIRA)]

[ 
https://issues.apache.org/jira/browse/IMAGING-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13914503#comment-13914503
 ] 

Damjan Jovanovic commented on IMAGING-126:
--

I am surprised you guys didn't see we have an LZW implementation in Commons 
Compress, which does .Z files and one of the ZIP compression methods. Please 
see COMPRESS-243 where I developed it and compared it to the algorithm done by 
Commons Imaging. It's also much faster.


 TIFF and PNG images should not be bigger than the ones created by java ImageIO
 --

 Key: IMAGING-126
 URL: https://issues.apache.org/jira/browse/IMAGING-126
 Project: Commons Imaging
  Issue Type: Improvement
  Components: Format: PNG, Format: TIFF
Affects Versions: 1.0
 Environment: W7
Reporter: Tilman Hausherr
Priority: Minor
 Attachments: Imaging_126_patch_1.patch, pdfbox-1870-devicen3-01.png, 
 pdfbox-1870-devicen3-01.tif, pdfbox-1870-devicen3.pdf-1.png, 
 pdfbox-1870-devicen3.pdf-1.tif


 I tried to use Apache Imaging for the PDFBOX project (PDFBOX-1734) because of 
 problems with setting the tiff resolution in java imageio.
 While the code is pretty nice, I found that the generated images are 
 sometimes much bigger in size than the ones generated by java imageio.
 Example:
 pdfbox-1870-devicen3-01.png 50 KB (imageio)
 pdfbox-1870-devicen3.pdf-1.png 70 KB (imaging)
 pdfbox-1870-devicen3-01.tif 401 KB (imageio)
 pdfbox-1870-devicen3.pdf-1.tif 1063 KB (imaging)



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (IMAGING-126) TIFF and PNG images should not be bigger than the ones created by java ImageIO

[Damjan Jovanovic (JIRA)]

[ 
https://issues.apache.org/jira/browse/IMAGING-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13914537#comment-13914537
 ] 

Damjan Jovanovic commented on IMAGING-126:
--

Well, it is for now...

 TIFF and PNG images should not be bigger than the ones created by java ImageIO
 --

 Key: IMAGING-126
 URL: https://issues.apache.org/jira/browse/IMAGING-126
 Project: Commons Imaging
  Issue Type: Improvement
  Components: Format: PNG, Format: TIFF
Affects Versions: 1.0
 Environment: W7
Reporter: Tilman Hausherr
Priority: Minor
 Attachments: Imaging_126_patch_1.patch, pdfbox-1870-devicen3-01.png, 
 pdfbox-1870-devicen3-01.tif, pdfbox-1870-devicen3.pdf-1.png, 
 pdfbox-1870-devicen3.pdf-1.tif


 I tried to use Apache Imaging for the PDFBOX project (PDFBOX-1734) because of 
 problems with setting the tiff resolution in java imageio.
 While the code is pretty nice, I found that the generated images are 
 sometimes much bigger in size than the ones generated by java imageio.
 Example:
 pdfbox-1870-devicen3-01.png 50 KB (imageio)
 pdfbox-1870-devicen3.pdf-1.png 70 KB (imaging)
 pdfbox-1870-devicen3-01.tif 401 KB (imageio)
 pdfbox-1870-devicen3.pdf-1.tif 1063 KB (imaging)



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (COMPRESS-243) Provide CompressorInputStream for classic Unix compress (maybe based on LZW codec from imaging)

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COMPRESS-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic updated COMPRESS-243:
--

Summary: Provide CompressorInputStream for classic Unix compress (maybe 
based on LZW codec from imaging)  (was: Provide Compressor for classic Unix 
compress (maybe based on LZW codec from imaging))

 Provide CompressorInputStream for classic Unix compress (maybe based on LZW 
 codec from imaging)
 ---

 Key: COMPRESS-243
 URL: https://issues.apache.org/jira/browse/COMPRESS-243
 Project: Commons Compress
  Issue Type: New Feature
Reporter: Stefan Bodewig
Priority: Minor

 https://svn.apache.org/repos/asf/commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/common/mylzw/



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (COMPRESS-243) Provide CompressorInputStream for classic Unix compress (maybe based on LZW codec from imaging)

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COMPRESS-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic resolved COMPRESS-243.
---

   Resolution: Fixed
Fix Version/s: 1.7

Ok, resolving fixed then. The CompressorOutputStream can be a different bug.

Porting wise, the reverse will probably happen: this implementation will get 
ported to commons-imaging :).

 Provide CompressorInputStream for classic Unix compress (maybe based on LZW 
 codec from imaging)
 ---

 Key: COMPRESS-243
 URL: https://issues.apache.org/jira/browse/COMPRESS-243
 Project: Commons Compress
  Issue Type: New Feature
Reporter: Stefan Bodewig
Priority: Minor
 Fix For: 1.7


 https://svn.apache.org/repos/asf/commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/common/mylzw/



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (COMPRESS-243) Provide Compressor for classic Unix compress (maybe based on LZW codec from imaging)

[Damjan Jovanovic (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13835637#comment-13835637
 ] 

Damjan Jovanovic commented on COMPRESS-243:
---

I've rewritten .Z decompression from scratch, tested it and optimized it. It 
doesn't really get much better than what I've got now, so I am going to commit 
it. No compression at the moment though, so leaving this issue open for now.


 Provide Compressor for classic Unix compress (maybe based on LZW codec from 
 imaging)
 

 Key: COMPRESS-243
 URL: https://issues.apache.org/jira/browse/COMPRESS-243
 Project: Commons Compress
  Issue Type: New Feature
Reporter: Stefan Bodewig
Priority: Minor

 https://svn.apache.org/repos/asf/commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/common/mylzw/



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (COMPRESS-243) Provide Compressor for classic Unix compress (maybe based on LZW codec from imaging)

[Damjan Jovanovic (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13833936#comment-13833936
 ] 

Damjan Jovanovic commented on COMPRESS-243:
---

Ok, correction. Commenting writeClearCode() and writeEoiCode() out of 
MyLzwCompressor.compress(), changing initial_entries_count in 
MyLzwCompressor.initilizeStringTable() to (1  codeSize) + 1 (because there 
isn't an EOI in .Z files), using little endian byte order and initialCodeSize 
of 8 (which internally becomes 9 like we want) in the constructor parameters to 
that class, then prefixing the resulting stream with 0x1f 0x9d 0x8c, does end 
up writing a file which correctly decompresses with compress - up until the 
point where it starts using 10 bits per symbol, then decompression breaks.

Apart from those changes, to use commons-imaging's MyLzw package for .Z 
files, we'd also need at least maximum code size to be set dynamically instead 
of being hardcoded to 12, changes to make string construction and comparisons 
more efficient, and it needs to be a filter stream type interface instead of a 
blocking array - array interface (which needs those string changes, since 
currently strings are stored as offset/length in the input array).

I'll continue to hack at it so long but please comment if you can help.

 Provide Compressor for classic Unix compress (maybe based on LZW codec from 
 imaging)
 

 Key: COMPRESS-243
 URL: https://issues.apache.org/jira/browse/COMPRESS-243
 Project: Commons Compress
  Issue Type: New Feature
Reporter: Stefan Bodewig
Priority: Minor

 https://svn.apache.org/repos/asf/commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/common/mylzw/



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (COMPRESS-243) Steal LZW codec from imaging and provide a Compressor for classic Unix compress

[Damjan Jovanovic (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13833029#comment-13833029
 ] 

Damjan Jovanovic commented on COMPRESS-243:
---

Even after adding the 3 byte .Z header, the bitstream written by 
commons-imaging is unreadable by uncompress, and even 1 byte files compress 
differently.

There is very little documentation about .Z files, so it's hard to tell which 
precise compression technique they use.


 Steal LZW codec from imaging and provide a Compressor for classic Unix 
 compress
 ---

 Key: COMPRESS-243
 URL: https://issues.apache.org/jira/browse/COMPRESS-243
 Project: Commons Compress
  Issue Type: New Feature
Reporter: Stefan Bodewig
Priority: Minor

 https://svn.apache.org/repos/asf/commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/common/mylzw/



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (COMPRESS-243) Steal LZW codec from imaging and provide a Compressor for classic Unix compress

[Damjan Jovanovic (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13831479#comment-13831479
 ] 

Damjan Jovanovic commented on COMPRESS-243:
---

I've considered this before. That Unix compress tool which writes .Z files 
(http://ncompress.sourceforge.net) is in the public domain, the useful part of 
its source code is at 
http://sourceforge.net/p/ncompress/code/ci/master/tree/compress.c and we 
immediately see it is far more general than the TIFF6-specific commons-imaging 
implementation (block mode, variable max bits size), and *much* faster.

Later I'll examine the compressed bitstream compatibility between them, but 
don't get your hopes up.


 Steal LZW codec from imaging and provide a Compressor for classic Unix 
 compress
 ---

 Key: COMPRESS-243
 URL: https://issues.apache.org/jira/browse/COMPRESS-243
 Project: Commons Compress
  Issue Type: New Feature
Reporter: Stefan Bodewig
Priority: Minor

 https://svn.apache.org/repos/asf/commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/common/mylzw/



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (IMAGING-119) Convert ImageFormat from emulated enum to actual Java 5 enum

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IMAGING-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic resolved IMAGING-119.
--

Resolution: Fixed

It's fine as is. Thank you, resolving fixed.

 Convert ImageFormat from emulated enum to actual Java 5 enum
 

 Key: IMAGING-119
 URL: https://issues.apache.org/jira/browse/IMAGING-119
 Project: Commons Imaging
  Issue Type: Improvement
Affects Versions: 0.97
Reporter: Matt Benson
Assignee: Matt Benson
 Fix For: 1.0






--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (IMAGING-121) Null Pointer exception while extracting metadata for CR2 image

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IMAGING-121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic resolved IMAGING-121.
--

   Resolution: Fixed
Fix Version/s: 1.0

Patch applied, resolving fixed. Thank you for your patch!

 Null Pointer exception while extracting metadata for CR2 image
 --

 Key: IMAGING-121
 URL: https://issues.apache.org/jira/browse/IMAGING-121
 Project: Commons Imaging
  Issue Type: Bug
Reporter: Piyush Kapoor
Priority: Minor
 Fix For: 1.0

 Attachments: Tiff.patch


 rowsPerStrip = imageHeight.getIntValue(); 
 is getting a null pointer exception if imageHeight is null



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (IMAGING-110) The requested URL /commons/imaging/binaries/commons-imaging-1.0-bin.zip was not found on this server.

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IMAGING-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic resolved IMAGING-110.
--

   Resolution: Fixed
Fix Version/s: 1.0

I promise we'll fix it for 1.0 in a few days.

 The requested URL /commons/imaging/binaries/commons-imaging-1.0-bin.zip was 
 not found on this server.
 -

 Key: IMAGING-110
 URL: https://issues.apache.org/jira/browse/IMAGING-110
 Project: Commons Imaging
  Issue Type: Bug
  Components: Site
Affects Versions: 1.0
Reporter: Kjell Moens
Priority: Blocker
 Fix For: 1.0


 When trying to download the jar files for commons-imaging, neither of the 
 sites seemed to work. You receive this error : 
 Not Found
 The requested URL /commons/imaging/binaries/commons-imaging-1.0-bin.zip was 
 not found on this server.
 Additionally, a 404 Not Found error was encountered while trying to use an 
 ErrorDocument to handle the request.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (IMAGING-121) Null Pointer exception while extracting metadata for CR2 image

[Damjan Jovanovic (JIRA)]

[ 
https://issues.apache.org/jira/browse/IMAGING-121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13809529#comment-13809529
 ] 

Damjan Jovanovic commented on IMAGING-121:
--

Why would imageHeight be null? Is this a TIFF file or an JPEG EXIF thumbnail?

 Null Pointer exception while extracting metadata for CR2 image
 --

 Key: IMAGING-121
 URL: https://issues.apache.org/jira/browse/IMAGING-121
 Project: Commons Imaging
  Issue Type: Bug
Reporter: Piyush Kapoor
Priority: Minor
 Attachments: Tiff.patch


 rowsPerStrip = imageHeight.getIntValue(); 
 is getting a null pointer exception if imageHeight is null



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (IMAGING-120) Extract an interface from ImageFormat

[Damjan Jovanovic (JIRA)]

[ 
https://issues.apache.org/jira/browse/IMAGING-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13804579#comment-13804579
 ] 

Damjan Jovanovic commented on IMAGING-120:
--

The patch seems to be missing the ImageFormatDescriptor.java file.

Also should the enum maybe be ImageFormats, and the interface ImageFormat? Or 
maybe leave that until version 2?


 Extract an interface from ImageFormat
 -

 Key: IMAGING-120
 URL: https://issues.apache.org/jira/browse/IMAGING-120
 Project: Commons Imaging
  Issue Type: Improvement
Affects Versions: 0.97
Reporter: Matt Benson
 Fix For: 1.0

 Attachments: IMAGING-120.patch.txt


 As discussed on the dev@commons ML, this would allow users to create custom 
 image formats while permitting the known image formats to be represented by 
 the {{ImageFormat enum}}.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (IMAGING-119) Convert ImageFormat from emulated enum to actual Java 5 enum

[Damjan Jovanovic (JIRA)]

[ 
https://issues.apache.org/jira/browse/IMAGING-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13804610#comment-13804610
 ] 

Damjan Jovanovic commented on IMAGING-119:
--

Well you've already written the old constant names, so I think let's just leave 
them for now.


 Convert ImageFormat from emulated enum to actual Java 5 enum
 

 Key: IMAGING-119
 URL: https://issues.apache.org/jira/browse/IMAGING-119
 Project: Commons Imaging
  Issue Type: Improvement
Affects Versions: 0.97
Reporter: Matt Benson
Assignee: Matt Benson
 Fix For: 1.0






--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (IMAGING-115) DhtSegment class contains mutable public arrays

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IMAGING-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic resolved IMAGING-115.
--

   Resolution: Fixed
Fix Version/s: 1.0

Ok getters that don't copy it is. Thank you, resolving fixed.

 DhtSegment class contains mutable public arrays
 ---

 Key: IMAGING-115
 URL: https://issues.apache.org/jira/browse/IMAGING-115
 Project: Commons Imaging
  Issue Type: Bug
Reporter: Sebb
 Fix For: 1.0


 Mutable public arrays are very bad for thread-safety and maintainability.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (IMAGING-115) DhtSegment class contains mutable public arrays

[Damjan Jovanovic (JIRA)]

[ 
https://issues.apache.org/jira/browse/IMAGING-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13802045#comment-13802045
 ] 

Damjan Jovanovic commented on IMAGING-115:
--

DhtSegment fields are accessed from the performance-critical JPEG decompression 
path, so making those arrays private and returning copies in getters is 
probably out of the question.


 DhtSegment class contains mutable public arrays
 ---

 Key: IMAGING-115
 URL: https://issues.apache.org/jira/browse/IMAGING-115
 Project: Commons Imaging
  Issue Type: Bug
Reporter: Sebb

 Mutable public arrays are very bad for thread-safety and maintainability.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (IMAGING-117) SofnSegment.components - public mutable array

[Damjan Jovanovic (JIRA)]

[ 
https://issues.apache.org/jira/browse/IMAGING-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13802068#comment-13802068
 ] 

Damjan Jovanovic commented on IMAGING-117:
--

Public mutable List:
TiffContents.directories and ColorGroup.color_counts are now 
Collections.unmodifiableList()s

Protected mutable arrays:
But protected fields can only be written from subclasses and from the same 
package, both of which presumably know not to write to them.


 SofnSegment.components - public mutable array
 -

 Key: IMAGING-117
 URL: https://issues.apache.org/jira/browse/IMAGING-117
 Project: Commons Imaging
  Issue Type: Bug
Reporter: Sebb





--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (IMAGING-106) JpegImageParser didn't rewrite the writeImage method

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IMAGING-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic updated IMAGING-106:
-

Issue Type: Improvement  (was: Bug)

 JpegImageParser didn't rewrite the writeImage method
 

 Key: IMAGING-106
 URL: https://issues.apache.org/jira/browse/IMAGING-106
 Project: Commons Imaging
  Issue Type: Improvement
  Components: Format: JPEG
Affects Versions: 1.0
 Environment: Windows 7, JDK 6, Commons Imaging svn version 1480454
Reporter: raise

 JpegImageParser didn't rewrite the writeImage method, this lead to that we 
 can not write BufferedImage to a jpeg file.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (IMAGING-106) JpegImageParser didn't rewrite the writeImage method

[Damjan Jovanovic (JIRA)]

[ 
https://issues.apache.org/jira/browse/IMAGING-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13800839#comment-13800839
 ] 

Damjan Jovanovic commented on IMAGING-106:
--

We don't support writing JPEG files at the moment, as documented in 
http://commons.apache.org/proper/commons-imaging/formatsupport.html

Setting Type to Improvement.


 JpegImageParser didn't rewrite the writeImage method
 

 Key: IMAGING-106
 URL: https://issues.apache.org/jira/browse/IMAGING-106
 Project: Commons Imaging
  Issue Type: Improvement
  Components: Format: JPEG
Affects Versions: 1.0
 Environment: Windows 7, JDK 6, Commons Imaging svn version 1480454
Reporter: raise

 JpegImageParser didn't rewrite the writeImage method, this lead to that we 
 can not write BufferedImage to a jpeg file.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (IMAGING-106) Writing JPEG images is unsupported

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IMAGING-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic updated IMAGING-106:
-

Summary: Writing JPEG images is unsupported  (was: JpegImageParser didn't 
rewrite the writeImage method)

 Writing JPEG images is unsupported
 --

 Key: IMAGING-106
 URL: https://issues.apache.org/jira/browse/IMAGING-106
 Project: Commons Imaging
  Issue Type: Improvement
  Components: Format: JPEG
Affects Versions: 1.0
 Environment: Windows 7, JDK 6, Commons Imaging svn version 1480454
Reporter: raise

 JpegImageParser didn't rewrite the writeImage method, this lead to that we 
 can not write BufferedImage to a jpeg file.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (IMAGING-108) JPEG EOI marker could not be found at expected location

[Damjan Jovanovic (JIRA)]

[ 
https://issues.apache.org/jira/browse/IMAGING-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13800863#comment-13800863
 ] 

Damjan Jovanovic commented on IMAGING-108:
--

IMAGING-99 was the reason that EOI check was needed. However testing that image 
with the section commented out still works, so I guess only doing that check 
when the strict flag is set is good enough.


 JPEG EOI marker could not be found at expected location
 ---

 Key: IMAGING-108
 URL: https://issues.apache.org/jira/browse/IMAGING-108
 Project: Commons Imaging
  Issue Type: Bug
  Components: Format: JPEG
 Environment: Windows
Reporter: Petr Nejedly
 Attachments: Christmas 2004 Matt 002.jpg


 Getting the above exception when calling
 ImageInfo imageInfo = Imaging.getImageInfo(f.getInputStream(), 
 f.getFilename());
 for the attached file.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (IMAGING-108) JPEG EOI marker could not be found at expected location

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IMAGING-108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic resolved IMAGING-108.
--

   Resolution: Fixed
Fix Version/s: 1.0

Patch committed, resolving fixed.

 JPEG EOI marker could not be found at expected location
 ---

 Key: IMAGING-108
 URL: https://issues.apache.org/jira/browse/IMAGING-108
 Project: Commons Imaging
  Issue Type: Bug
  Components: Format: JPEG
 Environment: Windows
Reporter: Petr Nejedly
 Fix For: 1.0

 Attachments: Christmas 2004 Matt 002.jpg


 Getting the above exception when calling
 ImageInfo imageInfo = Imaging.getImageInfo(f.getInputStream(), 
 f.getFilename());
 for the attached file.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (IMAGING-113) Cannot read multipage tiff

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IMAGING-113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic resolved IMAGING-113.
--

   Resolution: Fixed
Fix Version/s: 1.0

Thank you for the bug report. Patch committed, resolving fixed.

 Cannot read multipage tiff
 --

 Key: IMAGING-113
 URL: https://issues.apache.org/jira/browse/IMAGING-113
 Project: Commons Imaging
  Issue Type: Bug
Affects Versions: 1.0
Reporter: Adrian Costil
  Labels: multipage, tiff
 Fix For: 1.0


 I get the error below when I'm trying to read a multipage tiff file as a list 
 of images
   final ListBufferedImage images = 
 Imaging.getAllBufferedImages(new File(imageLocation));
 line 589 of TiffImageParser
 Rectangle subImage = checkForSubImage(params); //if the params is 
 null it will crash
 java.lang.NullPointerException
   at 
 org.apache.commons.imaging.formats.tiff.TiffImageParser.getIntegerParameter(TiffImageParser.java:513)
   at 
 org.apache.commons.imaging.formats.tiff.TiffImageParser.checkForSubImage(TiffImageParser.java:531)
   at 
 org.apache.commons.imaging.formats.tiff.TiffImageParser.getBufferedImage(TiffImageParser.java:589)
   at 
 org.apache.commons.imaging.formats.tiff.TiffDirectory.getTiffImage(TiffDirectory.java:163)
   at 
 org.apache.commons.imaging.formats.tiff.TiffImageParser.getAllBufferedImages(TiffImageParser.java:499)
   at 
 org.apache.commons.imaging.Imaging.getAllBufferedImages(Imaging.java:1210)
   at 
 org.apache.commons.imaging.Imaging.getAllBufferedImages(Imaging.java:1202)
   at TestWriteTiffImages.main(TestWriteTiffImages.java:30)



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (IMAGING-109) Several files contain non-UTF8 characters

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IMAGING-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic resolved IMAGING-109.
--

   Resolution: Fixed
Fix Version/s: 1.0

Thank you for your bug report. Patch committed, resolving fixed.

 Several files contain non-UTF8 characters
 -

 Key: IMAGING-109
 URL: https://issues.apache.org/jira/browse/IMAGING-109
 Project: Commons Imaging
  Issue Type: Bug
Reporter: Max Gilead
Priority: Minor
 Fix For: 1.0


 That makes javac very unhappy, particularly version 7 on OSX.
 src/main/java/org/apache/commons/imaging/color/ColorConversions.java:32: 
 error: unmappable character for encoding UTF8
 double var_X = X / ref_X; // ref_X = 95.047 Observer= 2�, Illuminant=
^
 src/main/java/org/apache/commons/imaging/color/ColorConversions.java:84: 
 error: unmappable character for encoding UTF8
 final double X = ref_X * var_X; // ref_X = 95.047 Observer= 2�, 
 Illuminant=
  ^
 src/main/java/org/apache/commons/imaging/color/ColorConversions.java:127: 
 error: unmappable character for encoding UTF8
 // Observer = 2�, Illuminant = D65
^
 src/main/java/org/apache/commons/imaging/color/ColorConversions.java:128: 
 error: unmappable character for encoding UTF8
 final double var_X = X / 100.0; // Where X = 0 � 95.047
^
 src/main/java/org/apache/commons/imaging/color/ColorConversions.java:129: 
 error: unmappable character for encoding UTF8
 final double var_Y = Y / 100.0; // Where Y = 0 � 100.000
^
 src/main/java/org/apache/commons/imaging/color/ColorConversions.java:130: 
 error: unmappable character for encoding UTF8
 final double var_Z = Z / 100.0; // Where Z = 0 � 108.883
^
 src/main/java/org/apache/commons/imaging/color/ColorConversions.java:164: 
 error: unmappable character for encoding UTF8
 double var_R = r / 255.0; // Where R = 0 � 255
  ^
 src/main/java/org/apache/commons/imaging/color/ColorConversions.java:165: 
 error: unmappable character for encoding UTF8
 double var_G = g / 255.0; // Where G = 0 � 255
  ^
 src/main/java/org/apache/commons/imaging/color/ColorConversions.java:166: 
 error: unmappable character for encoding UTF8
 double var_B = b / 255.0; // Where B = 0 � 255
  ^
 src/main/java/org/apache/commons/imaging/color/ColorConversions.java:188: 
 error: unmappable character for encoding UTF8
 // Observer. = 2�, Illuminant = D65
 ^
 src/main/java/org/apache/commons/imaging/color/ColorConversions.java:201: 
 error: unmappable character for encoding UTF8
 // RGB values = 0 � 255
   ^
 src/main/java/org/apache/commons/imaging/color/ColorConversions.java:202: 
 error: unmappable character for encoding UTF8
 // CMY values = 0 � 1
   ^
 src/main/java/org/apache/commons/imaging/color/ColorConversions.java:218: 
 error: unmappable character for encoding UTF8
 // CMY values = 0 � 1
   ^
 src/main/java/org/apache/commons/imaging/color/ColorConversions.java:219: 
 error: unmappable character for encoding UTF8
 // RGB values = 0 � 255
   ^
 src/main/java/org/apache/commons/imaging/color/ColorConversions.java:229: 
 error: unmappable character for encoding UTF8
 // Where CMYK and CMY values = 0 � 1
  ^
 src/main/java/org/apache/commons/imaging/color/ColorConversions.java:264: 
 error: unmappable character for encoding UTF8
 // Where CMYK and CMY values = 0 � 1
  ^
 src/main/java/org/apache/commons/imaging/color/ColorConversions.java:290: 
 error: unmappable character for encoding UTF8
 final double var_R = (R / 255.0); // Where RGB values = 0 � 255
   ^
 src/main/java/org/apache/commons/imaging/color/ColorConversions.java:317: 
 error: unmappable character for encoding UTF8
 H = 0; // HSL results = 0 � 1
   ^
 src/main/java/org/apache/commons/imaging/color/ColorConversions.java:367: 
 error: unmappable character for encoding UTF8
 // HSL values = 0 � 1
   ^
 

[jira] [Updated] (IMAGING-100) Need to support images with multiple App13 segments

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IMAGING-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic updated IMAGING-100:
-

Summary: Need to support images with multiple App13 segments  (was: 
Sanselan stumbles on attached image)

 Need to support images with multiple App13 segments
 ---

 Key: IMAGING-100
 URL: https://issues.apache.org/jira/browse/IMAGING-100
 Project: Commons Imaging
  Issue Type: Bug
  Components: Format: JPEG
Affects Versions: 0.97
Reporter: Luis Arias
Assignee: Damjan Jovanovic
Priority: Minor
 Attachments: employee.jpg


 The attached image gives rise to the following exception when using sanselan 
 to retrieve exif orientation information as follows:
   IImageMetadata metadata = Sanselan.getMetadata(bytes);
   JpegImageMetadata jpegMetadata = (JpegImageMetadata) metadata;
   TiffField orientation = 
 jpegMetadata.findEXIFValue(TiffConstants.EXIF_TAG_ORIENTATION);
   orientation.getIntValue();
 |  org.apache.sanselan.ImageReadException: Jpeg contains more than one 
 Photoshop App13 segment.
   at 
 org.apache.sanselan.formats.jpeg.JpegImageParser.getPhotoshopMetadata(JpegImageParser.java:609)
   at 
 org.apache.sanselan.formats.jpeg.JpegImageParser.getMetadata(JpegImageParser.java:309)
   at org.apache.sanselan.Sanselan.getMetadata(Sanselan.java:978)
   at org.apache.sanselan.Sanselan.getMetadata(Sanselan.java:871)
   at org.apache.sanselan.Sanselan.getMetadata(Sanselan.java:846)



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (IMAGING-114) ComSegment.comment is a public final byte array

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IMAGING-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic resolved IMAGING-114.
--

   Resolution: Fixed
Fix Version/s: 1.0

Patch committed, resolving fixed. Thank you for your bug report.

 ComSegment.comment is a public final byte array
 ---

 Key: IMAGING-114
 URL: https://issues.apache.org/jira/browse/IMAGING-114
 Project: Commons Imaging
  Issue Type: Bug
Reporter: Sebb
 Fix For: 1.0


 ComSegment.comment is a public final byte array.
 This is mutable, and not advisable as it is easily corrupted accidentally or 
 deliberately; also it's not possible to guarantee thread-safety.
 The field should be private with sutable accessors.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (IMAGING-102) TIFF parser does not support floating-point images

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IMAGING-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic updated IMAGING-102:
-

Issue Type: Improvement  (was: Bug)

 TIFF parser does not support floating-point images
 --

 Key: IMAGING-102
 URL: https://issues.apache.org/jira/browse/IMAGING-102
 Project: Commons Imaging
  Issue Type: Improvement
Reporter: Gary Lucas
 Attachments: Sample64BitFloatingPointPix451x337.tif


 The TIFF specification defines a data form for storing pixels as either 
 32-bit or 64-bit floating point values given in the IEEE 754 format. The 
 TIFF-6 specification is actually incomplete in this regard, but typically 
 such values are stored as data in the range [0,1] with  (or other values 
 out of the range zero to one) used to indicate no-data.   Typically, values 
 are rendered in gray tones. The TIFF SampleFormat tag indicates when data 
 is encoded in this form.
 Commons Imaging does not currently support data that uses the floating-point 
 sample format.  It does define a constant in the TiffTagConstants.java file 
 which is named SAMPLE_FORMAT_VALUE_IEEE_FLOATING_POINT.  But this constant is 
 not used in the code.
 I propose to at least implement read-support for images in this format. I am 
 working to obtain permission to post a sample image which I will attach to 
 this tracker item in the future. 
 Currently, the TIFF parser provides output in the form of a BufferedImage. 
 For the initial implementation, I recommend staying with that convention and 
 resolving the floating point values to gray tones. Although this approach has 
 the disadvantage that it will not provide an API for extracting the original 
 floating-point values, it seems to me the safest tactic for an initial 
 implementation.
 Development will require some caution to avoid degrading parser performance. 
 The BitImageStream.readBits() method which reads samples (pixels) from the 
 source data, currently returns the Java int type, which only supports 32 
 bits.  To support 64 bits, this function would have to return a Java long.  
 The development effort will require testing to ensure that making a change of 
 this type does not degrade performance for the mainstream TIFF data formats 
 (probably this is only an issue on 32-bit operating systems).
 For those of you who are asking why someone would choose to store data using 
 floating-point values (at the cost of 64 bits per pixel)... I don't really 
 know. Putting aside the fact that it's in the spec (sort of) and somebody 
 wants me to plot data from such images, I would have to say the motivation 
 would probably be using TIFF files as a way of storing arbitrary data in 
 gridded fields.  The proposed changes wouldn't satisfy their requirements, 
 but it is a first step in that direction.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (IMAGING-97) Fails to read most Sony A100 JPG files generated from Photoshop CS2

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IMAGING-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic updated IMAGING-97:


Issue Type: New Feature  (was: Bug)

 Fails to read most Sony A100 JPG files generated from Photoshop CS2 
 

 Key: IMAGING-97
 URL: https://issues.apache.org/jira/browse/IMAGING-97
 Project: Commons Imaging
  Issue Type: New Feature
  Components: Format: JPEG
Affects Versions: 1.0
 Environment: Windows 7, JDK1.7, Imaging snapshot build from 20121013
Reporter: William Saar
 Attachments: _DSC6099.jpg


 This line fails with the exception at the bottom for most of my old JPG files 
 shot with a Sony A100, and sometimes processed by Photoshop CS2. I will 
 attach a failing file.
 BufferedImage img = Imaging.getBufferedImage(compressedThumbnailData, 
 jpgDecodeParams);
 where jpgDecodeParams are
 ImagingConstants.BUFFERED_IMAGE_FACTORY, new RgbBufferedImageFactory()
 ImagingConstants.PARAM_KEY_FORMAT, ImageFormat.IMAGE_FORMAT_JPEG
 Exception:
 org.apache.commons.imaging.ImageReadException: Invalid marker found in 
 entropy data
   at 
 org.apache.commons.imaging.formats.jpeg.decoder.JpegInputStream.nextBit(JpegInputStream.java:50)
   at 
 org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.decode(JpegDecoder.java:417)
   at 
 org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.readMCU(JpegDecoder.java:311)
   at 
 org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.visitSOS(JpegDecoder.java:122)
   at 
 org.apache.commons.imaging.formats.jpeg.JpegUtils.traverseJFIF(JpegUtils.java:83)
   at 
 org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.decode(JpegDecoder.java:428)
   at 
 org.apache.commons.imaging.formats.jpeg.JpegImageParser.getBufferedImage(JpegImageParser.java:95)
   at 
 org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1375)
   at 
 org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1315)
   at 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (IMAGING-112) JpegIptcRewriter.removeIPTC() does not remove all metadata

[Damjan Jovanovic (JIRA)]

[ 
https://issues.apache.org/jira/browse/IMAGING-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13800967#comment-13800967
 ] 

Damjan Jovanovic commented on IMAGING-112:
--

Hmm, that is the documented behaviour in the Javadoc:
 Reads a Jpeg image, removes all IPTC data from the App13 segment but
 leaves the other data in that segment (if present) unchanged and writes
 the result to a stream.

However it is inconsistent with what ExifRewriter does:
 Reads a Jpeg image, removes all EXIF metadata (by removing the APP1
 segment), and writes the result to a stream.

I guess the problem is that the App13 segment can contain other data in 
addition to IPTC so that's why it isn't removed completely like EXIF's App1 
segment? Maybe we should have an additional method to remove the entire segment?


 JpegIptcRewriter.removeIPTC() does not remove all metadata
 --

 Key: IMAGING-112
 URL: https://issues.apache.org/jira/browse/IMAGING-112
 Project: Commons Imaging
  Issue Type: Bug
Affects Versions: 1.0
Reporter: Xavier Dury
 Attachments: ImageTest.java


 I'm trying to compute hashes from my images to detect duplicates.
 To do so, I strip every metadata (like keywords I may have added) then 
 compute a CRC32.
 My problem is that JpegIptcRewriter.removeIPTC() does not remove all metadata 
 as there is always a difference of 18 bytes (containing Photoshop 3.0).
 So could it be possible to remove those 18 bytes as well in removeIPTC() so 
 that I can compute hashes?
 Thanks,
 Xavier



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (IMAGING-112) JpegIptcRewriter.removeIPTC() does not remove all metadata

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IMAGING-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic updated IMAGING-112:
-

Issue Type: Improvement  (was: Bug)

 JpegIptcRewriter.removeIPTC() does not remove all metadata
 --

 Key: IMAGING-112
 URL: https://issues.apache.org/jira/browse/IMAGING-112
 Project: Commons Imaging
  Issue Type: Improvement
Affects Versions: 1.0
Reporter: Xavier Dury
 Attachments: ImageTest.java


 I'm trying to compute hashes from my images to detect duplicates.
 To do so, I strip every metadata (like keywords I may have added) then 
 compute a CRC32.
 My problem is that JpegIptcRewriter.removeIPTC() does not remove all metadata 
 as there is always a difference of 18 bytes (containing Photoshop 3.0).
 So could it be possible to remove those 18 bytes as well in removeIPTC() so 
 that I can compute hashes?
 Thanks,
 Xavier



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (IMAGING-118) interface RgbeConstants contains mutable array

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IMAGING-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic resolved IMAGING-118.
--

   Resolution: Fixed
Fix Version/s: 1.0

Thank you, fixed.

 interface RgbeConstants contains mutable array
 --

 Key: IMAGING-118
 URL: https://issues.apache.org/jira/browse/IMAGING-118
 Project: Commons Imaging
  Issue Type: Bug
Reporter: Sebb
 Fix For: 1.0


 Interfaces should never contain data, and particularly not mutable constants.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (IMAGING-117) SofnSegment.components - public mutable array

[Damjan Jovanovic (JIRA)]

[ 
https://issues.apache.org/jira/browse/IMAGING-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13801458#comment-13801458
 ] 

Damjan Jovanovic commented on IMAGING-117:
--

Ok, but why are protected mutable arrays a problem?

 SofnSegment.components - public mutable array
 -

 Key: IMAGING-117
 URL: https://issues.apache.org/jira/browse/IMAGING-117
 Project: Commons Imaging
  Issue Type: Bug
Reporter: Sebb





--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (IMAGING-116) GenericSegment.bytes - public mutable array

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IMAGING-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic resolved IMAGING-116.
--

   Resolution: Fixed
Fix Version/s: 1.0

Thank you, patch committed, resolving fixed.

 GenericSegment.bytes - public mutable array
 ---

 Key: IMAGING-116
 URL: https://issues.apache.org/jira/browse/IMAGING-116
 Project: Commons Imaging
  Issue Type: Bug
Reporter: Sebb
 Fix For: 1.0






--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Created] (COMPRESS-226) Add ARJ archive support

[Damjan Jovanovic (JIRA)]

Damjan Jovanovic created COMPRESS-226:
-

 Summary: Add ARJ archive support
 Key: COMPRESS-226
 URL: https://issues.apache.org/jira/browse/COMPRESS-226
 Project: Commons Compress
  Issue Type: New Feature
  Components: Archivers
Affects Versions: 1.5
 Environment: All
Reporter: Damjan Jovanovic
Priority: Minor
 Fix For: 1.6


This is just to track ARJ archive support I am adding.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (COMPRESS-226) Add ARJ archive support

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COMPRESS-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic resolved COMPRESS-226.
---

Resolution: Fixed
  Assignee: Damjan Jovanovic

Patch committed, resolving fixed.

 Add ARJ archive support
 ---

 Key: COMPRESS-226
 URL: https://issues.apache.org/jira/browse/COMPRESS-226
 Project: Commons Compress
  Issue Type: New Feature
  Components: Archivers
Affects Versions: 1.5
 Environment: All
Reporter: Damjan Jovanovic
Assignee: Damjan Jovanovic
Priority: Minor
 Fix For: 1.6

   Original Estimate: 10m
  Remaining Estimate: 10m

 This is just to track ARJ archive support I am adding.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (COMPRESS-111) support for lzma files

[Damjan Jovanovic (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13651683#comment-13651683
 ] 

Damjan Jovanovic edited comment on COMPRESS-111 at 5/8/13 7:42 AM:
---

Compared to the normal way of extracting a file from an archive 
(read-decompress-write), the temp-file solution requires 
read-decompress-write-temp-read-temp-write, increasing I/O time 
proportionally to the size of the decompressed file (ie. at least doubling it), 
which is why I didn't even consider it.

It seems like LZMA2 breaks up the stream to be compressed into blocks, and can 
(de)compress the blocks independently of each other (which has the benefit of 
allowing fast, multi-threaded decompression). In Lasse's code, LZMA2InputStream 
uses O\(n) memory per block in the method RangeDecoder.prepareInputBuffer() 
called from LZMA2InputStream.decodeChunkHeader(). For LZMA however, the block 
is the entire file. Luckily it seems pretty easy to patch RangeDecoder to read 
incrementally. LZMA2InputStream probably has to also be modified, as I don't 
think LZMA has a chunk header. I don't know what else may be necessary.

Oh and even if LZMA is a legacy format, we still need it for reading .7z files, 
which always use LZMA for header compression (which is enabled by default).


  was (Author: damjan):
Compared to the normal way of extracting a file from an archive 
(read-decompress-write), the temp-file solution requires 
read-decompress-write-temp-read-temp-write, increasing I/O time 
proportionally to the size of the decompressed file (ie. at least doubling it), 
which is why I didn't even consider it.

It seems like LZMA2 breaks up the stream to be compressed into blocks, and can 
(de)compress the blocks independently of each other (which has the benefit of 
allowing fast, multi-threaded decompression). In Lasse's code, LZMA2InputStream 
uses O(n) memory per block in the method RangeDecoder.prepareInputBuffer() 
called from LZMA2InputStream.decodeChunkHeader(). For LZMA however, the block 
is the entire file. Luckily it seems pretty easy to patch RangeDecoder to read 
incrementally. LZMA2InputStream probably has to also be modified, as I don't 
think LZMA has a chunk header. I don't know what else may be necessary.

Oh and even if LZMA is a legacy format, we still need it for reading .7z files, 
which always use LZMA for header compression (which is enabled by default).

  
 support for lzma files
 --

 Key: COMPRESS-111
 URL: https://issues.apache.org/jira/browse/COMPRESS-111
 Project: Commons Compress
  Issue Type: New Feature
  Components: Compressors
Affects Versions: 1.0
Reporter: maurel jean francois
 Attachments: compress-trunk-lzmaRev0.patch, 
 compress-trunk-lzmaRev1.patch


 adding support for compressing and decompressing of files with LZMA algoritm 
 (Lempel-Ziv-Markov chain-Algorithm)
 (see 
 http://markmail.org/search/?q=list%3Aorg.apache.commons.users/#query:list%3Aorg.apache.commons.users%2F+page:1+mid:syn4uuvbzusevtko+state:results)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (COMPRESS-111) support for lzma files

[Damjan Jovanovic (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13651683#comment-13651683
 ] 

Damjan Jovanovic commented on COMPRESS-111:
---

Compared to the normal way of extracting a file from an archive 
(read-decompress-write), the temp-file solution requires 
read-decompress-write-temp-read-temp-write, increasing I/O time 
proportionally to the size of the decompressed file (ie. at least doubling it), 
which is why I didn't even consider it.

It seems like LZMA2 breaks up the stream to be compressed into blocks, and can 
(de)compress the blocks independently of each other (which has the benefit of 
allowing fast, multi-threaded decompression). In Lasse's code, LZMA2InputStream 
uses O(n) memory per block in the method RangeDecoder.prepareInputBuffer() 
called from LZMA2InputStream.decodeChunkHeader(). For LZMA however, the block 
is the entire file. Luckily it seems pretty easy to patch RangeDecoder to read 
incrementally. LZMA2InputStream probably has to also be modified, as I don't 
think LZMA has a chunk header. I don't know what else may be necessary.

Oh and even if LZMA is a legacy format, we still need it for reading .7z files, 
which always use LZMA for header compression (which is enabled by default).


 support for lzma files
 --

 Key: COMPRESS-111
 URL: https://issues.apache.org/jira/browse/COMPRESS-111
 Project: Commons Compress
  Issue Type: New Feature
  Components: Compressors
Affects Versions: 1.0
Reporter: maurel jean francois
 Attachments: compress-trunk-lzmaRev0.patch, 
 compress-trunk-lzmaRev1.patch


 adding support for compressing and decompressing of files with LZMA algoritm 
 (Lempel-Ziv-Markov chain-Algorithm)
 (see 
 http://markmail.org/search/?q=list%3Aorg.apache.commons.users/#query:list%3Aorg.apache.commons.users%2F+page:1+mid:syn4uuvbzusevtko+state:results)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (COMPRESS-54) Add 7zip or RAR archive support

[Damjan Jovanovic (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13651277#comment-13651277
 ] 

Damjan Jovanovic commented on COMPRESS-54:
--

As of revision 1480055, I've committed read-only support for 7z archives to SVN 
trunk. But we have no LZMA compression support yet, so it can only read 
archives made with special options - see the Javadoc for SevenZFile for details.


 Add 7zip or RAR archive support
 ---

 Key: COMPRESS-54
 URL: https://issues.apache.org/jira/browse/COMPRESS-54
 Project: Commons Compress
  Issue Type: New Feature
  Components: Archivers
 Environment: N/A
Reporter: Tim Pinet
Priority: Minor
   Original Estimate: 30h
  Remaining Estimate: 30h

 Has anyone looked into adding support for 7zip and RAR file types? Using the 
 j7zip and junrar libraries I was able to get a rough protoype working with 
 commons-compress but only with extract support for RAR (due to licencing 
 issues). Also, my prototype performance is poor so I definately need to 
 improve it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (COMPRESS-111) support for lzma files

[Damjan Jovanovic (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13651308#comment-13651308
 ] 

Damjan Jovanovic commented on COMPRESS-111:
---

The fundamental problem is that Commons Compress does decompression via 
CompressorInputStream’s read() methods, which are a pull-model interface, while 
the LZMA SDK (in the public domain) does it with Decoder.code(), a method that 
takes a compressed input stream and an output stream to decompress to, then 
reads, decompresses, and writes, only returning when the entire file is 
decompressed. There is no way to convert this to a pull-model 
CompressorInputStream: either you have to pull in one thread while pushing from 
another, or push everything into a ByteArrayInputStream (which needs O\(n) 
memory!!) and then pull from that afterwards. Both are really ugly solutions: 
thread per stream is heavy and creating new threads is not allowed in some 
environments (eg. unsigned Applets and Java EE servers), while trying to 
allocate O\(n) memory can OutOfMemoryError the entire JVM.

The Java LZMA attempts out there rate as follows:

Maurel’s patch here uses O\(n) memory, and decompresses the entire stream in 
the constructor and stores it in a ByteArrayInputStream which is then copied 
from on each read().

http://jponge.github.io/lzma-java/ is licensed ASLv2 and states how it solved 
the push/pull problem: “Although not a derivate work, the streaming api classes 
were inspired from the work of Christopher League. I reused his technique of 
fake streams and working threads to pass the data around between 
encoders/decoders and normal Java streams.” In other words, it pushes in one 
thread and pulls in another. Actual decompression in the other thread is still 
done with the LZMA SDK, which it just wraps into an InputStream subclass.

http://contrapunctus.net/league/haques/lzmajio/ was done by Christopher League, 
it’s under “LGPL or the Common Public License” and has the same push in one 
thread pull in another story. It’s also just a wrapper of the LZMA SDK.

http://tukaani.org/xz/java.html is in the public domain and is already used by 
Commons Compress to provide XZ compression support. It supports XZ and LZMA2 
only and supports them well - proper pull-model InputStream with no O\(n) 
memory or background threads. LZMA2 is a different file format from LZMA. But 
then again LZMA2 uses LZMA internally. I’ll have to investigate in detail.

 support for lzma files
 --

 Key: COMPRESS-111
 URL: https://issues.apache.org/jira/browse/COMPRESS-111
 Project: Commons Compress
  Issue Type: New Feature
  Components: Compressors
Affects Versions: 1.0
Reporter: maurel jean francois
 Attachments: compress-trunk-lzmaRev0.patch, 
 compress-trunk-lzmaRev1.patch


 adding support for compressing and decompressing of files with LZMA algoritm 
 (Lempel-Ziv-Markov chain-Algorithm)
 (see 
 http://markmail.org/search/?q=list%3Aorg.apache.commons.users/#query:list%3Aorg.apache.commons.users%2F+page:1+mid:syn4uuvbzusevtko+state:results)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (IMAGING-100) Sanselan stumbles on attached image

[Damjan Jovanovic (JIRA)]

[ 
https://issues.apache.org/jira/browse/IMAGING-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13538997#comment-13538997
 ] 

Damjan Jovanovic commented on IMAGING-100:
--

According to http://dev.robotbattle.com/bugs/view.php?id=533
there are 2 cases when multiple App13 segments appear: one is (a) where a 
single IPTC block is split into multiple segments, and the other is (b) when 
there are multiple independent IPTC blocks.

This image is case (b). To write a patch for this, I also need a case (a) image 
so I can see exactly how to distinguish these cases.


 Sanselan stumbles on attached image
 ---

 Key: IMAGING-100
 URL: https://issues.apache.org/jira/browse/IMAGING-100
 Project: Commons Imaging
  Issue Type: Bug
  Components: Format: JPEG
Affects Versions: 0.97
Reporter: Luis Arias
Priority: Minor
 Attachments: employee.jpg


 The attached image gives rise to the following exception when using sanselan 
 to retrieve exif orientation information as follows:
   IImageMetadata metadata = Sanselan.getMetadata(bytes);
   JpegImageMetadata jpegMetadata = (JpegImageMetadata) metadata;
   TiffField orientation = 
 jpegMetadata.findEXIFValue(TiffConstants.EXIF_TAG_ORIENTATION);
   orientation.getIntValue();
 |  org.apache.sanselan.ImageReadException: Jpeg contains more than one 
 Photoshop App13 segment.
   at 
 org.apache.sanselan.formats.jpeg.JpegImageParser.getPhotoshopMetadata(JpegImageParser.java:609)
   at 
 org.apache.sanselan.formats.jpeg.JpegImageParser.getMetadata(JpegImageParser.java:309)
   at org.apache.sanselan.Sanselan.getMetadata(Sanselan.java:978)
   at org.apache.sanselan.Sanselan.getMetadata(Sanselan.java:871)
   at org.apache.sanselan.Sanselan.getMetadata(Sanselan.java:846)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (IMAGING-94) Add ability to load partial TIFF images

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IMAGING-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic resolved IMAGING-94.
-

   Resolution: Fixed
Fix Version/s: 1.0

Thank you very much for your patch Gary, I've committed it now :).

Resolving fixed.


 Add ability to load partial TIFF images
 ---

 Key: IMAGING-94
 URL: https://issues.apache.org/jira/browse/IMAGING-94
 Project: Commons Imaging
  Issue Type: New Feature
  Components: Format: TIFF
Reporter: Gary Lucas
 Fix For: 1.0

 Attachments: LucasTrackerItem94_Oct14.patch, 
 LucasTrackerItem94_Oct24.patch


 For most Apache Commons Imaging applications, the easiest way to obtain a sub 
 image from a file is to simply use the Imaging class to load it as a 
 BufferedImage and then use BufferedImage’s getSubimage() method to extract 
 the portion of the image you wish to use.  The TIFF format presents a special 
 problem because it is very common to have huge images (100’s or even 1000’s 
 of megapixel).  Examples include Landsat satellite images, global-scale 
 GeoTIFF images, etc.  In such cases, loading the entire image into memory is 
 not practical because it would require too much memory.  For example, I am 
 currently working with a 21600 by 10800 image that requires more than 890 
 megabytes to store as a BufferedImage.  That value is pushing the limit of 
 what I can configure Java to handle on my particular OS.
 I propose to implement features for TIFF files that would permit Commons 
 Imaging to load a partial image of a TIFF file using only the amount memory 
 actually needed to hold the sub-image.
 These changes would not interfere with normal operations of TIFF files and 
 would not affect other image formats.  If there were a need for similar 
 features for other image formats, they could be phased in through future 
 changes.
 The specification for a sub-image would be through the use of the params 
 argument in the getBufferedImage call as follows:
 HashMapString, Object params = new HashMapString, Object();
 params.put(TiffConstants.PARAM_KEY_SUBIMAGE_X, new Integer( x ));
 params.put(TiffConstants.PARAM_KEY_SUBIMAGE_Y, new Integer( y ));
 params.put(TiffConstants.PARAM_KEY_SUBIMAGE_WIDTH, new 
 Integer(width));
 params.put(TiffConstants.PARAM_KEY_SUBIMAGE_HEIGHT, new 
 Integer(height));

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (IMAGING-97) Fails to read most Sony A100 JPG files generated from Photoshop CS2

[Damjan Jovanovic (JIRA)]

[ 
https://issues.apache.org/jira/browse/IMAGING-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13509491#comment-13509491
 ] 

Damjan Jovanovic commented on IMAGING-97:
-

Imaging's ability to read images from JPEG files is still at an early stage, as 
documented in src/site/xdoc/formatsupport.xml. ImageIO is a better bet for now.


 Fails to read most Sony A100 JPG files generated from Photoshop CS2 
 

 Key: IMAGING-97
 URL: https://issues.apache.org/jira/browse/IMAGING-97
 Project: Commons Imaging
  Issue Type: Bug
  Components: Format: JPEG
Affects Versions: 1.0
 Environment: Windows 7, JDK1.7, Imaging snapshot build from 20121013
Reporter: William Saar
 Attachments: _DSC6099.jpg


 This line fails with the exception at the bottom for most of my old JPG files 
 shot with a Sony A100, and sometimes processed by Photoshop CS2. I will 
 attach a failing file.
 BufferedImage img = Imaging.getBufferedImage(compressedThumbnailData, 
 jpgDecodeParams);
 where jpgDecodeParams are
 ImagingConstants.BUFFERED_IMAGE_FACTORY, new RgbBufferedImageFactory()
 ImagingConstants.PARAM_KEY_FORMAT, ImageFormat.IMAGE_FORMAT_JPEG
 Exception:
 org.apache.commons.imaging.ImageReadException: Invalid marker found in 
 entropy data
   at 
 org.apache.commons.imaging.formats.jpeg.decoder.JpegInputStream.nextBit(JpegInputStream.java:50)
   at 
 org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.decode(JpegDecoder.java:417)
   at 
 org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.readMCU(JpegDecoder.java:311)
   at 
 org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.visitSOS(JpegDecoder.java:122)
   at 
 org.apache.commons.imaging.formats.jpeg.JpegUtils.traverseJFIF(JpegUtils.java:83)
   at 
 org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.decode(JpegDecoder.java:428)
   at 
 org.apache.commons.imaging.formats.jpeg.JpegImageParser.getBufferedImage(JpegImageParser.java:95)
   at 
 org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1375)
   at 
 org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1315)
   at 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (IMAGING-99) java.io.IOException: Could not read block

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IMAGING-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic resolved IMAGING-99.
-

   Resolution: Fixed
Fix Version/s: 1.0

Thank you, fixed.


 java.io.IOException: Could not read block
 -

 Key: IMAGING-99
 URL: https://issues.apache.org/jira/browse/IMAGING-99
 Project: Commons Imaging
  Issue Type: Bug
  Components: Format: JPEG
Affects Versions: 0.97
Reporter: st.h
 Fix For: 1.0


 We have found that certain images could not be read with imaging, even they 
 usually appear to be fine. This is the stack trace:
 {code}
 java.io.IOException: Could not read block (block start: 442, block length: 
 8861, data length: 9301).
   at 
 org.apache.commons.imaging.common.bytesource.ByteSourceArray.getBlock(ByteSourceArray.java:46)
   at 
 org.apache.commons.imaging.formats.tiff.TiffReader.getJpegRawImageData(TiffReader.java:491)
   at 
 org.apache.commons.imaging.formats.tiff.TiffReader.readDirectory(TiffReader.java:216)
   at 
 org.apache.commons.imaging.formats.tiff.TiffReader.readDirectory(TiffReader.java:103)
   at 
 org.apache.commons.imaging.formats.tiff.TiffReader.readDirectory(TiffReader.java:272)
   at 
 org.apache.commons.imaging.formats.tiff.TiffReader.readDirectory(TiffReader.java:103)
   at 
 org.apache.commons.imaging.formats.tiff.TiffReader.readDirectories(TiffReader.java:95)
   at 
 org.apache.commons.imaging.formats.tiff.TiffReader.read(TiffReader.java:421)
   at 
 org.apache.commons.imaging.formats.tiff.TiffReader.readContents(TiffReader.java:412)
   at 
 org.apache.commons.imaging.formats.tiff.TiffImageParser.getMetadata(TiffImageParser.java:132)
   at 
 org.apache.commons.imaging.ImageParser.getMetadata(ImageParser.java:203)
   at 
 org.apache.commons.imaging.formats.jpeg.JpegImageParser.getExifMetadata(JpegImageParser.java:335)
   at 
 org.apache.commons.imaging.formats.jpeg.JpegImageParser.getMetadata(JpegImageParser.java:295)
   at 
 org.apache.commons.imaging.formats.jpeg.JpegImageParser.getImageInfo(JpegImageParser.java:668)
   at org.apache.commons.imaging.Imaging.getImageInfo(Imaging.java:683)
   at org.apache.commons.imaging.Imaging.getImageInfo(Imaging.java:615)
 {code}
 Further research showed that these images usually are made with a certain 
 type of camera. I have searched flicker and found a image which shows the 
 same problems. (This image does not belong to me, but I guess this should be 
 fine for testing purposes)
 http://www.flickr.com/photos/sara-net/3880941727/sizes/o/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (IMAGING-90) ClassCastException: [I cannot be cast to java.lang.Number in TiffReader.readDirectory(TiffReader.java:239) and JpegImageParser

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IMAGING-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic resolved IMAGING-90.
-

   Resolution: Fixed
Fix Version/s: 1.0

Fixed by allowing for non-1 tag lengths in non-strict mode (and then ignoring 
those tags); getMetadata() should now work, and other methods may require 
explicitly setting strict mode to off. Thank you for your bug report.


 ClassCastException: [I cannot be cast to java.lang.Number in 
 TiffReader.readDirectory(TiffReader.java:239) and JpegImageParser
 --

 Key: IMAGING-90
 URL: https://issues.apache.org/jira/browse/IMAGING-90
 Project: Commons Imaging
  Issue Type: Bug
  Components: Format: JPEG
Affects Versions: 1.0
 Environment: jdk 1.6.0_33
Reporter: st.h
 Fix For: 1.0


 Version 1.0 rc2. (Checked the trunk, but couldn't find any commits concerning 
 this issue)
 When calling Imaging.getImageInfo on certain (in this case jpeg) images, 
 there might be a ClassCastException in TiffReader:239 if the entry is not a 
 Number.
 {code}
 int subDirectoryOffset = ((Number) entry.getValue())
 .intValue();
 {code}
 This may occur if the entry does not have any actual value. This is the entry 
 shown by the debugger:
 {code}
  40965 (0xa005: InteropOffset):  (0 Long)
 {code}
 A quick solution to this problem might be to check if entry.getValue() could 
 be cast to a Number before doing so. Probably there is a more elegant way, 
 but I haven't had the time to analyze this thoroughly.
 Here is the stack trace:
 {code}
 Caused by: java.lang.ClassCastException: [I cannot be cast to java.lang.Number
 at 
 org.apache.commons.imaging.formats.tiff.TiffReader.readDirectory(TiffReader.java:239)
 at 
 org.apache.commons.imaging.formats.tiff.TiffReader.readDirectory(TiffReader.java:253)
 at 
 org.apache.commons.imaging.formats.tiff.TiffReader.readDirectory(TiffReader.java:103)
 at 
 org.apache.commons.imaging.formats.tiff.TiffReader.readDirectories(TiffReader.java:95)
 at 
 org.apache.commons.imaging.formats.tiff.TiffReader.read(TiffReader.java:419)
 at 
 org.apache.commons.imaging.formats.tiff.TiffReader.readContents(TiffReader.java:410)
 at 
 org.apache.commons.imaging.formats.tiff.TiffImageParser.getMetadata(TiffImageParser.java:132)
 at 
 org.apache.commons.imaging.ImageParser.getMetadata(ImageParser.java:203)
 at 
 org.apache.commons.imaging.formats.jpeg.JpegImageParser.getExifMetadata(JpegImageParser.java:335)
 at 
 org.apache.commons.imaging.formats.jpeg.JpegImageParser.getMetadata(JpegImageParser.java:295)
 at 
 org.apache.commons.imaging.formats.jpeg.JpegImageParser.getImageInfo(JpegImageParser.java:668)
 at org.apache.commons.imaging.Imaging.getImageInfo(Imaging.java:683)
 at org.apache.commons.imaging.Imaging.getImageInfo(Imaging.java:615)
 {code}
 The same issue applies to similar uses of TiffField, for instance 
 JpegImageParser around line 676.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (IMAGING-93) Tiled TIFF images do not correctly load partial tiles

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IMAGING-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic resolved IMAGING-93.
-

   Resolution: Fixed
Fix Version/s: 1.0

Applied, resolving fixed. Thank you for your patch!

 Tiled TIFF images do not correctly load partial tiles
 -

 Key: IMAGING-93
 URL: https://issues.apache.org/jira/browse/IMAGING-93
 Project: Commons Imaging
  Issue Type: Bug
  Components: Format: TIFF
Affects Versions: 1.0
Reporter: Gary Lucas
 Fix For: 1.0

 Attachments: LucasTrackerItem93_Oct14.patch


 For a tiled TIFF file in which the tile size does not evenly divide the width 
 or height of the image, the partial tiles (last row or column) are not being 
 populated.  This occurs only for 24-bit RGB format images.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (IMAGING-94) Add ability to load partial TIFF images

[Damjan Jovanovic (JIRA)]

[ 
https://issues.apache.org/jira/browse/IMAGING-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13483490#comment-13483490
 ] 

Damjan Jovanovic commented on IMAGING-94:
-

Hi Gary

Wow what a patch :).

In this section, is there some reason you don't use System.arraycopy()? That 
should be even faster than looping and copying 2 values at a time.

{code}
+// Transcribe the data.  In this code block, there is a small
+// amount of loop unrolling.  In testing, unrolling saves about 25 
+// percent load time for large subimages.  2/3 of the cost of reading
+// the subimage is in the transcription of data.
+int[] argb = new int[w * h];
+int k = 0;
+int w2 = w / 2;
+for (int iRow = 0; iRow  h; iRow++) {
+int dIndex = (iRow + y) * width + x;
+for (int j = 0; j  w2; j++) {
+argb[k++] = this.data[dIndex++];
+argb[k++] = this.data[dIndex++];
+}
+if ((w  1) != 0) {
+// there's an odd number of columns
+argb[k++] = this.data[dIndex++];
+}
+}
{code}

 Add ability to load partial TIFF images
 ---

 Key: IMAGING-94
 URL: https://issues.apache.org/jira/browse/IMAGING-94
 Project: Commons Imaging
  Issue Type: New Feature
  Components: Format: TIFF
Reporter: Gary Lucas
 Attachments: LucasTrackerItem94_Oct14.patch


 For most Apache Commons Imaging applications, the easiest way to obtain a sub 
 image from a file is to simply use the Imaging class to load it as a 
 BufferedImage and then use BufferedImage’s getSubimage() method to extract 
 the portion of the image you wish to use.  The TIFF format presents a special 
 problem because it is very common to have huge images (100’s or even 1000’s 
 of megapixel).  Examples include Landsat satellite images, global-scale 
 GeoTIFF images, etc.  In such cases, loading the entire image into memory is 
 not practical because it would require too much memory.  For example, I am 
 currently working with a 21600 by 10800 image that requires more than 890 
 megabytes to store as a BufferedImage.  That value is pushing the limit of 
 what I can configure Java to handle on my particular OS.
 I propose to implement features for TIFF files that would permit Commons 
 Imaging to load a partial image of a TIFF file using only the amount memory 
 actually needed to hold the sub-image.
 These changes would not interfere with normal operations of TIFF files and 
 would not affect other image formats.  If there were a need for similar 
 features for other image formats, they could be phased in through future 
 changes.
 The specification for a sub-image would be through the use of the params 
 argument in the getBufferedImage call as follows:
 HashMapString, Object params = new HashMapString, Object();
 params.put(TiffConstants.PARAM_KEY_SUBIMAGE_X, new Integer( x ));
 params.put(TiffConstants.PARAM_KEY_SUBIMAGE_Y, new Integer( y ));
 params.put(TiffConstants.PARAM_KEY_SUBIMAGE_WIDTH, new 
 Integer(width));
 params.put(TiffConstants.PARAM_KEY_SUBIMAGE_HEIGHT, new 
 Integer(height));

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (IMAGING-96) Full exif tag description ?

[Damjan Jovanovic (JIRA)]

[ 
https://issues.apache.org/jira/browse/IMAGING-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13482963#comment-13482963
 ] 

Damjan Jovanovic commented on IMAGING-96:
-

Through what API?

You can already do this:
{code}
TiffDirectory tiffDirectory = ...
int exposureProgram = 
tiffDirectory.getSingleFieldValue(ExifTagConstants.EXIF_TAG_EXPOSURE_PROGRAM);
switch (exposureProgram) {
case EXPOSURE_PROGRAM_VALUE_MANUAL: return manual;
}
{code}

 Full exif tag description  ?
 

 Key: IMAGING-96
 URL: https://issues.apache.org/jira/browse/IMAGING-96
 Project: Commons Imaging
  Issue Type: Question
  Components: Format: JPEG
Reporter: Piotr Czajka

 Is it possible to get a full exif tag description ?
 e.g.
 Simple output from Imaging:
 //...
 ExposureProgram : 1 
 //...
 In exif tagg spec. I found :
 ExposureProgram
 The specification defines these values:
 0 = Not defined
 1 = Manual
 2 = Normal program
 3 = Aperture priority
 4 = Shutter priority
 5 = Creative program (biased toward depth of field)
 6 = Action program (biased toward fast shutter speed)
 7 = Portrait mode (for closeup photos with the background out of focus)
 8 = Landscape mode (for landscape photos with the background in focus) 
 Can I receive description in that form : 
 ExposureProgram : Manual  ?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (IMAGING-91) ByteSourceInputStream.streamLength could be a long

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IMAGING-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic resolved IMAGING-91.
-

   Resolution: Fixed
Fix Version/s: 1.0

Thank you, it's fixed now :).

 ByteSourceInputStream.streamLength could be a long
 --

 Key: IMAGING-91
 URL: https://issues.apache.org/jira/browse/IMAGING-91
 Project: Commons Imaging
  Issue Type: Improvement
Reporter: Sebb
Priority: Trivial
 Fix For: 1.0


 ByteSourceInputStream.streamLength is currently a Long.
 Since it has to be positive, it could be converted to an long, e.g. using -1 
 as the equivalent of null.
 This would save some boxing/unboxing and instance creation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (IMAGING-95) Some tiff processing takes very long

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IMAGING-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic resolved IMAGING-95.
-

   Resolution: Fixed
Fix Version/s: 1.0

Fixed. Thank you for your patch!


 Some tiff processing takes very long
 

 Key: IMAGING-95
 URL: https://issues.apache.org/jira/browse/IMAGING-95
 Project: Commons Imaging
  Issue Type: Bug
  Components: Format: TIFF
Affects Versions: 1.0
Reporter: Amit Gupta
 Fix For: 1.0

 Attachments: tiff_perf_fix2.patch


 org.apache.commons.imaging.formats.tiff.TiffReader.getTiffRawImageData(ByteSource,
  TiffDirectory) 226635  1
 org.apache.commons.imaging.common.bytesource.ByteSourceInputStream.getBlock(int,
  int) 226588  5616
 org.apache.commons.imaging.common.BinaryFileFunctions.skipBytes(InputStream, 
 int) 226526  5616
 org.apache.commons.imaging.common.BinaryFileFunctions.skipBytes(InputStream, 
 int, String) 226526  5616
 org.apache.commons.imaging.common.bytesource.ByteSourceInputStream$CacheReadingInputStream.read(byte[],
  int, int) 226526  188656860
 org.apache.commons.imaging.common.bytesource.ByteSourceInputStream$CacheBlock.getNext()
64581   188651244
 skip bytes is being called repeatedly again and again, last column is 
 invocation count in one call tree. Second column is total number of time 
 taken by that method in that call tree..
 and skip method is not overridden 
 org.apache.commons.imaging.common.bytesource.ByteSourceInputStream.CacheReadingInputStream
  and default implementation of InputStream tries to use read method (which is 
 overridden in CacheReadingInputStream) to skip. 
 In case of a tiff, which has large number of strips, skip is repeatedly 
 called and use of read is inefficient as it tried to do a System.arraycopy. 
 array copy is not needed in case of skip operation, as the bytes were already 
 read in block/cached, we can simply jump the pointer (block by block)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (IMAGING-92) Issue trying to update GPS metadata info in a JPG

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IMAGING-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic resolved IMAGING-92.
-

   Resolution: Fixed
Fix Version/s: 1.0

Fix committed, thank you!


 Issue trying to update GPS metadata info in a JPG
 -

 Key: IMAGING-92
 URL: https://issues.apache.org/jira/browse/IMAGING-92
 Project: Commons Imaging
  Issue Type: Bug
  Components: Format: JPEG
Affects Versions: 1.0
 Environment: Windows 7, Java 1.6
Reporter: Herve M.
 Fix For: 1.0

 Attachments: IMAGING-92.patch


 I'm trying to update the GPS metadata of pictures done with a Canon SX 230HS
 using the code on trunk (0.98)
 CODE : 
 File original = new File(D:\\IMG_0772.JPG);
 MetadataExample.metadataExample(original);
 File newFile = new File(D:\\IMG_0772NEW.JPG);
 new WriteExifMetadataExample().setExifGPSTag(original, newFile);
 MetadataExample.metadataExample(newFile);
 We can see that that the Metadata is not set correctly.
 I tried with pictures from an IPhone - same issue.
 OUTPUT :
 file: D:\IMG_0772.JPG
 XResolution: 180
 DateTime: '2012:10:03 20:37:18'
 DateTimeOriginal: '2012:10:03 20:37:18'
 DateTimeDigitized: '2012:10:03 20:37:18'
 PhotographicSensitivity: 800
 ShutterSpeedValue: 189/32 (5.906)
 ApertureValue: 104/32 (3.25)
 BrightnessValue: Not Found.
 GPSLatitudeRef: 'N'
 GPSLatitude: 36, 49, 2935/1000 (2.935)
 GPSLongitudeRef: 'E'
 GPSLongitude: 31, 17, 59291/1000 (59.291)
 GPS Description: [GPS. Latitude: 36 degrees, 49 minutes, 2.935 seconds N, 
 Longitude: 31 degrees, 17 minutes, 59.291 seconds E]
 GPS Longitude (Degrees East): 31.29980305557
 GPS Latitude (Degrees North): 36.81748194445
 GPS Latitude: 36 degrees, 49 minutes, 2.935 seconds N
 GPS Longitude: 31 degrees, 17 minutes, 59.291 seconds E
 item: ImageDescription: ''
 item: Make: 'Canon'
 item: Model: 'Canon PowerShot SX230 HS'
 item: Orientation: 6
 item: XResolution: 180
 item: YResolution: 180
 item: ResolutionUnit: 2
 item: DateTime: '2012:10:03 20:37:18'
 item: YCbCrPositioning: 2
 item: ExifOffset: 252
 item: GPSInfo: 4900
 item: ExposureTime: 1/60 (0.017)
 item: FNumber: 31/10 (3.1)
 item: PhotographicSensitivity: 800
 item: Unknown Tag (0x8830): 4
 item: ExifVersion: 48, 50, 51, 48
 item: DateTimeOriginal: '2012:10:03 20:37:18'
 item: DateTimeDigitized: '2012:10:03 20:37:18'
 item: ComponentsConfiguration: 1, 2, 3, 0
 item: CompressedBitsPerPixel: 3
 item: ShutterSpeedValue: 189/32 (5.906)
 item: ApertureValue: 104/32 (3.25)
 item: ExposureCompensation: 0
 item: MaxApertureValue: 104/32 (3.25)
 item: MeteringMode: 5
 item: Flash: 89
 item: FocalLength: 5
 item: MakerNote: 29, 0, 1, 0, 3, 0, 48, 0, 0, 0, 112, 4, 0, 0, 3, 0, 3, 
 0, 4, 0, 0, 0, -48, 4, 0, 0, 4, 0, 3, 0, 34, 0, 0, 0, -40, 4, 0, 0, 6, 0, 2, 
 0, 28, 0, 0, 0, 28, 5, 0, 0, 7... (3800)
 item: UserComment: ''
 item: FlashpixVersion: 48, 49, 48, 48
 item: ColorSpace: 1
 item: ExifImageWidth: 4000
 item: ExifImageLength: 2248
 item: InteropOffset: 4822
 item: FocalPlaneXResolution: 400/244 (16'393.443)
 item: FocalPlaneYResolution: 300/183 (16'393.443)
 item: FocalPlaneResolutionUnit: 2
 item: SensingMethod: 2
 item: FileSource: 3
 item: CustomRendered: 0
 item: ExposureMode: 0
 item: WhiteBalance: 0
 item: DigitalZoomRatio: 1
 item: SceneCaptureType: 0
 item: InteroperabilityIndex: 'R98'
 item: InteroperabilityVersion: 48, 49, 48, 48
 item: RelatedImageWidth: 4000
 item: RelatedImageLength: 2248
 item: GPSLatitudeRef: 'N'
 item: GPSLatitude: 36, 49, 2935/1000 (2.935)
 item: GPSLongitudeRef: 'E'
 item: GPSLongitude: 31, 17, 59291/1000 (59.291)
 item: GPSTimeStamp: 17, 37, 16936/1000 (16.936)
 item: GPSStatus: 'A'
 item: GPSMapDatum: 'WGS-84'
 item: GPSDateStamp: '2012:10:03'
 item: Compression: 6
 item: XResolution: 180
 item: YResolution: 180
 item: ResolutionUnit: 2
 item: JpgFromRawStart: 5620
 item: JpgFromRawLength: 4254
 file: D:\IMG_0772NEW.JPG
 XResolution: 180
 DateTime: '2012:10:03 20:37:18'
 DateTimeOriginal: '2012:10:03 20:37:18'
 DateTimeDigitized: '2012:10:03 20:37:18'
 PhotographicSensitivity: 800
 ShutterSpeedValue: 189/32 (5.906)
 ApertureValue: 104/32 (3.25)
 BrightnessValue: Not Found.
 GPSLatitudeRef: Not Found.
 GPSLatitude: 40, 43, 1/2147483647 (0)
 GPSLongitudeRef: Not Found.
 GPSLongitude: Not Found.
 item: ImageDescription: ''
 item: Make: 'Canon'
 item: Model: 'Canon PowerShot SX230 HS'
 item: Orientation: 6
 item: XResolution: 180
 item: YResolution: 180
 item: ResolutionUnit: 2
 

[jira] [Commented] (IMAGING-89) Detect the YCCK color space/type

[Damjan Jovanovic (JIRA)]

[ 
https://issues.apache.org/jira/browse/IMAGING-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13457582#comment-13457582
 ] 

Damjan Jovanovic commented on IMAGING-89:
-

Well assuming you're unhappy with:

{code}
ListSegment segments = jpegImageParser.readSegments(byteSource,
new int[] { JPEG_APP14_Marker, }, false);

if ((segments == null) || (segments.size()  1)) {
// No APP14
} else {
// ...
}
{code}

what API would you propose instead?


 Detect the YCCK color space/type
 

 Key: IMAGING-89
 URL: https://issues.apache.org/jira/browse/IMAGING-89
 Project: Commons Imaging
  Issue Type: New Feature
  Components: Format: JPEG
Affects Versions: 1.x
Reporter: Arthur Bogaart
Priority: Minor
 Fix For: 1.0

 Attachments: test-YCCK.jpg


 I use Sanselan/CommonsImaging to detect if uploaded images are in the RGB 
 color space, and if not convert them to RGB.
 Currently, CI marks jpg images in the YCCK color space as CMYK:
 ImageInfo info = Imaging.getImageInfo(is, YCCK.jpg);
 info.getColorType() == ImageInfo.COLOR_TYPE_CMYK
 So I have to do a custom check afterwards to differ between YCCK and CMYK.
 I use the following to do this:
 import com.drew.imaging.jpeg.JpegSegmentReader;
 JpegSegmentReader reader = new JpegSegmentReader(is);
 byte[] appe = reader.readSegment(JpegSegmentReader.SEGMENT_APPE);
 bool isYCCK = appe != null  appe[11] == 2;
 Would it be possible to incorporate this into CommonsImaging?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (IMAGING-89) Detect the YCCK color space/type

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IMAGING-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic resolved IMAGING-89.
-

   Resolution: Fixed
Fix Version/s: 1.0

I've just committed a fix for this to the latest SVN. Imaging.getImageInfo() 
will now distinguish the YCCK colorspace based on the App14 segment.

Resolving fixed.


 Detect the YCCK color space/type
 

 Key: IMAGING-89
 URL: https://issues.apache.org/jira/browse/IMAGING-89
 Project: Commons Imaging
  Issue Type: New Feature
  Components: Format: JPEG
Affects Versions: 1.x
Reporter: Arthur Bogaart
Priority: Minor
 Fix For: 1.0

 Attachments: test-YCCK.jpg


 I use Sanselan/CommonsImaging to detect if uploaded images are in the RGB 
 color space, and if not convert them to RGB.
 Currently, CI marks jpg images in the YCCK color space as CMYK:
 ImageInfo info = Imaging.getImageInfo(is, YCCK.jpg);
 info.getColorType() == ImageInfo.COLOR_TYPE_CMYK
 So I have to do a custom check afterwards to differ between YCCK and CMYK.
 I use the following to do this:
 import com.drew.imaging.jpeg.JpegSegmentReader;
 JpegSegmentReader reader = new JpegSegmentReader(is);
 byte[] appe = reader.readSegment(JpegSegmentReader.SEGMENT_APPE);
 bool isYCCK = appe != null  appe[11] == 2;
 Would it be possible to incorporate this into CommonsImaging?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (IMAGING-88) Method lowerBound in org.apache.commons.imaging.common.itu_t4.T4AndT6Compression has a division error

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IMAGING-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic resolved IMAGING-88.
-

   Resolution: Fixed
Fix Version/s: 1.0

Patch applied to SVN, thank you for your contribution!

 Method lowerBound in 
 org.apache.commons.imaging.common.itu_t4.T4AndT6Compression has a division 
 error
 -

 Key: IMAGING-88
 URL: https://issues.apache.org/jira/browse/IMAGING-88
 Project: Commons Imaging
  Issue Type: Bug
  Components: Format: TIFF
Affects Versions: 1.0
Reporter: Craig Kelly
 Fix For: 1.0


 In method lowerBound in the class 
 org.apache.commons.imaging.common.itu_t4.T4AndT6Compression, the binary 
 search loop uses:
 int middle = (first + last)  2;
 To find a mid-point for the search.  However, the bit-shift is causing a 
 divide by 4.  At best this produces bad results, and at worst causes an 
 infinite loop (which is how I found the error). A simple patch to fix is:
 Index: 
 src/main/java/org/apache/commons/imaging/common/itu_t4/T4AndT6Compression.java
 ===
 --- 
 src/main/java/org/apache/commons/imaging/common/itu_t4/T4AndT6Compression.java
 (revision 1363019)
 +++ 
 src/main/java/org/apache/commons/imaging/common/itu_t4/T4AndT6Compression.java
 (working copy)
 @@ -720,7 +720,7 @@
  int first = 0;
  int last = entries.length - 1;
  do {
 -int middle = (first + last)  2;
 +int middle = (first + last)  1; //2;
  if (entries[middle].value.intValue() = value
   ((middle + 1) = entries.length || value  
 entries[middle + 1].value
  .intValue())) {

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (IMAGING-55) Add ability to insert comments when writing images.

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IMAGING-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic resolved IMAGING-55.
-

Resolution: Later

Deferring to after the 1.0 release.

 Add ability to insert comments when writing images.
 ---

 Key: IMAGING-55
 URL: https://issues.apache.org/jira/browse/IMAGING-55
 Project: Commons Imaging
  Issue Type: New Feature
Reporter: Charles Matthew Chen



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (IMAGING-53) Add Ability to Write Multiple Images to Gif, Tiff

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IMAGING-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic resolved IMAGING-53.
-

Resolution: Later

Deferring to after the 1.0 release.

 Add Ability to Write Multiple Images to Gif, Tiff
 -

 Key: IMAGING-53
 URL: https://issues.apache.org/jira/browse/IMAGING-53
 Project: Commons Imaging
  Issue Type: New Feature
Reporter: Charles Matthew Chen

 With GIF, should be able to specify the timing information around images 
 for animated gifs, as well as to set up looping animations.
 With Tiff, should support writing both related (primary image, large 
 thumbnail, small thumbnail, etc.) images and unrelated images to a single 
 file.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (IMAGING-85) Rename src/test/data directory to src/test/resources to comply with maven conventions

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IMAGING-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic resolved IMAGING-85.
-

Resolution: Later

Deferring to after the 1.0 release.

 Rename src/test/data directory to src/test/resources to comply with maven 
 conventions
 -

 Key: IMAGING-85
 URL: https://issues.apache.org/jira/browse/IMAGING-85
 Project: Commons Imaging
  Issue Type: Improvement
Reporter: Farrukh Najmi
 Attachments: SANSELAN-83-patch.txt


 Currently established maven convention is not being following because test 
 resources being placed under src/test/data instead of src/test/resources 
 directory. This causes problems is maven-jar-plugin and possibly other 
 situations. Proposed patch for IMAGING-84 will not work until the proposed 
 fix for this issues is addressed.
 The proposed fix is to rename src/test/data to src/test/resources and apply 
 the following patch to fix test code that setsup path for test data files:
 {code}
 Index: src/test/java/org/apache/commons/imaging/ImagingTestConstants.java
 ===
 --- src/test/java/org/apache/commons/imaging/ImagingTestConstants.java  
 (revision 1354112)
 +++ src/test/java/org/apache/commons/imaging/ImagingTestConstants.java  
 (working copy)
 @@ -24,12 +24,12 @@
  
  static final File PHIL_HARVEY_TEST_IMAGE_FOLDER = new File(
  FilenameUtils
 -
 .separatorsToSystem(src\\test\\data\\images\\exif\\philHarvey\\));
 +
 .separatorsToSystem(src\\test\\resources\\images\\exif\\philHarvey\\));
  
  static final File SOURCE_FOLDER = new File(src);
  static final File TEST_SOURCE_FOLDER = new File(SOURCE_FOLDER, test);
  static final File TEST_DATA_SOURCE_FOLDER = new File(TEST_SOURCE_FOLDER,
 -data);
 +resources);
  static final File TEST_IMAGE_FOLDER = new File(TEST_DATA_SOURCE_FOLDER,
  images);
  }
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (IMAGING-25) integer overflow unhandled

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IMAGING-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic resolved IMAGING-25.
-

Resolution: Later

Deferring to after the 1.0 release.

 integer overflow unhandled
 --

 Key: IMAGING-25
 URL: https://issues.apache.org/jira/browse/IMAGING-25
 Project: Commons Imaging
  Issue Type: Bug
  Components: Format: JPEG
Affects Versions: 0.94-incubator
 Environment: win32, 32 bit operating systems
Reporter: Greg Squires
 Attachments: concat-app13.patch, crash.jpeg

   Original Estimate: 24h
  Remaining Estimate: 24h

 This function can throw an Exception in ByteSourceArray.java due to a 
 negative byte[] allocation size. The length argument has been found to wrap 
 when called from IccProfileParser.java.
 In 64bit machines, issues related to incorrect metadata, or ICC data can lead 
 to incorrect and excess memory allocations. These large numbers however cause 
 32bit negative signed values.
   public byte[] getBlock(int start, int length) throws IOException
   {
   if (start + length  bytes.length)
   throw new IOException(Could not read block (block 
 start:  + start
   + , block length:  + length + , data 
 length: 
   + bytes.length + ).);
   byte result[] = new byte[length];
   System.arraycopy(bytes, start, result, 0, length);
   return result;
   }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (IMAGING-72) Improve logging calls

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IMAGING-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic resolved IMAGING-72.
-

Resolution: Later

Deferring to after the 1.0 release.

 Improve logging calls
 -

 Key: IMAGING-72
 URL: https://issues.apache.org/jira/browse/IMAGING-72
 Project: Commons Imaging
  Issue Type: Improvement
 Environment: 0.97-incubator
Reporter: Vincent Siveton

 Actually, when building the Shindig project, some undesirable stacktrace are 
 displayed [1].
 The org.apache.sanselan.util.Debug class is not configurable at all.  It 
 could be nice to use a logging API like commons logging.
 [1] http://hudson.zones.apache.org/hudson/view/Shindig/job/Shindig/433/console

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (IMAGING-34) Tiffreader fails if rows per strip and imageheight both are absent

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IMAGING-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic resolved IMAGING-34.
-

Resolution: Later

No response, probably not a problem, but deferring to after the 1.0 release 
anyway.

 Tiffreader fails if rows per strip and imageheight both are absent 
 ---

 Key: IMAGING-34
 URL: https://issues.apache.org/jira/browse/IMAGING-34
 Project: Commons Imaging
  Issue Type: Bug
Reporter: Piyush Kapoor
Priority: Minor
 Attachments: Tiffreader.patch, Tiffreader.patch, Tiffreader.patch


 If rowsperstrip is not present in Tiff files , we take imageHeight value as 
 rows per strip value. Currently if imageheight is not present then Np occurs ,
 Added some checks to safely run the process .

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (IMAGING-86) TagInfoAscii Error

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IMAGING-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic resolved IMAGING-86.
-

   Resolution: Fixed
Fix Version/s: 1.0

The problem was that EXIF_TAG_DATE_TIME_ORIGINAL and 
EXIF_TAG_DATE_TIME_DIGITIZED had the wrong length (1 instead of 20). I've fixed 
it in the latest SVN. Thank you for your bug report!


 TagInfoAscii Error
 --

 Key: IMAGING-86
 URL: https://issues.apache.org/jira/browse/IMAGING-86
 Project: Commons Imaging
  Issue Type: Bug
  Components: Format: TIFF
Affects Versions: 0.97
Reporter: dev.shoon
  Labels: patch
 Fix For: 1.0

 Attachments: patch.txt


 Some TagInfoAscii Error
 Check attachment

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (IMAGING-87) [Sanselan] Writing new gps values to jpeg.

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IMAGING-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic resolved IMAGING-87.
-

Resolution: Not A Problem

Imaging currently don't modify the EXIF GPS lat/long (or any other EXIF for 
that matter) in-place, it has to write a new copy.

However, you can read the file contents into a byte array, and use the method 
that takes a byte array, and specify the original file name as the file to 
write to. This will overwrite the original file with the updated version 
instead of generating a new file.


 [Sanselan] Writing new gps values to jpeg. 
 ---

 Key: IMAGING-87
 URL: https://issues.apache.org/jira/browse/IMAGING-87
 Project: Commons Imaging
  Issue Type: Question
  Components: Format: JPEG
Reporter: Piotr Czajka
  Labels: newbie

 Hello :)
 I want to edit GPS tag and save new GPS latitude and longitude to jpeg.
 I tried to use code from this example 
 http://massapi.com/source/sanselan-0.97-incubator/src/test/java/org/apache/sanselan/sampleUsage/WriteExifMetadataExample.java.html
  
 Ok it works but it creates a new jpeg photo with new gps values.. but I would 
 like to save new values to the same photo. How I can do this ?
 Generally I want to create application similar to Picasa (photo viewer + 
 google maps) .. and in this case when I drag and drop marker on map I want to 
 save new gps exif metadata to photo.. so according with this example it will 
 be create new photo every time?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (IMAGING-86) TagInfoAscii Error

[Damjan Jovanovic (JIRA)]

[ 
https://issues.apache.org/jira/browse/IMAGING-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13414671#comment-13414671
 ] 

Damjan Jovanovic commented on IMAGING-86:
-

DateTime has to have a specific format: “:MM:DD HH:MM:SS”, which is 20 
characters long, including the terminating null. This is according to the TIFF 
specification. The current code is by design and should work.

What is the real problem you are having?


 TagInfoAscii Error
 --

 Key: IMAGING-86
 URL: https://issues.apache.org/jira/browse/IMAGING-86
 Project: Commons Imaging
  Issue Type: Bug
  Components: Format: TIFF
Affects Versions: 0.97
Reporter: dev.shoon
  Labels: patch
 Attachments: patch.txt


 Some TagInfoAscii Error
 Check attachment

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (IMAGING-56) Add support for the ICNS icon format

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IMAGING-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic updated IMAGING-56:


Fix Version/s: 1.0

 Add support for the ICNS icon format
 

 Key: IMAGING-56
 URL: https://issues.apache.org/jira/browse/IMAGING-56
 Project: Commons Imaging
  Issue Type: New Feature
 Environment: All
Reporter: Damjan Jovanovic
Priority: Minor
 Fix For: 1.0

 Attachments: icns-images.tar.bz2, sanselan-icns.patch

   Original Estimate: 0h
  Remaining Estimate: 0h

 I am submitting a patch that adds support for the Apple ICNS icon format. It 
 supports reading, writing, getting the image info, and dumping the icons, and 
 contains insightful tests.
 This is, to my knowledge, the most correct open source ICNS parser in 
 existence at the moment, and the only one to contain any detailed tests. It 
 deals with an extensively investigated compression quirk in 128x128 images, 
 uses the same alpha mask search order used by MacOS, and has been thoroughly 
 tested for conformance against MacOS itself. It correctly parses all the ICNS 
 files that ship with MacOS.
 The only missing feature is support for 256x256 and 512x512 icons, but that 
 requires JPEG2000 decompression which Sanselan doesn't have at the moment.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (IMAGING-56) Add support for the ICNS icon format

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IMAGING-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic updated IMAGING-56:


Fix Version/s: (was: 0.94-incubator)

 Add support for the ICNS icon format
 

 Key: IMAGING-56
 URL: https://issues.apache.org/jira/browse/IMAGING-56
 Project: Commons Imaging
  Issue Type: New Feature
 Environment: All
Reporter: Damjan Jovanovic
Priority: Minor
 Fix For: 1.0

 Attachments: icns-images.tar.bz2, sanselan-icns.patch

   Original Estimate: 0h
  Remaining Estimate: 0h

 I am submitting a patch that adds support for the Apple ICNS icon format. It 
 supports reading, writing, getting the image info, and dumping the icons, and 
 contains insightful tests.
 This is, to my knowledge, the most correct open source ICNS parser in 
 existence at the moment, and the only one to contain any detailed tests. It 
 deals with an extensively investigated compression quirk in 128x128 images, 
 uses the same alpha mask search order used by MacOS, and has been thoroughly 
 tested for conformance against MacOS itself. It correctly parses all the ICNS 
 files that ship with MacOS.
 The only missing feature is support for 256x256 and 512x512 icons, but that 
 requires JPEG2000 decompression which Sanselan doesn't have at the moment.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (IMAGING-24) Fetching GPS Latitude Ref gets Interoperability Index instead of Reference

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IMAGING-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic updated IMAGING-24:


Fix Version/s: (was: 0.94-incubator)
   1.0

 Fetching GPS Latitude Ref gets Interoperability Index instead of Reference
 --

 Key: IMAGING-24
 URL: https://issues.apache.org/jira/browse/IMAGING-24
 Project: Commons Imaging
  Issue Type: Bug
Affects Versions: 0.94-incubator
 Environment: Windows XP SP3, java version 1.5.0_17
 apache-sanselan-incubating-0.97-bin.zip
Reporter: Christian Junk
Priority: Minor
 Fix For: 1.0

 Attachments: R0013102.jpg, geo1.jpg, sanselan-21.patch, 
 tiff-tag-exact-directory.patch


 When testing  the following example
 https://svn.apache.org/repos/asf/incubator/sanselan/trunk/src/test/java/org/apache/sanselan/sampleUsage/MetadataExample.java
 with apache-sanselan-incubating-0.97 it always stops working throwing a 
 ClassCastException. It seems, that the line 
 TiffField gpsLatitudeRefField = jpegMetadata
   
 .findEXIFValue(TiffConstants.GPS_TAG_GPS_LATITUDE_REF);
 returns the Interoperability Index (R98) instead of the GPS Latitude Ref.
 XResolution: 72
 Date Time: '2008:07:23 18:19:58'
 Date Time Original: '2008:07:23 10:05:21'
 Create Date: '2008:07:23 10:05:21'
 ISO: 64
 Shutter Speed Value: Not Found.
 Aperture Value: 6
 Brightness Value: 81/10 (8,1)
 GPS Latitude Ref: 'R98'  
  !!!
 GPS Latitude: 48, 49, 48, 48
 GPS Longitude Ref: 'E'
 GPS Longitude: 6, 38, 2061/100 (20,61)
 GPS Description: [GPS. Latitude: 49 degrees, 45 minutes, 34,18 seconds N, 
 Longitude: 6 degrees, 38 minutes, 20,61 seconds E]
   
 Exception in thread main java.lang.ClassCastException: [B
 at com.alta4.phasr.MetadataExample.metadataExample(MetadataExample.java:113)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (IMAGING-59) Initial code drop

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IMAGING-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic updated IMAGING-59:


Fix Version/s: (was: 0.97)
   0.94-incubator
 Assignee: (was: Carsten Ziegeler)

 Initial code drop
 -

 Key: IMAGING-59
 URL: https://issues.apache.org/jira/browse/IMAGING-59
 Project: Commons Imaging
  Issue Type: New Feature
Reporter: Craig L Russell
 Fix For: 0.94-incubator

 Attachments: patch_init.zip


 This issue is to discuss the initial code drop into the project.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (IMAGING-82) BMP Physical Width in inches and Physical Height in inches is wrong

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IMAGING-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic resolved IMAGING-82.
-

   Resolution: Fixed
Fix Version/s: 1.0

I've committed your patch.
Thank you!


 BMP Physical Width in inches and Physical Height in inches is wrong
 ---

 Key: IMAGING-82
 URL: https://issues.apache.org/jira/browse/IMAGING-82
 Project: Commons Imaging
  Issue Type: Bug
Reporter: Piyush Kapoor
 Fix For: 1.0

 Attachments: BMPimage.patch

   Original Estimate: 1m
  Remaining Estimate: 1m

 Hresolution and Vresolition are in pixels per meter . I have uploaded the 
 correct formula for calculating the Physical Width and Physical Height in 
 inches.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (IMAGING-81) Add more Javadoc to main package

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IMAGING-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic resolved IMAGING-81.
-

   Resolution: Fixed
Fix Version/s: 1.0
 Assignee: Damjan Jovanovic  (was: Luc Maisonobe)

Patch committed. Thank you for your contribution! Resolving fixed.


 Add more Javadoc to main package
 

 Key: IMAGING-81
 URL: https://issues.apache.org/jira/browse/IMAGING-81
 Project: Apache Commons Imaging
  Issue Type: Improvement
  Components: Documentation
Reporter: Gary Lucas
Assignee: Damjan Jovanovic
Priority: Minor
 Fix For: 1.0

 Attachments: Lucas_Javadoc_25_June_2012.patch


 The current version of the Apache Commons Imaging has minimal Javadoc.  While 
 the task of completely supplying Javadoc for the package would easily require 
 multiple man-months of effort, it would be useful to add information to at 
 least the top-level package and main classes. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (IMAGING-69) Streamlined TIFF strip reader reduces load time by a factor of 5

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IMAGING-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic resolved IMAGING-69.
-

   Resolution: Fixed
Fix Version/s: 1.0

Patch applied, thank you for your contribution.
Resolving fixed.


 Streamlined TIFF strip reader reduces load time by a factor of 5
 

 Key: IMAGING-69
 URL: https://issues.apache.org/jira/browse/IMAGING-69
 Project: Apache Commons Imaging
  Issue Type: Improvement
Reporter: Gary Lucas
 Fix For: 1.0

 Attachments: ApacheImagingTrackerItem69_May_30_2012.patch, 
 ApacheImagingTrackerItem69_May_9_2012.patch, 
 Sanselan-58-TiffStripReaderSpeed.patch, Tracker_Item_58_22_Apr_2012.patch

   Original Estimate: 1h
  Remaining Estimate: 1h

 Testing reveals that streamlining the DataReaderStrip.java operations for 8 
 and 24 bit-per-pixel TIFF images reduces the TIFF file load time by a factor 
 of 5.  
 For each pixel in images of these types, the interpretStrip() method of 
 DataReaderStrip makes calls to a generic bit extractor using its 
 getSamplesAsBytes() method.  Internally, this method simply copies the 
 requisite number of bytes (8 or 24), but it executes a lot of conditional 
 statements to do so.  Under most architectures, conditionals tend to take 2 
 to 3 times as long to execute as simple arithmetic statements, so this 
 approach is expensive (especially since an image may contain millions of 
 pixels).  While the implementation is very generic, the majority of TIFF 
 files out there appear to fall into two simple categories.  By implementing 
 specialized code for these two cases, the loading time for TIFF images is 
 dramatically reduced.
 The following snippet shows the code I used for testing.  It was added right 
 at the beginning of the interpretStrip() method.
  // Oct 2011 changes.
 //  The general case decoder is based on the idea of using a 
 //  generic bit-reader to unpack the number of bytes that are
 //  needed.  Although it is efficiently implemented, it does
 //  require performing at least three conditional branches per sample
 //  extracted (and often more).   This change attempts to bypass that
 //  overhead by implementing specialized blocks of extraction code
 //  for commonly used 8 bitsPerPixel and 24 bitsPerPixel cases.
 //  In other cases, it will simply fall through to the original code.
 //note that when promoting a byte to an integer, it is necessary
 //to mask it with 0xff because the Java byte type is signed
 //an this implementation requires an unsigned value
 if(x=width)
 {
 // this may not be required.  it was coded based on the 
 // original implementation.  But looking at the TIFF 6.0 spec,
 // it looks like the rows always evenly fill out the strip,
 // so there should never be a partial row in a strip and x
 // should not be anything except zero.
 x = 0;
 y++;
 }
 if(y=height)
 {
 // we check it once before starting, so that we don't have
 // to check it redundantly for each pixel
 return;
 }
 
 if(predictor==-1  this.bitsPerPixel==8)
 {
 int [] samples = new int[1];
 for(int i=0; ipixels_per_strip; i++)
 {
 samples[0] = bytes[i]0x00ff;
 photometricInterpreter.interpretPixel(bi, samples, x, y);
 x++;
 if(x=width)
 {
 x = 0;
 y++;
 if(y=height)
 return; // any remaining bytes are not needed
 }
 } 
 return;
 }
 else if(predictor==-1  this.bitsPerPixel==24)
 {
 int [] samples = new int[3];
 int k = 0;
 for(int i=0; ipixels_per_strip; i++)
 {
 samples[0] = bytes[k++]0x00ff;
 samples[1] = bytes[k++]0x00ff;
 samples[2] = bytes[k++]0x00ff;
 photometricInterpreter.interpretPixel(bi, samples, x, y);
 x++;
 if(x=width)
 {
 x = 0;
 y++;
 if(y=height)
 return; // any remaining bytes are not needed
 }
 }   
 return;
 }
 
 // original code before Oct 2011 modification
 ByteArrayInputStream bais = new ByteArrayInputStream(bytes);
 BitInputStream bis = new BitInputStream(bais);
 etc.

[jira] [Commented] (IMAGING-69) Streamlined TIFF strip reader reduces load time by a factor of 5

[Damjan Jovanovic (JIRA)]

[ 
https://issues.apache.org/jira/browse/IMAGING-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13286668#comment-13286668
 ] 

Damjan Jovanovic commented on IMAGING-69:
-

Thank you, but please reattach, this time clicking Grant license to ASF for 
inclusion in ASF works. I can't use it otherwise.


 Streamlined TIFF strip reader reduces load time by a factor of 5
 

 Key: IMAGING-69
 URL: https://issues.apache.org/jira/browse/IMAGING-69
 Project: Apache Commons Imaging
  Issue Type: Improvement
Reporter: Gary Lucas
 Attachments: ApacheImagingTrackerItem69_May_30_2012.patch, 
 ApacheImagingTrackerItem69_May_9_2012.patch, 
 Sanselan-58-TiffStripReaderSpeed.patch, Tracker_Item_58_22_Apr_2012.patch

   Original Estimate: 1h
  Remaining Estimate: 1h

 Testing reveals that streamlining the DataReaderStrip.java operations for 8 
 and 24 bit-per-pixel TIFF images reduces the TIFF file load time by a factor 
 of 5.  
 For each pixel in images of these types, the interpretStrip() method of 
 DataReaderStrip makes calls to a generic bit extractor using its 
 getSamplesAsBytes() method.  Internally, this method simply copies the 
 requisite number of bytes (8 or 24), but it executes a lot of conditional 
 statements to do so.  Under most architectures, conditionals tend to take 2 
 to 3 times as long to execute as simple arithmetic statements, so this 
 approach is expensive (especially since an image may contain millions of 
 pixels).  While the implementation is very generic, the majority of TIFF 
 files out there appear to fall into two simple categories.  By implementing 
 specialized code for these two cases, the loading time for TIFF images is 
 dramatically reduced.
 The following snippet shows the code I used for testing.  It was added right 
 at the beginning of the interpretStrip() method.
  // Oct 2011 changes.
 //  The general case decoder is based on the idea of using a 
 //  generic bit-reader to unpack the number of bytes that are
 //  needed.  Although it is efficiently implemented, it does
 //  require performing at least three conditional branches per sample
 //  extracted (and often more).   This change attempts to bypass that
 //  overhead by implementing specialized blocks of extraction code
 //  for commonly used 8 bitsPerPixel and 24 bitsPerPixel cases.
 //  In other cases, it will simply fall through to the original code.
 //note that when promoting a byte to an integer, it is necessary
 //to mask it with 0xff because the Java byte type is signed
 //an this implementation requires an unsigned value
 if(x=width)
 {
 // this may not be required.  it was coded based on the 
 // original implementation.  But looking at the TIFF 6.0 spec,
 // it looks like the rows always evenly fill out the strip,
 // so there should never be a partial row in a strip and x
 // should not be anything except zero.
 x = 0;
 y++;
 }
 if(y=height)
 {
 // we check it once before starting, so that we don't have
 // to check it redundantly for each pixel
 return;
 }
 
 if(predictor==-1  this.bitsPerPixel==8)
 {
 int [] samples = new int[1];
 for(int i=0; ipixels_per_strip; i++)
 {
 samples[0] = bytes[i]0x00ff;
 photometricInterpreter.interpretPixel(bi, samples, x, y);
 x++;
 if(x=width)
 {
 x = 0;
 y++;
 if(y=height)
 return; // any remaining bytes are not needed
 }
 } 
 return;
 }
 else if(predictor==-1  this.bitsPerPixel==24)
 {
 int [] samples = new int[3];
 int k = 0;
 for(int i=0; ipixels_per_strip; i++)
 {
 samples[0] = bytes[k++]0x00ff;
 samples[1] = bytes[k++]0x00ff;
 samples[2] = bytes[k++]0x00ff;
 photometricInterpreter.interpretPixel(bi, samples, x, y);
 x++;
 if(x=width)
 {
 x = 0;
 y++;
 if(y=height)
 return; // any remaining bytes are not needed
 }
 }   
 return;
 }
 
 // original code before Oct 2011 modification
 ByteArrayInputStream bais = new ByteArrayInputStream(bytes);
 BitInputStream 

[jira] [Resolved] (IMAGING-5) Broken documentation link on the web site

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IMAGING-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic resolved IMAGING-5.


Resolution: Fixed

Fixed in SVN trunk. Thank you for your bug report.


 Broken documentation link on the web site
 -

 Key: IMAGING-5
 URL: https://issues.apache.org/jira/browse/IMAGING-5
 Project: Apache Commons Imaging
  Issue Type: Bug
  Components: Documentation
Affects Versions: 0.97
Reporter: Ralph Louis Vinciguerra
Priority: Minor
  Labels: documentation
 Fix For: 1.0


 On this page: http://commons.apache.org/sanselan/
 the Documentation link in the left navigation box is broken, and leads to:
 Not Found
 The requested URL /SANSELAN/ was not found on this server.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (IMAGING-61) Include a test utility for timing and memory in project example classes

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IMAGING-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic resolved IMAGING-61.
-

   Resolution: Fixed
Fix Version/s: 1.0

Applied to SVN trunk.
Thank you for your contribution.


 Include a test utility for timing and memory in project example classes
 ---

 Key: IMAGING-61
 URL: https://issues.apache.org/jira/browse/IMAGING-61
 Project: Apache Commons Imaging
  Issue Type: New Feature
Reporter: Gary Lucas
Priority: Minor
 Fix For: 1.0

 Attachments: ApacheImagingSpeedAndMemoryTest.java


 For the convenience of developers, I've written a little test class for 
 measuring the time and memory required to load a file using Apache Imaging.  
 Code can be modified for use for other purposes (such as writing files, 
 etc.).I propse that this class be added to the examples in the Apache 
 Imaging code distribution.
 The Java file I've included with this upload includes a lot of explanation of 
 why I do certain things when I'm testing.  I don't claim that it's the last 
 word in testing procedures.  Really, it's more of a first word and lead to 
 further discussion and even more useful tools.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (IMAGING-70) Reduce memory use of TIFF readers

[Damjan Jovanovic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IMAGING-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damjan Jovanovic resolved IMAGING-70.
-

   Resolution: Fixed
Fix Version/s: 1.0

Thank you! Patch applied to SVN. Resolving fixed.


 Reduce memory use of TIFF readers
 -

 Key: IMAGING-70
 URL: https://issues.apache.org/jira/browse/IMAGING-70
 Project: Apache Commons Imaging
  Issue Type: Improvement
  Components: Format: TIFF
Reporter: Gary Lucas
 Fix For: 1.0

 Attachments: Tracker_76_Test_5_May_2012.patch

   Original Estimate: 80h
  Remaining Estimate: 80h

 This Tracker Item proposes changes to the TIFF file readers to address memory 
 issues when reading very large images from TIFF files.  The TIFF format is 
 used extensively in technical applications such as aerial photographs, 
 satellite images, and digital raster maps which feature very large image 
 sizes.  For example, the public-domain Natural Earth Data set features raster 
 files sized 21,600 by 10,800 pixels (222.5 megapixels).   Although this 
 example is unusually large, image sizes of 25 to 100 megapixels are common 
 for such applications.
 Unfortunately, when Sanselan reads a TIFF image, it consumes nearly twice as 
 much memory as is necessary.  The reader operates in two stages. First, it 
 reads the entire source file into memory then it builds the output image, 
 also in memory.   In the example file mentioned above, the source data runs 
 from 83.19 to 373 megabytes (depending on compression).   Thus Sanselan would 
 require a minimum of 83.19+4*222.5 = 985 megabytes to produce an image for 
 one of these files (allowing 4 bytes per pixel in the output BufferedImage)
 Fortunately, TIFF files are organized so that they can be read a piece at a 
 time.  TIFF files are divided into either strips or tiles and, if data 
 compression is used, each piece is compressed individually.  Thus each 
 individual piece has no dependency on the other. 
 This item proposes to implement two changes:
 1)  Allow the TIFF data reader to read the files one piece at a time while 
 constructing the buffered image.  Thus the memory use for reading would be no 
 larger than the piece size.  This would be an internal change, so the 
 external appearance of the Sanselan getBufferedImage methods would not change.
 2) Provide new API elements that permit applications to read the strips or 
 tiles from TIFF files individually. This change would support 
 applications that needed to access very large TIFF files without committing 
 the memory to store a BufferedImage for the entire file (a 222.5 megapixel 
 image requires 890 megabytes, which is a lot even by contemporary standards).
 There is one minor issue in this implementation that is easily addressed.  
 Sanselan reads images from ByteSources that can be either random-access files 
 or sequential-access input streams.  In the case of sequential-input streams, 
 it may be hard to perform a partial read on a TIFF directory.  In such a 
 case, the TIFF access routines might have to resort to reading the entire 
 source data into memory as it currently does.   This would simply be a 
 limitation of the implementation.
 There is one issue that may make this change a bit problematic.  The TIFF 
 processors depend on accessing a class called TiffDataElement that contains a 
 public array of bytes called data.   The most expeditious way of 
 implementing the enchancement is to make this element private and add an 
 accessor that either returns the data from internal memory or else loads it 
 on-demand.  Unfortunately, because the data element is scoped to public, 
 there is a chance that some existing applications are using it directly.   In 
 hindsight, it is clear that scoping this element as public was a mistake, but 
 it may be too late to fix it.  So care will be required to ensure that 
 compatibility remains.   The most likely solution seems to be to implement a 
 new class for passing raw data from the source TIFF files to the DataReader 
 implementations.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira