Re: [IMAGING] Cannot get to JavaDocs

[John Crowley]

Great, thanks.

John Crowley
Charlotte, NC
203-856-2396
j.crow...@computer.org






> On May 15, 2024, at 8:26 AM, Gary Gregory  wrote:
> 
> That's odd, I'll have a look this week, in the meantime, you can use the
> archives:
> 
> https://javadoc.io/doc/org.apache.commons/commons-imaging/latest/index.html
> 
> Gary
> 
> 
> 
> On Wed, May 15, 2024, 8:21 AM John Crowley  wrote:
> 
>> Hi all,
>> 
>> Was thinking of using the Imaging library in a current project.
>> 
>> Can find the project OK at
>> https://commons.apache.org/proper/commons-imaging/ - but the latest API
>> docs link results in a 404 not found
>> 
>> Also went to https://github.com/apache/commons-imaging - but the JavaDoc
>> link in the README also gives me a 404
>> 
>> Thanks,
>> 
>> John Crowley
>> Charlotte, NC
>> 203-856-2396
>> j.crow...@computer.org
>> 
>> 
>> 
>> 
>> 
>> 
>> 

Re: [IMAGING] Cannot get to JavaDocs

[Gary Gregory]

That's odd, I'll have a look this week, in the meantime, you can use the
archives:

https://javadoc.io/doc/org.apache.commons/commons-imaging/latest/index.html

Gary



On Wed, May 15, 2024, 8:21 AM John Crowley  wrote:

> Hi all,
>
> Was thinking of using the Imaging library in a current project.
>
> Can find the project OK at
> https://commons.apache.org/proper/commons-imaging/ - but the latest API
> docs link results in a 404 not found
>
> Also went to https://github.com/apache/commons-imaging - but the JavaDoc
> link in the README also gives me a 404
>
> Thanks,
>
> John Crowley
> Charlotte, NC
> 203-856-2396
> j.crow...@computer.org
>
>
>
>
>
>
>

[IMAGING] Cannot get to JavaDocs

[John Crowley]

Hi all,

Was thinking of using the Imaging library in a current project.

Can find the project OK at https://commons.apache.org/proper/commons-imaging/ - 
but the latest API docs link results in a 404 not found

Also went to https://github.com/apache/commons-imaging - but the JavaDoc link 
in the README also gives me a 404

Thanks,

John Crowley
Charlotte, NC
203-856-2396
j.crow...@computer.org

[ANNOUNCE] Apache Commons Imaging 1.0.0-alpha5

[Gary Gregory]

The Apache Commons Imaging team is pleased to announce the release of
Apache Commons Imaging 1.0.0-alpha5.

Apache Commons Imaging (previously Sanselan) is a pure-Java image library.

The 1.0.0-alpha5 release requires Java 8.

Historical list of changes:
https://commons.apache.org/proper/commons-imaging//changes-report.html

For complete information on Apache Commons Imaging, including
instructions on how to submit bug reports, patches, or suggestions for
improvement, see the Apache Commons Imaging website:

https://commons.apache.org/proper/commons-imaging/

Download page: 
https://commons.apache.org/proper/commons-imaging//download_text.cgi

Gary Gregory
- Apache Commons Team

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

[ANNOUNCE] Apache Commons Imaging 1.0.0-alpha4

[Gary Gregory]

The Apache Commons Imaging team is pleased to announce the release of
Apache Commons Imaging 1.0.0-alpha4.

Apache Commons Imaging (previously Sanselan) is a pure Java image library.

The 1.0.0-alpha4 release requires Java 8.

Historical list of changes:
https://commons.apache.org/proper/commons-imaging//changes-report.html

For complete information on Apache Commons Imaging, including
instructions on how to submit bug reports, patches, or suggestions for
improvement, see the Apache Commons Imaging website:

https://commons.apache.org/proper/commons-imaging/

Download page: 
https://commons.apache.org/proper/commons-imaging//download_text.cgi

Have fun!
Gary Gregory
- Apache Commons Team

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: RE: Re: release of commons-imaging

[Gary Gregory]

I'll see about creating a release candidate over the next few days.

Gary

On Fri, Mar 22, 2024, 6:07 AM William Borg Barthet <
william.borgbart...@bloomreach.com> wrote:

> Sorry to be a pain about this, is there any timeline for tagging/releasing
> a version of commons-imaging?
>
> Thanks again for your support.
>
> Regards,
>
> William
>
> On 2024/03/06 14:50:51 William Borg Barthet wrote:
> > Thanks for your replies.
> >
> > I am actually waiting on the WebP support. I found a PR and tested
> against
> > it and it seems to work for my purposes. I cannot really make use of a
> > SNAPSHOT, so any sort of tagged release, short of a 1.0 release would
> > suffice if it contained the WebP support.
> >
> > Thanks and regards
> >
> > William
> >
> > On 2024/02/28 15:43:06 Gary Gregory wrote:
> > > Yes: M is for milestone.
> > >
> > > Gary
> > >
> > > On Wed, Feb 28, 2024, 10:40 AM Bruno Kinoshita 
> > > wrote:
> > >
> > > > >
> > > > > Why not continue with experimental releases using the same scheme
> > > > > (i.e. "alpha", then "beta") with the agreed on semantics (that
> > > > > compatibility
> > > > > can be broken)?
> > > >
> > > >
> > > > Sounds good to me too, at least users wouldn't expect any difference
> > seeing
> > > > a new alphaN+1 announced. But not sure if there won't be any
> differences
> > > > with a milestone release (M is for milestone, right?)
> > > >
> > > > Cheers
> > > >
> > > > On Wed, 28 Feb 2024 at 16:11, Gilles Sadowski 
> > > > wrote:
> > > >
> > > > > Le mer. 28 févr. 2024 à 16:00, Bruno Kinoshita
> > > > >  a écrit :
> > > > > >
> > > > > > Hi Gary,
> > > > > >
> > > > > > What would be the main difference between the alpha and M1
> releases?
> > > > > >
> > > > > > I am not 100% confident that we have the public and protected API
> > > > right,
> > > > > > > specifically we might have too much public and protected. YMMV.
> > > > > >
> > > > > >
> > > > > > Agreed, and I think if we are to release anything, we would need
> > one or
> > > > > > more extra releases before we get everything right for the 1.0.
> But
> > if
> > > > we
> > > > > > can continue breaking backward compatibility (even though we will
> > try
> > > > > that
> > > > > > to only what's necessary to reduce impact to users) with
> M1/M2/M3,
> > the
> > > > > same
> > > > > > way we did with the alpha releases, then I'm +1 for that already.
> > > > >
> > > > > Why not continue with experimental releases using the same scheme
> > > > > (i.e. "alpha", then "beta") with the agreed on semantics (that
> > > > > compatibility
> > > > > can be broken)?
> > > > >
> > > > > > > > [...]
> > > > >
> > > > >
> -
> > > > > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> > > > > For additional commands, e-mail: user-h...@commons.apache.org
> > > > >
> > > > >
> > > >
> > >
> >
>

RE: RE: Re: release of commons-imaging

[William Borg Barthet]

Sorry to be a pain about this, is there any timeline for tagging/releasing
a version of commons-imaging?

Thanks again for your support.

Regards,

William

On 2024/03/06 14:50:51 William Borg Barthet wrote:
> Thanks for your replies.
>
> I am actually waiting on the WebP support. I found a PR and tested against
> it and it seems to work for my purposes. I cannot really make use of a
> SNAPSHOT, so any sort of tagged release, short of a 1.0 release would
> suffice if it contained the WebP support.
>
> Thanks and regards
>
> William
>
> On 2024/02/28 15:43:06 Gary Gregory wrote:
> > Yes: M is for milestone.
> >
> > Gary
> >
> > On Wed, Feb 28, 2024, 10:40 AM Bruno Kinoshita 
> > wrote:
> >
> > > >
> > > > Why not continue with experimental releases using the same scheme
> > > > (i.e. "alpha", then "beta") with the agreed on semantics (that
> > > > compatibility
> > > > can be broken)?
> > >
> > >
> > > Sounds good to me too, at least users wouldn't expect any difference
> seeing
> > > a new alphaN+1 announced. But not sure if there won't be any
differences
> > > with a milestone release (M is for milestone, right?)
> > >
> > > Cheers
> > >
> > > On Wed, 28 Feb 2024 at 16:11, Gilles Sadowski 
> > > wrote:
> > >
> > > > Le mer. 28 févr. 2024 à 16:00, Bruno Kinoshita
> > > >  a écrit :
> > > > >
> > > > > Hi Gary,
> > > > >
> > > > > What would be the main difference between the alpha and M1
releases?
> > > > >
> > > > > I am not 100% confident that we have the public and protected API
> > > right,
> > > > > > specifically we might have too much public and protected. YMMV.
> > > > >
> > > > >
> > > > > Agreed, and I think if we are to release anything, we would need
> one or
> > > > > more extra releases before we get everything right for the 1.0.
But
> if
> > > we
> > > > > can continue breaking backward compatibility (even though we will
> try
> > > > that
> > > > > to only what's necessary to reduce impact to users) with M1/M2/M3,
> the
> > > > same
> > > > > way we did with the alpha releases, then I'm +1 for that already.
> > > >
> > > > Why not continue with experimental releases using the same scheme
> > > > (i.e. "alpha", then "beta") with the agreed on semantics (that
> > > > compatibility
> > > > can be broken)?
> > > >
> > > > > > > [...]
> > > >
> > > >
-
> > > > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> > > > For additional commands, e-mail: user-h...@commons.apache.org
> > > >
> > > >
> > >
> >
>

RE: Re: release of commons-imaging

[William Borg Barthet]

Thanks for your replies.

I am actually waiting on the WebP support. I found a PR and tested against
it and it seems to work for my purposes. I cannot really make use of a
SNAPSHOT, so any sort of tagged release, short of a 1.0 release would
suffice if it contained the WebP support.

Thanks and regards

William

On 2024/02/28 15:43:06 Gary Gregory wrote:
> Yes: M is for milestone.
>
> Gary
>
> On Wed, Feb 28, 2024, 10:40 AM Bruno Kinoshita 
> wrote:
>
> > >
> > > Why not continue with experimental releases using the same scheme
> > > (i.e. "alpha", then "beta") with the agreed on semantics (that
> > > compatibility
> > > can be broken)?
> >
> >
> > Sounds good to me too, at least users wouldn't expect any difference
seeing
> > a new alphaN+1 announced. But not sure if there won't be any differences
> > with a milestone release (M is for milestone, right?)
> >
> > Cheers
> >
> > On Wed, 28 Feb 2024 at 16:11, Gilles Sadowski 
> > wrote:
> >
> > > Le mer. 28 févr. 2024 à 16:00, Bruno Kinoshita
> > >  a écrit :
> > > >
> > > > Hi Gary,
> > > >
> > > > What would be the main difference between the alpha and M1 releases?
> > > >
> > > > I am not 100% confident that we have the public and protected API
> > right,
> > > > > specifically we might have too much public and protected. YMMV.
> > > >
> > > >
> > > > Agreed, and I think if we are to release anything, we would need
one or
> > > > more extra releases before we get everything right for the 1.0. But
if
> > we
> > > > can continue breaking backward compatibility (even though we will
try
> > > that
> > > > to only what's necessary to reduce impact to users) with M1/M2/M3,
the
> > > same
> > > > way we did with the alpha releases, then I'm +1 for that already.
> > >
> > > Why not continue with experimental releases using the same scheme
> > > (i.e. "alpha", then "beta") with the agreed on semantics (that
> > > compatibility
> > > can be broken)?
> > >
> > > > > > [...]
> > >
> > > -
> > > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: user-h...@commons.apache.org
> > >
> > >
> >
>

Re: release of commons-imaging

[Gary Gregory]

Yes: M is for milestone.

Gary

On Wed, Feb 28, 2024, 10:40 AM Bruno Kinoshita 
wrote:

> >
> > Why not continue with experimental releases using the same scheme
> > (i.e. "alpha", then "beta") with the agreed on semantics (that
> > compatibility
> > can be broken)?
>
>
> Sounds good to me too, at least users wouldn't expect any difference seeing
> a new alphaN+1 announced. But not sure if there won't be any differences
> with a milestone release (M is for milestone, right?)
>
> Cheers
>
> On Wed, 28 Feb 2024 at 16:11, Gilles Sadowski 
> wrote:
>
> > Le mer. 28 févr. 2024 à 16:00, Bruno Kinoshita
> >  a écrit :
> > >
> > > Hi Gary,
> > >
> > > What would be the main difference between the alpha and M1 releases?
> > >
> > > I am not 100% confident that we have the public and protected API
> right,
> > > > specifically we might have too much public and protected. YMMV.
> > >
> > >
> > > Agreed, and I think if we are to release anything, we would need one or
> > > more extra releases before we get everything right for the 1.0. But if
> we
> > > can continue breaking backward compatibility (even though we will try
> > that
> > > to only what's necessary to reduce impact to users) with M1/M2/M3, the
> > same
> > > way we did with the alpha releases, then I'm +1 for that already.
> >
> > Why not continue with experimental releases using the same scheme
> > (i.e. "alpha", then "beta") with the agreed on semantics (that
> > compatibility
> > can be broken)?
> >
> > > > > [...]
> >
> > -
> > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> > For additional commands, e-mail: user-h...@commons.apache.org
> >
> >
>

Re: release of commons-imaging

[Gary Gregory]

It's just a label that says not 1.0 but really it seems like a label I see
more often than alpha and beta these days. The main idea for me is that we
should have a couple of releases IMO before we stamp a 1.0 and set a binary
compatibility base line.

I am happy to call releases alpha, beta, or milestones until then.

Gary


On Wed, Feb 28, 2024, 10:01 AM Bruno Kinoshita 
wrote:

> Hi Gary,
>
> What would be the main difference between the alpha and M1 releases?
>
> I am not 100% confident that we have the public and protected API right,
> > specifically we might have too much public and protected. YMMV.
>
>
> Agreed, and I think if we are to release anything, we would need one or
> more extra releases before we get everything right for the 1.0. But if we
> can continue breaking backward compatibility (even though we will try that
> to only what's necessary to reduce impact to users) with M1/M2/M3, the same
> way we did with the alpha releases, then I'm +1 for that already.
>
> Thanks!
>
> On Wed, 28 Feb 2024 at 13:50, Gary Gregory  wrote:
>
> > I would like to have an M1 release to push out the current code base.
> >
> > I am not 100% confident that we have the public and protected API right,
> > specifically we might have too much public and protected. YMMV.
> >
> > Gary
> >
> > On Wed, Feb 28, 2024, 6:36 AM Bruno Kinoshita 
> > wrote:
> >
> > > BTW, let us know if there is any issue not resolved that you need/would
> > > like to see in the next release, or if you can help testing/triaging
> the
> > > issues.
> > >
> > > On JIRA you can filter by the milestone/release. Check what's in 1.0
> and
> > > 1.0-alphaN (where N may vary) and is open. Any help there would be
> > > appreciated.
> > >
> > > Cheers
> > >
> > > On Wed, 28 Feb 2024 at 12:30, Bruno Kinoshita  >
> > > wrote:
> > >
> > > > Hi William,
> > > >
> > > > Not sure. I will start looking at the issues to see what is missing
> for
> > > > 1.0, but I suspect we are not ready for a final release yet.
> > > >
> > > > I think there was some discussion about an M1 or RC1 release of
> sorts,
> > > but
> > > > I am out of the loop. The most important thing to know is that there
> > is a
> > > > version to be released soon (as soon as a volunteer has time to go
> > > through
> > > > issues and prepare it), but not the final 1.0 yet.
> > > >
> > > > Cheers,
> > > >
> > > > Bruno
> > > >
> > > > On Wed, 28 Feb 2024 at 12:00, William Borg Barthet <
> > > > william.borgbart...@bloomreach.com> wrote:
> > > >
> > > >> Hi there,
> > > >>
> > > >> Apologies if this is already covered in another thread, but I can't
> > seem
> > > >> to
> > > >> find it. Is a new release of Apache Commons Imaging imminent?
> > > >>
> > > >> Thanks for your help
> > > >>
> > > >> William
> > > >>
> > > >
> > >
> >
>

Re: release of commons-imaging

[Bruno Kinoshita]

>
> Why not continue with experimental releases using the same scheme
> (i.e. "alpha", then "beta") with the agreed on semantics (that
> compatibility
> can be broken)?


Sounds good to me too, at least users wouldn't expect any difference seeing
a new alphaN+1 announced. But not sure if there won't be any differences
with a milestone release (M is for milestone, right?)

Cheers

On Wed, 28 Feb 2024 at 16:11, Gilles Sadowski  wrote:

> Le mer. 28 févr. 2024 à 16:00, Bruno Kinoshita
>  a écrit :
> >
> > Hi Gary,
> >
> > What would be the main difference between the alpha and M1 releases?
> >
> > I am not 100% confident that we have the public and protected API right,
> > > specifically we might have too much public and protected. YMMV.
> >
> >
> > Agreed, and I think if we are to release anything, we would need one or
> > more extra releases before we get everything right for the 1.0. But if we
> > can continue breaking backward compatibility (even though we will try
> that
> > to only what's necessary to reduce impact to users) with M1/M2/M3, the
> same
> > way we did with the alpha releases, then I'm +1 for that already.
>
> Why not continue with experimental releases using the same scheme
> (i.e. "alpha", then "beta") with the agreed on semantics (that
> compatibility
> can be broken)?
>
> > > > [...]
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>
>

Re: release of commons-imaging

[Gilles Sadowski]

Le mer. 28 févr. 2024 à 16:00, Bruno Kinoshita
 a écrit :
>
> Hi Gary,
>
> What would be the main difference between the alpha and M1 releases?
>
> I am not 100% confident that we have the public and protected API right,
> > specifically we might have too much public and protected. YMMV.
>
>
> Agreed, and I think if we are to release anything, we would need one or
> more extra releases before we get everything right for the 1.0. But if we
> can continue breaking backward compatibility (even though we will try that
> to only what's necessary to reduce impact to users) with M1/M2/M3, the same
> way we did with the alpha releases, then I'm +1 for that already.

Why not continue with experimental releases using the same scheme
(i.e. "alpha", then "beta") with the agreed on semantics (that compatibility
can be broken)?

> > > [...]

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: release of commons-imaging

[Bruno Kinoshita]

Hi Gary,

What would be the main difference between the alpha and M1 releases?

I am not 100% confident that we have the public and protected API right,
> specifically we might have too much public and protected. YMMV.


Agreed, and I think if we are to release anything, we would need one or
more extra releases before we get everything right for the 1.0. But if we
can continue breaking backward compatibility (even though we will try that
to only what's necessary to reduce impact to users) with M1/M2/M3, the same
way we did with the alpha releases, then I'm +1 for that already.

Thanks!

On Wed, 28 Feb 2024 at 13:50, Gary Gregory  wrote:

> I would like to have an M1 release to push out the current code base.
>
> I am not 100% confident that we have the public and protected API right,
> specifically we might have too much public and protected. YMMV.
>
> Gary
>
> On Wed, Feb 28, 2024, 6:36 AM Bruno Kinoshita 
> wrote:
>
> > BTW, let us know if there is any issue not resolved that you need/would
> > like to see in the next release, or if you can help testing/triaging the
> > issues.
> >
> > On JIRA you can filter by the milestone/release. Check what's in 1.0 and
> > 1.0-alphaN (where N may vary) and is open. Any help there would be
> > appreciated.
> >
> > Cheers
> >
> > On Wed, 28 Feb 2024 at 12:30, Bruno Kinoshita 
> > wrote:
> >
> > > Hi William,
> > >
> > > Not sure. I will start looking at the issues to see what is missing for
> > > 1.0, but I suspect we are not ready for a final release yet.
> > >
> > > I think there was some discussion about an M1 or RC1 release of sorts,
> > but
> > > I am out of the loop. The most important thing to know is that there
> is a
> > > version to be released soon (as soon as a volunteer has time to go
> > through
> > > issues and prepare it), but not the final 1.0 yet.
> > >
> > > Cheers,
> > >
> > > Bruno
> > >
> > > On Wed, 28 Feb 2024 at 12:00, William Borg Barthet <
> > > william.borgbart...@bloomreach.com> wrote:
> > >
> > >> Hi there,
> > >>
> > >> Apologies if this is already covered in another thread, but I can't
> seem
> > >> to
> > >> find it. Is a new release of Apache Commons Imaging imminent?
> > >>
> > >> Thanks for your help
> > >>
> > >> William
> > >>
> > >
> >
>

Re: release of commons-imaging

[Gary Gregory]

I would like to have an M1 release to push out the current code base.

I am not 100% confident that we have the public and protected API right,
specifically we might have too much public and protected. YMMV.

Gary

On Wed, Feb 28, 2024, 6:36 AM Bruno Kinoshita 
wrote:

> BTW, let us know if there is any issue not resolved that you need/would
> like to see in the next release, or if you can help testing/triaging the
> issues.
>
> On JIRA you can filter by the milestone/release. Check what's in 1.0 and
> 1.0-alphaN (where N may vary) and is open. Any help there would be
> appreciated.
>
> Cheers
>
> On Wed, 28 Feb 2024 at 12:30, Bruno Kinoshita 
> wrote:
>
> > Hi William,
> >
> > Not sure. I will start looking at the issues to see what is missing for
> > 1.0, but I suspect we are not ready for a final release yet.
> >
> > I think there was some discussion about an M1 or RC1 release of sorts,
> but
> > I am out of the loop. The most important thing to know is that there is a
> > version to be released soon (as soon as a volunteer has time to go
> through
> > issues and prepare it), but not the final 1.0 yet.
> >
> > Cheers,
> >
> > Bruno
> >
> > On Wed, 28 Feb 2024 at 12:00, William Borg Barthet <
> > william.borgbart...@bloomreach.com> wrote:
> >
> >> Hi there,
> >>
> >> Apologies if this is already covered in another thread, but I can't seem
> >> to
> >> find it. Is a new release of Apache Commons Imaging imminent?
> >>
> >> Thanks for your help
> >>
> >> William
> >>
> >
>

Re: release of commons-imaging

[Bruno Kinoshita]

BTW, let us know if there is any issue not resolved that you need/would
like to see in the next release, or if you can help testing/triaging the
issues.

On JIRA you can filter by the milestone/release. Check what's in 1.0 and
1.0-alphaN (where N may vary) and is open. Any help there would be
appreciated.

Cheers

On Wed, 28 Feb 2024 at 12:30, Bruno Kinoshita 
wrote:

> Hi William,
>
> Not sure. I will start looking at the issues to see what is missing for
> 1.0, but I suspect we are not ready for a final release yet.
>
> I think there was some discussion about an M1 or RC1 release of sorts, but
> I am out of the loop. The most important thing to know is that there is a
> version to be released soon (as soon as a volunteer has time to go through
> issues and prepare it), but not the final 1.0 yet.
>
> Cheers,
>
> Bruno
>
> On Wed, 28 Feb 2024 at 12:00, William Borg Barthet <
> william.borgbart...@bloomreach.com> wrote:
>
>> Hi there,
>>
>> Apologies if this is already covered in another thread, but I can't seem
>> to
>> find it. Is a new release of Apache Commons Imaging imminent?
>>
>> Thanks for your help
>>
>> William
>>
>

Re: release of commons-imaging

[Bruno Kinoshita]

Hi William,

Not sure. I will start looking at the issues to see what is missing for
1.0, but I suspect we are not ready for a final release yet.

I think there was some discussion about an M1 or RC1 release of sorts, but
I am out of the loop. The most important thing to know is that there is a
version to be released soon (as soon as a volunteer has time to go through
issues and prepare it), but not the final 1.0 yet.

Cheers,

Bruno

On Wed, 28 Feb 2024 at 12:00, William Borg Barthet <
william.borgbart...@bloomreach.com> wrote:

> Hi there,
>
> Apologies if this is already covered in another thread, but I can't seem to
> find it. Is a new release of Apache Commons Imaging imminent?
>
> Thanks for your help
>
> William
>

release of commons-imaging

[William Borg Barthet]

Hi there,

Apologies if this is already covered in another thread, but I can't seem to
find it. Is a new release of Apache Commons Imaging imminent?

Thanks for your help

William

[imaging]Does it support multiple images in ICNS and ICO?

[Will Hartung]

Is there a way to create an ICNS and ICO file that will have the multiple
resolutions used by MacOS and Windows?

Regards,

WIll Hartung

Re: [imaging] I want to know the roadmap up to the version 1.0 in the future

[cottonspace]

Hello, Thanks to everyone who contributes to this library.

I have not contributed to development [imaging] library yet.
I haven't seen the "development" ML yet, so I'll check the issue tickets to
see if there's one I can contribute to.

2022年12月9日(金) 2:37 Gary Gregory :

> Then I encourage 1.0-beta1 ;-)
>
> Gary
>
> On Thu, Dec 8, 2022, 11:29 Bruno Kinoshita  wrote:
>
> > No objection from me :) 1.0b or 1.0, doing any progress on [Imaging]
> would
> > be grand.
> >
> > -Bruno
> >
> > On Thu, 8 Dec 2022 at 17:11, Gilles Sadowski 
> wrote:
> >
> > > [Moving to "dev" ML...]
> > >
> > > Le jeu. 8 déc. 2022 à 16:56, Gary Gregory  a
> > > écrit :
> > > >
> > > > Since we had alpha releases, should we have a beta?
> > >
> > > +1
> > >
> > > It would allow modifying the API in order to e.g. provide a code that
> > > self-documents the caller's responsibility wrt validation of external
> > > input.  [Something which "cottonspace" might want to help with (?).]
> > >
> > > Gilles
> > >
> > > >> [...]
> > >
> > > -
> > > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: user-h...@commons.apache.org
> > >
> > >
> >
>


-- 
cottonsp...@gmail.com

Re: [imaging] I want to know the roadmap up to the version 1.0 in the future

[Gary Gregory]

Then I encourage 1.0-beta1 ;-)

Gary

On Thu, Dec 8, 2022, 11:29 Bruno Kinoshita  wrote:

> No objection from me :) 1.0b or 1.0, doing any progress on [Imaging] would
> be grand.
>
> -Bruno
>
> On Thu, 8 Dec 2022 at 17:11, Gilles Sadowski  wrote:
>
> > [Moving to "dev" ML...]
> >
> > Le jeu. 8 déc. 2022 à 16:56, Gary Gregory  a
> > écrit :
> > >
> > > Since we had alpha releases, should we have a beta?
> >
> > +1
> >
> > It would allow modifying the API in order to e.g. provide a code that
> > self-documents the caller's responsibility wrt validation of external
> > input.  [Something which "cottonspace" might want to help with (?).]
> >
> > Gilles
> >
> > >> [...]
> >
> > -
> > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> > For additional commands, e-mail: user-h...@commons.apache.org
> >
> >
>

Re: [imaging] I want to know the roadmap up to the version 1.0 in the future

[Bruno Kinoshita]

No objection from me :) 1.0b or 1.0, doing any progress on [Imaging] would
be grand.

-Bruno

On Thu, 8 Dec 2022 at 17:11, Gilles Sadowski  wrote:

> [Moving to "dev" ML...]
>
> Le jeu. 8 déc. 2022 à 16:56, Gary Gregory  a
> écrit :
> >
> > Since we had alpha releases, should we have a beta?
>
> +1
>
> It would allow modifying the API in order to e.g. provide a code that
> self-documents the caller's responsibility wrt validation of external
> input.  [Something which "cottonspace" might want to help with (?).]
>
> Gilles
>
> >> [...]
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>
>

Re: [imaging] I want to know the roadmap up to the version 1.0 in the future

[Gilles Sadowski]

[Moving to "dev" ML...]

Le jeu. 8 déc. 2022 à 16:56, Gary Gregory  a écrit :
>
> Since we had alpha releases, should we have a beta?

+1

It would allow modifying the API in order to e.g. provide a code that
self-documents the caller's responsibility wrt validation of external
input.  [Something which "cottonspace" might want to help with (?).]

Gilles

>> [...]

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [imaging] I want to know the roadmap up to the version 1.0 in the future

[Gary Gregory]

Since we had alpha releases, should we have a beta?

Gaty

On Thu, Dec 8, 2022, 09:29 Bruno Kinoshita  wrote:

> Hi,
>
> +1 to using the dev mailing list as there are more people subscribed.
>
> Some more context that may help with contributing to 1.0. We had a vote for
> 1.0 some years ago, but we had too many blocker issues. That release was
> cancelled, and we started to slowly close the blocker issues for 1.0, and
> prepare alpha releases for users to try the code.
>
> Luckily a few of these users provided great feedback, and even pull
> requests. There are still some pending issues, but I am confident we don't
> need another alpha release, and we can fix all these last issues and
> prepare the 1.0 release in the next weeks/months, depending on
> contributions received and developer bandwidth.
>
> So feel free to start a discussion in the dev mailing list, or directly on
> JIRA or GitHub in a pull request. These are the issues for 1.0:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20IMAGING%20AND%20fixVersion%20%3D%201.0
>
> If you find anything else in JIRA, or any problem with the code, that you
> believe deserves to be added to 1.0, either comment in the dev list, or
> just use JIRA and suggest the FixVersion for 1.0.
>
> Cheers
>
> Bruno
>
> On Thu, 8 Dec 2022 at 11:29, Gilles Sadowski  wrote:
>
> > Hello.
> >
> > Le jeu. 8 déc. 2022 à 05:44, cottonspace  a
> écrit :
> > >
> > > Hi. Thank you for your reply.
> > >
> > > I think that the current alpha-3 version gives good and enough quality.
> > > But my business clients concerned about the stability of the library
> > > quality in alpha version.
> >
> > This question question should probably be discussed on the "dev" ML.[1]
> >
> > >
> > > I'd like to contribute to the project also.
> >
> > Then please do subscribe to the "dev" mailing list as this is where you
> can
> > collect infos about the ongoing work, and propose to help on it.
> >
> > Best regards,
> > Gilles
> >
> > [1] https://commons.apache.org/mail-lists.html
> >
> > >> [...]
> >
> > -
> > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> > For additional commands, e-mail: user-h...@commons.apache.org
> >
> >
>

Re: [imaging] I want to know the roadmap up to the version 1.0 in the future

[Bruno Kinoshita]

Hi,

+1 to using the dev mailing list as there are more people subscribed.

Some more context that may help with contributing to 1.0. We had a vote for
1.0 some years ago, but we had too many blocker issues. That release was
cancelled, and we started to slowly close the blocker issues for 1.0, and
prepare alpha releases for users to try the code.

Luckily a few of these users provided great feedback, and even pull
requests. There are still some pending issues, but I am confident we don't
need another alpha release, and we can fix all these last issues and
prepare the 1.0 release in the next weeks/months, depending on
contributions received and developer bandwidth.

So feel free to start a discussion in the dev mailing list, or directly on
JIRA or GitHub in a pull request. These are the issues for 1.0:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20IMAGING%20AND%20fixVersion%20%3D%201.0

If you find anything else in JIRA, or any problem with the code, that you
believe deserves to be added to 1.0, either comment in the dev list, or
just use JIRA and suggest the FixVersion for 1.0.

Cheers

Bruno

On Thu, 8 Dec 2022 at 11:29, Gilles Sadowski  wrote:

> Hello.
>
> Le jeu. 8 déc. 2022 à 05:44, cottonspace  a écrit :
> >
> > Hi. Thank you for your reply.
> >
> > I think that the current alpha-3 version gives good and enough quality.
> > But my business clients concerned about the stability of the library
> > quality in alpha version.
>
> This question question should probably be discussed on the "dev" ML.[1]
>
> >
> > I'd like to contribute to the project also.
>
> Then please do subscribe to the "dev" mailing list as this is where you can
> collect infos about the ongoing work, and propose to help on it.
>
> Best regards,
> Gilles
>
> [1] https://commons.apache.org/mail-lists.html
>
> >> [...]
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>
>

Re: [imaging] I want to know the roadmap up to the version 1.0 in the future

[Gilles Sadowski]

Hello.

Le jeu. 8 déc. 2022 à 05:44, cottonspace  a écrit :
>
> Hi. Thank you for your reply.
>
> I think that the current alpha-3 version gives good and enough quality.
> But my business clients concerned about the stability of the library
> quality in alpha version.

This question question should probably be discussed on the "dev" ML.[1]

>
> I'd like to contribute to the project also.

Then please do subscribe to the "dev" mailing list as this is where you can
collect infos about the ongoing work, and propose to help on it.

Best regards,
Gilles

[1] https://commons.apache.org/mail-lists.html

>> [...]

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [imaging] I want to know the roadmap up to the version 1.0 in the future

[cottonspace]

Hi. Thank you for your reply.

I think that the current alpha-3 version gives good and enough quality.
But my business clients concerned about the stability of the library
quality in alpha version.

I'd like to contribute to the project also.

Regards.

2022年12月8日(木) 10:06 Gilles Sadowski :

> Hi.
>
> Le jeu. 8 déc. 2022 à 01:10, cottonspace  a écrit :
> >
> > Hello, I want to use this convenient library. However, the current
> version
> > is alpha-3.
> >
> > If possible, I would like to wait for the release of the version 1.0 at
> > starting to use it.
>
> Why?
>
> >
> > At now, do you have any prospects for when the version 1.0 will be
> released?
>
> The surest way to bring the date closer is to contribute to the project.
>
> Best regards,
> Gilles
>
> >
> > Note) I would like to use this library only for read/write EXIF
> information
> > of JPEG image.
> >
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>
>

-- 
cottonsp...@gmail.com

Re: [imaging] I want to know the roadmap up to the version 1.0 in the future

[Gilles Sadowski]

Hi.

Le jeu. 8 déc. 2022 à 01:10, cottonspace  a écrit :
>
> Hello, I want to use this convenient library. However, the current version
> is alpha-3.
>
> If possible, I would like to wait for the release of the version 1.0 at
> starting to use it.

Why?

>
> At now, do you have any prospects for when the version 1.0 will be released?

The surest way to bring the date closer is to contribute to the project.

Best regards,
Gilles

>
> Note) I would like to use this library only for read/write EXIF information
> of JPEG image.
>

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

[imaging] I want to know the roadmap up to the version 1.0 in the future

[cottonspace]

Hello, I want to use this convenient library. However, the current version
is alpha-3.

If possible, I would like to wait for the release of the version 1.0 at
starting to use it.

At now, do you have any prospects for when the version 1.0 will be released?

Note) I would like to use this library only for read/write EXIF information
of JPEG image.

--
cottonsp...@gmail.com

Re: How to apply Exif informations other than image orientation fields using Commons Imaging to resized image

[Bruno Kinoshita]

Thanks for confirming it, and for sharing the test code Cotton!

Bruno

On Thu, 27 Oct 2022 at 17:26, cottonspace  wrote:

> It seems that the test code could not be attached, so I attach it with the
> extension ".txt".
>
> 2022年10月27日(木) 13:18 cottonspace :
>
>> Hello.
>>
>> I executed test. and run "exiftool" for each image files.
>>
>> The following fields I was concerned about seem to be determined based on
>> the resized image, as expected, rather than the Exif value of the original
>> image.
>>
>> - Orientation: copy from *original* image.
>> - Image Width: based on *resized* image.
>> - Image Height: based on *resized* image.
>> - Y Cb Cr Sub Sampling: based on *resized* image.
>>
>> I thought my concern was unnecessary. My question is solved.
>>
>> Regards.
>>
>
>
> --
> cottonsp...@gmail.com
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org

Re: How to apply Exif informations other than image orientation fields using Commons Imaging to resized image

[cottonspace]

It seems that the test code could not be attached, so I attach it with the
extension ".txt".

2022年10月27日(木) 13:18 cottonspace :

> Hello.
>
> I executed test. and run "exiftool" for each image files.
>
> The following fields I was concerned about seem to be determined based on
> the resized image, as expected, rather than the Exif value of the original
> image.
>
> - Orientation: copy from *original* image.
> - Image Width: based on *resized* image.
> - Image Height: based on *resized* image.
> - Y Cb Cr Sub Sampling: based on *resized* image.
>
> I thought my concern was unnecessary. My question is solved.
>
> Regards.
>


-- 
cottonsp...@gmail.com
import java.awt.Graphics;
import java.awt.Image;
import java.awt.image.BufferedImage;
import java.io.BufferedOutputStream;
import java.io.ByteArrayInputStream;
import java.io.ByteArrayOutputStream;
import java.io.File;
import java.io.IOException;
import java.nio.file.Files;

import javax.imageio.ImageIO;

import org.apache.commons.imaging.Imaging;
import org.apache.commons.imaging.ImagingException;
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;

public class ExifCopyTest {

public static void main(String[] args) throws IOException, 
ImagingException {

// Parameters
File fileOriginal = new File("original.jpg");
File fileResized = new File("resized.jpg");
File fileExifUpdated = new File("exif-updated.jpg");

// Read original image
byte[] bytesOriginal = 
Files.readAllBytes(fileOriginal.toPath());
BufferedImage imageOriginal = null;
ByteArrayInputStream bais = new 
ByteArrayInputStream(bytesOriginal);
imageOriginal = ImageIO.read(bais);

// Resize (half size)
int dw = imageOriginal.getWidth() / 2;
int dh = imageOriginal.getHeight() / 2;
BufferedImage imageResized = new BufferedImage(dw, dh, 
imageOriginal.getType());
Graphics g = imageResized.createGraphics();
g.drawImage(imageOriginal.getScaledInstance(dw, dh, 
Image.SCALE_AREA_AVERAGING), 0, 0, dw, dh, null);
g.dispose();

// Get resized image to bytes
byte[] bytesResized = null;
ByteArrayOutputStream baos1 = new ByteArrayOutputStream();
BufferedOutputStream bos1 = new BufferedOutputStream(baos1);
ImageIO.write(imageResized, "jpg", bos1);
bytesResized = baos1.toByteArray();

// Save (Resized only)
Files.write(fileResized.toPath(), bytesResized);

// Apply original metadata into resized image
TiffImageMetadata exif = ((JpegImageMetadata) 
Imaging.getMetadata(bytesOriginal)).getExif();
ByteArrayOutputStream baos2 = new ByteArrayOutputStream();
new ExifRewriter().updateExifMetadataLossy(bytesResized, baos2, 
exif.getOutputSet());
byte[] bytesExifUpdated = baos2.toByteArray();

// Save (Exif Updated)
Files.write(fileExifUpdated.toPath(), bytesExifUpdated);
}
}

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: How to apply Exif informations other than image orientation fields using Commons Imaging to resized image

[cottonspace]

Hello.

I executed test. and run "exiftool" for each image files.

The following fields I was concerned about seem to be determined based on
the resized image, as expected, rather than the Exif value of the original
image.

- Orientation: copy from *original* image.
- Image Width: based on *resized* image.
- Image Height: based on *resized* image.
- Y Cb Cr Sub Sampling: based on *resized* image.

I thought my concern was unnecessary. My question is solved.

Regards.
ExifTool Version Number : 12.49
File Name   : original.jpg
Directory   : .
File Size   : 139 kB
Zone Identifier : Exists
File Modification Date/Time : 2022:10:27 12:12:46+09:00
File Access Date/Time   : 2022:10:27 12:57:16+09:00
File Creation Date/Time : 2022:10:27 12:54:07+09:00
File Permissions: -rw-rw-rw-
File Type   : JPEG
File Type Extension : jpg
MIME Type   : image/jpeg
Exif Byte Order : Little-endian (Intel, II)
Orientation : Horizontal (normal)
X Resolution: 72
Y Resolution: 72
Resolution Unit : inches
Y Cb Cr Positioning : Centered
Quality : 70%
XMP Toolkit : Adobe XMP Core 5.0-c060 61.134777, 
2010/02/12-17:32:00
Original Document ID: xmp.did:048011740720681185DFA072021BDFE6
Document ID : xmp.did:192571C8CED511E1B1C1DA012E36D12B
Instance ID : xmp.iid:44CDC084CED311E1B1C1DA012E36D12B
Creator Tool: Adobe Photoshop CS5 Macintosh
Derived From Instance ID: xmp.iid:854147ED0A20681185DFA072021BDFE6
Derived From Document ID: xmp.did:048011740720681185DFA072021BDFE6
Current IPTC Digest : fce11f89c8b7c9782f346234075877eb
Coded Character Set : UTF8
Application Record Version  : 2
IPTC Digest : fce11f89c8b7c9782f346234075877eb
DCT Encode Version  : 100
APP14 Flags 0   : [14], Encoded with Blend=1 downsampling
APP14 Flags 1   : (none)
Color Transform : YCbCr
Image Width : 600
Image Height: 450
Encoding Process: Baseline DCT, Huffman coding
Bits Per Sample : 8
Color Components: 3
Y Cb Cr Sub Sampling: YCbCr4:4:4 (1 1)
Image Size  : 600x450
Megapixels  : 0.270
ExifTool Version Number : 12.49
File Name   : resized.jpg
Directory   : .
File Size   : 20 kB
File Modification Date/Time : 2022:10:27 12:57:17+09:00
File Access Date/Time   : 2022:10:27 12:57:18+09:00
File Creation Date/Time : 2022:10:27 12:57:17+09:00
File Permissions: -rw-rw-rw-
File Type   : JPEG
File Type Extension : jpg
MIME Type   : image/jpeg
JFIF Version: 1.02
Resolution Unit : None
X Resolution: 1
Y Resolution: 1
Image Width : 300
Image Height: 225
Encoding Process: Baseline DCT, Huffman coding
Bits Per Sample : 8
Color Components: 3
Y Cb Cr Sub Sampling: YCbCr4:2:0 (2 2)
Image Size  : 300x225
Megapixels  : 0.068
ExifTool Version Number : 12.49
File Name   : exif-updated.jpg
Directory   : .
File Size   : 20 kB
File Modification Date/Time : 2022:10:27 12:57:17+09:00
File Access Date/Time   : 2022:10:27 12:57:52+09:00
File Creation Date/Time : 2022:10:27 12:57:17+09:00
File Permissions: -rw-rw-rw-
File Type   : JPEG
File Type Extension : jpg
MIME Type   : image/jpeg
JFIF Version: 1.02
Exif Byte Order : Little-endian (Intel, II)
Orientation : Horizontal (normal)
X Resolution: 72
Y Resolution: 72
Resolution Unit : inches
Y Cb Cr Positioning : Centered
Image Width : 300
Image Height: 225
Encoding Process: Baseline DCT, Huffman coding
Bits Per Sample : 8
Color Components: 3
Y Cb Cr Sub Sampling: YCbCr4:2:0 (2 2)
Image Size  : 300x225
Megapixels  : 0.068

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: How to apply Exif informations other than image orientation fields using Commons Imaging to resized image

[cottonspace]

Hi. Bruno. Thanks for your reply.

I'll test it the following way you suggested.

> 1. Grab an image with some EXIF data
> 2. Run exiftool and save the output somewhere
> 3. Run your code
> 4. Run exiftool again on the reduced image, save the output somewhere
> 5. Diff the output

I will report the results on this thread.

Regards.

2022年10月27日(木) 10:32 Bruno Kinoshita :

> Hi Cotton,
>
> I think your concerns are valid. I had a quick look and couldn't see in
> updateExifMetadataLossy() chain of methods called anywhere where it would
> update the ImageWidth and ImageLength.
>
> But probably the best way is to test yourself to verify it. You can try the
> following:
>
> 1. Grab an image with some EXIF data
> 2. Run exiftool and save the output somewhere
> 3. Run your code
> 4. Run exiftool again on the reduced image, save the output somewhere
> 5. Diff the output
>
> I **think** you would have to adjust the image/length. But it would be nice
> to confirm that. We should improve the javadoc of these classes as well to
> document whether developers should worry about that or not. I'm moving
> between countries this week/weekend, so I won't have time to create issues
> and work on that for a while. But you can reply here if you are able to
> confirm, or ping this thread again in a few months and I'd be happy to try
> that.
>
> If you find anything broken or have suggestions for improvements in Commons
> Imaging, feel free to create a JIRA Issue for those tasks. As for language,
> do not worry because your English is fine. If you need help translating,
> try deepl.com, Google Translate, and other free translation services that
> may assist you too (that's what I'm doing right now, as I'm going to a
> country where I don't speak the native language :)
>
> Cheers
>
> Bruno
>
> On Wed, 26 Oct 2022 at 22:27, cottonspace  wrote:
>
> > Hello. I don't use English on a usually. Sorry for the hard-to-read my
> > message.
> >
> > Thank you for publishing such a wonderful library.
> >
> > I want to resize an image, and apply Exif meta information (orientation
> > direction, author, and so on) in original to the image after resized
> image.
> > My code is like this.
> >
> > --- begin ---
> > // Original Image
> > byte[] original = load(file); // some loader
> >
> > // Edit (resize, rotate, ..)
> > byte[] resized = resize(original, width, height); // some edit methods
> >
> > // Apply original metadata into resized image
> > TiffImageMetadata exif = ((JpegImageMetadata)
> > Imaging.getMetadata(original)).getExif();
> > ByteArrayOutputStream baos = new ByteArrayOutputStream();
> > new ExifRewriter().updateExifMetadataLossy(resized, baos,
> > exif.getOutputSet());
> > byte[] result = baos.toByteArray();
> > --- end ---
> >
> > Can I apply the OutputSet got from the original image to the image after
> > resizing with ExifRewriter ?
> >
> > My question is that if the Dimension information such as Orientation
> > information contained in Exif is reflected by ExifRewriter, it will
> affect
> > the actual image size. Doesn't the direction and the Exif information
> > conflict with each other?
> >
> > My concerns are unnecessary? Please teach me.
> >
> > --
> > cotton
> >
>


-- 
cottonsp...@gmail.com

Re: How to apply Exif informations other than image orientation fields using Commons Imaging to resized image

[Bruno Kinoshita]

Hi Cotton,

I think your concerns are valid. I had a quick look and couldn't see in
updateExifMetadataLossy() chain of methods called anywhere where it would
update the ImageWidth and ImageLength.

But probably the best way is to test yourself to verify it. You can try the
following:

1. Grab an image with some EXIF data
2. Run exiftool and save the output somewhere
3. Run your code
4. Run exiftool again on the reduced image, save the output somewhere
5. Diff the output

I **think** you would have to adjust the image/length. But it would be nice
to confirm that. We should improve the javadoc of these classes as well to
document whether developers should worry about that or not. I'm moving
between countries this week/weekend, so I won't have time to create issues
and work on that for a while. But you can reply here if you are able to
confirm, or ping this thread again in a few months and I'd be happy to try
that.

If you find anything broken or have suggestions for improvements in Commons
Imaging, feel free to create a JIRA Issue for those tasks. As for language,
do not worry because your English is fine. If you need help translating,
try deepl.com, Google Translate, and other free translation services that
may assist you too (that's what I'm doing right now, as I'm going to a
country where I don't speak the native language :)

Cheers

Bruno

On Wed, 26 Oct 2022 at 22:27, cottonspace  wrote:

> Hello. I don't use English on a usually. Sorry for the hard-to-read my
> message.
>
> Thank you for publishing such a wonderful library.
>
> I want to resize an image, and apply Exif meta information (orientation
> direction, author, and so on) in original to the image after resized image.
> My code is like this.
>
> --- begin ---
> // Original Image
> byte[] original = load(file); // some loader
>
> // Edit (resize, rotate, ..)
> byte[] resized = resize(original, width, height); // some edit methods
>
> // Apply original metadata into resized image
> TiffImageMetadata exif = ((JpegImageMetadata)
> Imaging.getMetadata(original)).getExif();
> ByteArrayOutputStream baos = new ByteArrayOutputStream();
> new ExifRewriter().updateExifMetadataLossy(resized, baos,
> exif.getOutputSet());
> byte[] result = baos.toByteArray();
> --- end ---
>
> Can I apply the OutputSet got from the original image to the image after
> resizing with ExifRewriter ?
>
> My question is that if the Dimension information such as Orientation
> information contained in Exif is reflected by ExifRewriter, it will affect
> the actual image size. Doesn't the direction and the Exif information
> conflict with each other?
>
> My concerns are unnecessary? Please teach me.
>
> --
> cotton
>

How to apply Exif informations other than image orientation fields using Commons Imaging to resized image

[cottonspace]

Hello. I don't use English on a usually. Sorry for the hard-to-read my
message.

Thank you for publishing such a wonderful library.

I want to resize an image, and apply Exif meta information (orientation
direction, author, and so on) in original to the image after resized image.
My code is like this.

--- begin ---
// Original Image
byte[] original = load(file); // some loader

// Edit (resize, rotate, ..)
byte[] resized = resize(original, width, height); // some edit methods

// Apply original metadata into resized image
TiffImageMetadata exif = ((JpegImageMetadata)
Imaging.getMetadata(original)).getExif();
ByteArrayOutputStream baos = new ByteArrayOutputStream();
new ExifRewriter().updateExifMetadataLossy(resized, baos,
exif.getOutputSet());
byte[] result = baos.toByteArray();
--- end ---

Can I apply the OutputSet got from the original image to the image after
resizing with ExifRewriter ?

My question is that if the Dimension information such as Orientation
information contained in Exif is reflected by ExifRewriter, it will affect
the actual image size. Doesn't the direction and the Exif information
conflict with each other?

My concerns are unnecessary? Please teach me.

--
cotton

Re: [imaging] Is there any intention to add jpeg-writing capabilities?

[Bruno Kinoshita]

Hi Kean,

Do you have an example of Sanselan code that doesn't work now? We can then
imvestigate in jira and git tosee what happened to that code.

Thanks
Bruno

On Fri, 2 Sep 2022, 8:08 am Kean Erickson,  wrote:

>  The original sanselan incubator had this capability, but it seems like
> this is no longer an option for the commons-imaging alpha
>
> Is there an intention to bring back support for this at some point? Thank
> you
>

[imaging] Is there any intention to add jpeg-writing capabilities?

[Kean Erickson]

 The original sanselan incubator had this capability, but it seems like
this is no longer an option for the commons-imaging alpha

Is there an intention to bring back support for this at some point? Thank
you

[ANNOUNCEMENT] Apache Commons Imaging 1.0-alpha3 Released

[Bruno Kinoshita]

The Apache Commons Team is pleased to announce the availability of
Apache Commons Imaging 1.0-alpha3.

Apache Commons Imaging, previously known as Apache Commons Sanselan,
is a library that reads and writes a variety of image formats, including
fast parsing of image info (size, color space, ICC profile, etc.) and
metadata.

Version 1.0-alpha3 has a series of bug fixes, new features, and
improvements.
There are breaking changes since alpha2 as we are not maintaining backward
compatibility until it reaches the 1.0 release (likely the next release).

A full list of changes can be found at
https://commons.apache.org/proper/commons-imaging/changes-report.html

Source and binary distributions are available for download from the
Apache Commons download site:

https://commons.apache.org/proper/commons-imaging/download_imaging.cgi

Please verify signatures using the KEYS file available at the above
location when downloading the release.

For complete information on Commons Imaging, including
instructions on how to submit bug reports, patches, or suggestions for
improvement, see the Apache Commons Imaging website:

https://commons.apache.org/proper/commons-imaging/

Bruno
on behalf of the Apache Commons community

Re: Re: imaging

[Gary Gregory]

How about this:
https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-imaging/1.0-alpha3-SNAPSHOT/

Gary


On Mon, Apr 18, 2022, 16:07 Half Scheidl  wrote:

> Thank you Gary. I tried to update the dependency simply by changing the
> version in the POM file in IntelliJ. After some investigation it seemed
> that snapshots are not available neither in Maven central nor at
> https://repository.apache.org/content/repositories/snapshots/
> Could you point me on how to locate the Apache snapshot repository?
>
>
> On 2022/04/18 12:57:46 Gary Gregory wrote:
> > You'll need to point Maven or your build to the Apache snapshot
> repository
> > and use 1.0-alpha3-SNAPSHOT until
> > 1.0-alpha3 is released, but, there is no schedule for that to happen.
> >
> > Gary
> >
> >
> > On Mon, Apr 18, 2022, 07:51 Half Scheidl  wrote:
> >
> > > I'm interested in using the Imaging library to write text chunks to Png
> > > images. By looking at TIFF ImageWriter example it seems the
> > > PngImageParameters is the way to go, however the class has a comment
> "since
> > > 1-alpha3", however Maven only shows 1-alpha2.
> > >
> > > Apologies for the lack of familiarity with the development cycles, how
> > > could I find out when that version of the code is going to be released?
> > >
> > > Link to the class mentioned:
> > >
> > >
>
> https://github.com/apache/commons-imaging/blob/master/src/main/java/org/apache/commons/imaging/formats/png/PngImagingParameters.java
> > >
> >
>

RE: Re: imaging

[Half Scheidl]

Thank you Gary. I tried to update the dependency simply by changing the
version in the POM file in IntelliJ. After some investigation it seemed
that snapshots are not available neither in Maven central nor at
https://repository.apache.org/content/repositories/snapshots/
Could you point me on how to locate the Apache snapshot repository?


On 2022/04/18 12:57:46 Gary Gregory wrote:
> You'll need to point Maven or your build to the Apache snapshot repository
> and use 1.0-alpha3-SNAPSHOT until
> 1.0-alpha3 is released, but, there is no schedule for that to happen.
>
> Gary
>
>
> On Mon, Apr 18, 2022, 07:51 Half Scheidl  wrote:
>
> > I'm interested in using the Imaging library to write text chunks to Png
> > images. By looking at TIFF ImageWriter example it seems the
> > PngImageParameters is the way to go, however the class has a comment
"since
> > 1-alpha3", however Maven only shows 1-alpha2.
> >
> > Apologies for the lack of familiarity with the development cycles, how
> > could I find out when that version of the code is going to be released?
> >
> > Link to the class mentioned:
> >
> >
https://github.com/apache/commons-imaging/blob/master/src/main/java/org/apache/commons/imaging/formats/png/PngImagingParameters.java
> >
>

Re: imaging

[Gary Gregory]

You'll need to point Maven or your build to the Apache snapshot repository
and use 1.0-alpha3-SNAPSHOT until
1.0-alpha3 is released, but, there is no schedule for that to happen.

Gary


On Mon, Apr 18, 2022, 07:51 Half Scheidl  wrote:

> I'm interested in using the Imaging library to write text chunks to Png
> images. By looking at TIFF ImageWriter example it seems the
> PngImageParameters is the way to go, however the class has a comment "since
> 1-alpha3", however Maven only shows 1-alpha2.
>
> Apologies for the lack of familiarity with the development cycles, how
> could I find out when that version of the code is going to be released?
>
> Link to the class mentioned:
>
> https://github.com/apache/commons-imaging/blob/master/src/main/java/org/apache/commons/imaging/formats/png/PngImagingParameters.java
>

imaging

[Half Scheidl]

I'm interested in using the Imaging library to write text chunks to Png
images. By looking at TIFF ImageWriter example it seems the
PngImageParameters is the way to go, however the class has a comment "since
1-alpha3", however Maven only shows 1-alpha2.

Apologies for the lack of familiarity with the development cycles, how
could I find out when that version of the code is going to be released?

Link to the class mentioned:
https://github.com/apache/commons-imaging/blob/master/src/main/java/org/apache/commons/imaging/formats/png/PngImagingParameters.java

Re: [imaging] - java 7 not supported

[Gary Gregory]

This component requires Java 8. See
https://github.com/apache/commons-imaging/blob/23131ae2a9a34eac454b7ffaf1dde9f5bf3c50ce/pom.xml#L46

Gary


On Tue, Oct 19, 2021, 08:17 Pavol Michalco  wrote:

> Hello,
>
> On the page
> https://commons.apache.org/proper/commons-imaging/gettingstarted.html
> there
> is the statement: "Commons Imaging requires Java 1.7 or higher."
> But 1.0-alpha2 jar from official download page  (
> https://commons.apache.org/proper/commons-imaging/download_imaging.cgi) is
> built for java 8 - get "Unsupported major.minor version 52.0" when run on
> java 7.
> Is java 7 supported or not?
>
> Thank you.
>

[imaging] - java 7 not supported

[Pavol Michalco]

Hello,

On the page
https://commons.apache.org/proper/commons-imaging/gettingstarted.html there
is the statement: "Commons Imaging requires Java 1.7 or higher."
But 1.0-alpha2 jar from official download page  (
https://commons.apache.org/proper/commons-imaging/download_imaging.cgi) is
built for java 8 - get "Unsupported major.minor version 52.0" when run on
java 7.
Is java 7 supported or not?

Thank you.

[ANNOUNCEMENT] Apache Commons Imaging 1.0-alpha2 Released

[Bruno P. Kinoshita]

The Apache Commons Imaging team is pleased to announce the 
commons-imaging-1.0-alpha2 release!

Apache Commons Imaging (previously Sanselan) is a pure-Java image library.

There are breaking changes between 1.0-alpha1 and 1.0-alpha2, until we 
stabilize the API for our 1.0 release.
Users are encouraged to read the release notes when updating to this new 
release.

For details of the fixes and new features please see:

https://www.apache.org/dist/commons/imaging/RELEASE-NOTES.txt

[These are also included with the binary and source archives]

The changes are also available at:
https://commons.apache.org/imaging/changes-report.html

Binary and source archives are available from:

https://commons.apache.org/proper/commons-imaging/download_imaging.cgi

Please see the Apache Commons Imaging website for full details:

https://commons.apache.org/imaging/

The Maven coordinates are:

    org.apache.commons
    commons-imaging
    1.0-alpha2

Changes in this version include:

New features:
o IMAGING-248:  ICNS: missing element types; some safety checks Thanks to Greg 
Shrago.
o IMAGING-245:  Add disposal method to GIF metadata Thanks to Christoffer 
Rydberg.
o IMAGING-146:  Add documentation for the color package
o IMAGING-244:  Use isEmpty instead of comparing size() with integers
o IMAGING-243:  PNG Writer Indexed Color with semi-transparent Pixels and 
Better Compression Thanks to Andreas Menze.
o IMAGING-239:  Add inflate (deflate algorithm) to TIFF files Thanks to Paul 
Austin.
o IMAGING-164:  Simplify code in IcoImageParser::writeImage Thanks to Michael 
Groß.
o IMAGING-165:  Add the fields from TiffReader.Collector to TiffContents Thanks 
to Michael Groß.
o IMAGING-228:  Remove private method PhotometricInterpreterLogLuv#cube by 
Math.pow
o IMAGING-236:  Add support to read multiple images from GIF Thanks to 
Christoffer Rydberg.

Fixed Bugs:
o IMAGING-247:  Fix crash when reading TIFF using PackBits Thanks to Gary Lucas.
o IMAGING-246:  Invalid Block Size error prevents handling of block 1084, 
Macintosh NSPrintInfo
o IMAGING-163:  Add XmpEmbedabble interface to parsers that support it
o IMAGING-151:  ColorGroup.color_counts is mutable public List and is multiply 
sorted
o IMAGING-242:  Upgrade to JUnit 5
o IMAGING-241:  Copy byte arrays fixing TODO markers
o IMAGING-136:  Imaging.getImageInfo() fails to read JPEG file Thanks to 
Michael Groß.
o IMAGING-238:  Return copied byte arrays in Png Chunk and Png Chunk ICCP
o IMAGING-230:  Properly close resources with try-with-resources in 
T4AndT6Compression
o IMAGING-134:  Invalid (RST) marker found in entropy data Thanks to Michael 
Sommerville.
o IMAGING-130:  Reading of some GIF images throws java.io.IOException: 
AddStringToTable: codes: 4096 code_size: 12 Thanks to Michael Sommerville.
o IMAGING-224:  Fix build errors in Travis
o IMAGING-167:  Possible infinite loop at XpmImageParser::writeImage Thanks to 
Michael Groß.
o IMAGING-211:  Imaging.getBufferedImage fails throwing 
java.lang.ArrayIndexOutOfBoundsException for specific inputs
o IMAGING-210:  Imaging.getBufferedImage fails throwing 
NegativeArraySizeException for specific inputs

Changes:
o IMAGING-258:  Prevent exception in TIFF when reading EXIF directory Thanks to 
Gary Lucas.
o IMAGING-260:  Fix mvn site failure with JavaNCSS parse error
o IMAGING-259:  Enhance TIFF DataReaders speed for compressed RGB Thanks to 
Gary Lucas.
o IMAGING-251:  Support for TIFF floating-point formats Thanks to Gary Lucas.
o IMAGING-254:  Small code improvements
o IMAGING-253:  ByteSourceInputStream has initialized its length when reading 
starts Thanks to David Hrbacek.
o IMAGING-249:  Make IPTCBlock members private and add getter/setter
o   Update tests from commons-io:commons-io 2.6 to 2.7. Thanks to 
Gary Gregory.
o   Update commons-parent from 50 to 51 #88. Thanks to Dependabot.
o   Update actions/checkout from v1 to v2.3.1 #87. Thanks to 
Dependabot.
o   Update junit-jupiter from 5.5.2 to 5.6.2 #86. Thanks to 
Dependabot.


Have fun!
-Apache Commons Imaging team

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [imaging] Thank you!

[Guang Chao]

On Fri, Jan 3, 2020 at 2:01 AM Bryan Atsatt  wrote:

> Just wanted to let the developers know that this project saved the day for
> an important Christmas present for my wife.
>
> She has wanted access to about 30k photos I have in an old Photoshop
> Elements catalog (with lots of keywords etc added), but didn't want to use
> that app.
>
> This library enabled me to preserve all the data by updating the photos,
> adding (approximate) GPS info where missing and making them searchable in
> Google Photos by appending keywords to the captions.
>
>
Maybe share the code in github


> She now has all of them in her Google Photos and on a portable drive, with
> no PSE required, and is very happy.
>
> So... thanks for all the hard work everyone, and Happy New Decade to you
> all.
>
> // Bryan
>


-- 
I love Java 

Re: [imaging] Thank you!

[Bruno P. Kinoshita]

 Thank you Bryan! Really happy to hear it was helpful to you and your wife.
Feedback, both like this or bug/improvement/feature requests, is really 
important for the project.
All the best for you too. And feel free to drop an e-mail here or raise issues 
on JIRA if you have any suggestion. 1.0-alpha2 should come out in the first 
quarter of this year.

Bruno

On Friday, 3 January 2020, 7:01:13 am NZDT, Bryan Atsatt 
 wrote:  
 
 Just wanted to let the developers know that this project saved the day for
an important Christmas present for my wife.

She has wanted access to about 30k photos I have in an old Photoshop
Elements catalog (with lots of keywords etc added), but didn't want to use
that app.

This library enabled me to preserve all the data by updating the photos,
adding (approximate) GPS info where missing and making them searchable in
Google Photos by appending keywords to the captions.

She now has all of them in her Google Photos and on a portable drive, with
no PSE required, and is very happy.

So... thanks for all the hard work everyone, and Happy New Decade to you
all.

// Bryan
  

[imaging] Thank you!

[Bryan Atsatt]

Just wanted to let the developers know that this project saved the day for
an important Christmas present for my wife.

She has wanted access to about 30k photos I have in an old Photoshop
Elements catalog (with lots of keywords etc added), but didn't want to use
that app.

This library enabled me to preserve all the data by updating the photos,
adding (approximate) GPS info where missing and making them searchable in
Google Photos by appending keywords to the captions.

She now has all of them in her Google Photos and on a portable drive, with
no PSE required, and is very happy.

So... thanks for all the hard work everyone, and Happy New Decade to you
all.

// Bryan

[imaging] Problem with read/write IPTC fields and charset

[Stéphane Pain]

Hi,

I try to read and write IPTC fields but I think I « lost » charset.

For example, before read and write IPTC fields, the PROVINCE_STATE field was 
Rhône-Alpes but after the value is Rh√¥ne-Alpes.

I am on Mac and my program is :

final ByteSource byteSource = new ByteSourceFile(file);
JpegPhotoshopMetadata metadata = new 
JpegImageParser().getPhotoshopMetadata(byteSource, null);

List newBlocks = new ArrayList();
List newRecords = new ArrayList();

if (metadata != null) {
List oldRecords = metadata.photoshopApp13Data.getRecords();
for (final IptcRecord record : oldRecords) {
newRecords.add(record);
}

newBlocks.addAll(metadata.photoshopApp13Data.getNonIptcBlocks());
}

PhotoshopApp13Data newData = new PhotoshopApp13Data(newRecords, newBlocks);

final File fileTmp = new File(file.getParentFile(), "test.jpg");
os = new FileOutputStream(fileTmp);
os = new BufferedOutputStream(os);
new JpegIptcRewriter().writeIPTC(file, os, newData);

Thank you for your help

Best regards

[imaging] Writing X/YResolution

[Scott Neville]

Hi, 

I am having a problem with writing EXIF Meta Data onto an existing JPEG image 
using commons imaging. I am trying to set the XResolution and the YResolution 
on the image. In this instance I have a photograph of a flat surface taken at 
exactly 90 degrees with a calibrated rule in it. The user has the option of 
specifying the length of the rule (clicking on two parts of the image) and 
entering the phyiscal length. I want to then add the XResolution and 
YResolution so that it can be used later to support printing the image at the 
same physical size (apprciate this might not be 100% accurate). The process 
originally started using scans taken via scanner where the X/YResolution would 
already be on the image and useable for turning the data back into physical 
space. 

I am using the following code: 

private static TiffImageMetadata _readImageMetaData(byte[] pImage) 
{ 
try 
{ 
IImageMetadata tMD = Imaging.getMetadata(pImage); 

if (tMD instanceof JpegImageMetadata) 
{ 
JpegImageMetadata tJMD = (JpegImageMetadata)tMD; 
return tJMD.getExif(); 
} 
else if (tMD instanceof TiffImageMetadata) 
{ 
return (TiffImageMetadata)tMD; 
} 
} 
catch (ImageReadException | IOException tEx) 
{ 
System.out.println(tEx.getMessage()); 
} 

return null; 
} 


private static org.apache.commons.imaging.formats.tiff.write.TiffOutputSet 
_getExifMetadata(TiffImageMetadata oMD, String pUserID, double pPPI, int 
pWidth, int pLength) 
{ 
try 
{ 
//the first version of this would copy the data out of the existing 
TiffImageMetaData rather than creating a new TiffOutputSet 
org.apache.commons.imaging.formats.tiff.write.TiffOutputSet tOutputSet = new 
org.apache.commons.imaging.formats.tiff.write.TiffOutputSet(); 
org.apache.commons.imaging.formats.tiff.write.TiffOutputDirectory 
tOutputDirectory = tOutputSet.getOrCreateRootDirectory(); 

tOutputDirectory.removeField(282); //XResoloution 
tOutputDirectory.removeField(283); //YResoloution 
tOutputDirectory.removeField(296); //ResoloutionUnit 
tOutputDirectory.removeField(256); //ImageWidth 
tOutputDirectory.removeField(257); //ImageLength 

tOutputDirectory.add(org.apache.commons.imaging.formats.tiff.write.TiffOutputField.TIFF_TAG_XRESOLUTION,
 new org.apache.commons.imaging.common.RationalNumber((int)pPPI, 1)); 
tOutputDirectory.add(org.apache.commons.imaging.formats.tiff.write.TiffOutputField.TIFF_TAG_YRESOLUTION,
 new org.apache.commons.imaging.common.RationalNumber((int)pPPI, 1)); 
tOutputDirectory.add(org.apache.commons.imaging.formats.tiff.write.TiffOutputField.TIFF_TAG_RESOLUTION_UNIT,
 (short)2); 

tOutputDirectory.add(org.apache.commons.imaging.formats.tiff.write.TiffOutputField.EXIF_TAG_IMAGE_WIDTH,
 pWidth); 
tOutputDirectory.add(org.apache.commons.imaging.formats.tiff.write.TiffOutputField.EXIF_TAG_IMAGE_HEIGHT,
 pLength); 
tOutputDirectory.add(org.apache.commons.imaging.formats.tiff.write.TiffOutputField.TIFF_TAG_ARTIST,
 pUserID); 

return tOutputSet; 
} 
catch (ImageWriteException tEx) 
{ 
System.out.println(tEx.getMessage()); 
return null; 
} 
} 



TiffImageMetadata tMetaData = _readImageMetaData(pInstruction.mGetBytes); 
//passing in a byte array[] 
BufferedImage tImage = ImageIO.read(new 
ByteArrayInputStream(pInstruction.mGetBytes)); 

//there is potentially some cropping done here depending on settings in 
pInstruction, left out for space 

org.apache.commons.imaging.formats.tiff.write.TiffOutputSet tOutputSet = 
_getExifMetadata(tMetaData, pUserID, pInstruction.mImagePPI, tImage.getWidth(), 
tImage.getHeight()); 

ByteArrayOutputStream tBAOS = new ByteArrayOutputStream(); 

//here we use ImageIO to write out the image into tBAOS (this will be the one 
we have potentially cropped) 

org.apache.commons.imaging.formats.jpeg.exif.ExifRewriter tRW = new 
org.apache.commons.imaging.formats.jpeg.exif.ExifRewriter(); 
byte[] tData = tBAOS.toByteArray(); 
tBAOS = new ByteArrayOutputStream(); 
tRW.updateExifMetadataLossless(tData, tBAOS, tOutputSet); 





Once this has run the image held in bytes in tBAOS will be an image with the 
EXIF correctly set for the artist, but the XResolution and YResolution will be 
both set to 96 DPI reegardless of any settings I put in the PPI (I hard coded a 
large value and a small one, and they always come out at 96). 

Am I doing something wrong or does commons imaging not support setting this 
data? 

Thanks 

Scott 



~
DISCLAIMER: This email message and any attachments is for the sole
use of the intended recipient(s) and may contain confidential and
privileged information.  Any unauthorised review, use, disclosure
or distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of
the original message.

The views expressed in this message may not necessarily reflect the
views of Bluestar Software Ltd.

Bluestar Software Ltd, Registered in England
Company Registration No. 03537860, VAT No. 709 2751

Re: commons-imaging stability?

[P. Ottlinger]

Am 25.01.19 um 23:47 schrieb Bruno P. Kinoshita:
> If you intend to use Commons Imaging, it might be a good idea to wait for the 
> 1.0 release. Can't promise when I will have time to work on the release 
> again, but my plan is to have it released in February (or earlier). Otherwise 
> my next long window for OSS development would be April.
> Other committers may step in and work on it before as well. If you have time 
> to help with the release, especially testing, that would be great too.

+1

Thanks for a release with the current functionality.

Cheers,
Phil

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: commons-imaging stability?

[Bruno P. Kinoshita]

 Hi Matt,
The project was called Sanselan during its incubation in ASF. It had a few full 
releases, without reaching a 1.0 (0.97 was the last release line I believe).
Then when it was moved under commons, got renamed to Apache Commons Imaging. 
Several packages changes, and the code base has changed significantly since 
Sanselan too.
Alas, there was a long hiatus since Sanselan's last release. Commons Imaging 
1.0 vote came out some months ago, but due to some issues with that release, it 
was postponed. I am now looking for some spare time to prepare the 1.0 release 
again.
If you intend to use Commons Imaging, it might be a good idea to wait for the 
1.0 release. Can't promise when I will have time to work on the release again, 
but my plan is to have it released in February (or earlier). Otherwise my next 
long window for OSS development would be April.
Other committers may step in and work on it before as well. If you have time to 
help with the release, especially testing, that would be great too.
CheersBruno

On Saturday, 26 January 2019, 11:03:32 AM NZDT, Matt Seil 
 wrote:  
 
 Greetings!

I'm the project Co-Lead for OWASP's ESAPI project, and I'm looking
into this library to enhance capability.  What I'm unsure about is
that it looks like every release was either "incubator" or "Snapshot,"
and if we brought it on as a dependency, many companies have rules
against using "snapshot" terminology.

What kind of instability are we talking about?  Is it security related
or just bugs for particular file types?

This is what sparked my interest:
https://www.owasp.org/index.php/Protect_FileUpload_Against_Malicious_File#Case_n.C2.B03:_Images

-- 
xeno6696

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

  

commons-imaging stability?

[Matt Seil]

Greetings!

I'm the project Co-Lead for OWASP's ESAPI project, and I'm looking
into this library to enhance capability.  What I'm unsure about is
that it looks like every release was either "incubator" or "Snapshot,"
and if we brought it on as a dependency, many companies have rules
against using "snapshot" terminology.

What kind of instability are we talking about?  Is it security related
or just bugs for particular file types?

This is what sparked my interest:
https://www.owasp.org/index.php/Protect_FileUpload_Against_Malicious_File#Case_n.C2.B03:_Images

-- 
xeno6696

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [imaging] Is it possible to release the current version as a release candidate from ASF

[Bruno P. Kinoshita]

Hi Phil,

I just need to find some time to upgrade a few plugins/dependencies, learn 
about the release-plugin, and leave everything ready for the 1.0-alpha release, 
but all issues for this version were fixed already [1][2]



Hopefully soon we might have a 1.0-alpha in Maven Central.

Cheers
Bruno



[1] https://markmail.org/message/txsxrr7mlx2cw5rg

[2] https://markmail.org/thread/uq2pm24lx2hc5eux





From: P. Ottlinger 
To: user@commons.apache.org 
Sent: Friday, 7 September 2018 7:14 AM
Subject: [imaging] Is it possible to release the current version as a release 
candidate from ASF



Hi,


while going away from Sanselan

https://mvnrepository.com/artifact/org.apache.sanselan/sanselan/0.97-incubator

to

https://mvnrepository.com/artifact/org.apache.commons/commons-imaging

I'm unable to find an official release version.


This hinders adoption in Travis as SNAPSHOT references happen not to

work all the time.


Is it possible to do a release of the current version - if it's not a

1.0.0 I'd be glad with a 0.9.8 from apache/in maven central.


What do you think?


Thanks,

Phil


-

To unsubscribe, e-mail: user-unsubscr...@commons.apache.org

For additional commands, e-mail: user-h...@commons.apache.org

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

[imaging] Is it possible to release the current version as a release candidate from ASF

[P. Ottlinger]

Hi,

while going away from Sanselan
https://mvnrepository.com/artifact/org.apache.sanselan/sanselan/0.97-incubator
to
https://mvnrepository.com/artifact/org.apache.commons/commons-imaging
I'm unable to find an official release version.

This hinders adoption in Travis as SNAPSHOT references happen not to
work all the time.

Is it possible to do a release of the current version - if it's not a
1.0.0 I'd be glad with a 0.9.8 from apache/in maven central.

What do you think?

Thanks,
Phil

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [imaging] Comment tag problem

[Bruno P. Kinoshita]

Hi Andrea,

Thanks for updating the thread with a solution for other users!

I am planning to have a cycle to work on issues in JIRA for imaging, and try to 
push it a bit closer to a 1.0 release. So if you have other issues or 
enhancements for the library, feel free to log them in JIRA or drop a message 
here or on the dev-list if necessary.

Cheers

Bruno





From: andrea antonello 
To: Commons Users List  
Sent: Friday, 6 July 2018 10:26 PM
Subject: Re: [imaging] Comment tag problem



Hi Bruno, all,

a short update for the original request.


I have been able to lay my hands on the C code that was writing the

comment (to remind, a comment in the COM segment).

It runs out to be something quite simeple, if you know how to do it.


Basically, it is done by squeezing the comment into the existing image

(i.e. doing a modified copy), using the following few lines of code :


String inPath = "blah.jpg";

String outPath = "blah_out.jpg";

try (RandomAccessFile raIn = new RandomAccessFile(new File(inPath), "r");

RandomAccessFile raOut = new RandomAccessFile(new

File(outPath), "rw");) {


// first 2 bytes are the same of the original image

raOut.write(raIn.read());

raOut.write(raIn.read());


// 2 bytes to identify the comment

raOut.write(0xFF);

raOut.write(0xFE);


// define the length of the comment you are going to insert

int length = 3 + geoInfo.length();

raOut.write(length / 0x100);

raOut.write(length % 0x100);


// write the bytes of the comment

raOut.write(geoInfo.getBytes());


// add final 0

raOut.write(0);


// write the rest of the original image

int b;

while( (b = raIn.read()) != -1 ) {

raOut.write(b);

}

}


This could be done better and I have no idea if this is defined in some specs.

But it works and it might help someone in my same need.


Cheers,

Andrea




On Mon, Apr 30, 2018 at 10:34 AM andrea antonello

 wrote:

>

> Hi Bruno,

> thanks again for coming back to me.

>

> > I believe the issue is that what you are trying to do is to add a segment, 
> > not a tag.

> >

> >

> > I think what you are trying to add, is a comment in the COM segment.

>

> yes, exactly.

>

> > Have a look at this page

> >

> > [1] https://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/JPEG.html

> >

> > There you should find a table. Where you see the JPEG tags, they are the 
> > identifier of

> > JPEG segments.

> >

> > Near the bottom of that table, you will find the COM segment. It is a bit 
> > confusing

> > to speak about tags, segments, markers. So here's a practical example with 
> > exiftool,

> > which you mentioned before you used too.

> >

> > 1. This Exiv2 page has a sample image with some metadata 
> > http://www.exiv2.org/sample.html. Save it somewhere

> > 2. Run `exiftool -htmldump img_1771.jpg > before.html`

> > 3. Run `exiftool -comment=KIAORA img_1771.jpg`

> > 4. Run `exiftool -htmldump img_1771.jpg > after.html`

> >

> >

> > Now open before.html and after.html. Search for "segment" in your browser. 
> > In before.html, you should find

> > just the following:

> >

> > "APP0 JFIF segment APP1 header Exif header"

> >

> > Which if you look at [1] you should be able to compare the EXIF tags in 
> > that segment,

> > matching by tag name (e.g.FocalLength) and perhaps by group name too (e.g.

> > ExifIFD).

> >

> > You won't find the COM segment in before.html, as the Exiv2 sample image 
> > doesn't have it.

> >

> >

> > Now, if you open after.html, and search for "KIAORA", or if you have 
> > noticed before when you

> > searched by "segment", there should be now a second segment. Look again at 
> > [1], near the

> > bottom of the first table. You should find a COM segment.

> >

> > In [imaging], there is a certain distinction between tag and segment. The 
> > example I had sent before

> > was for tags, sorry. I am not aware of a way to modify the COM segment in 
> > [imaging] at the moment.

> > There is an open JIRA ticket for that (sent in my previous e-mail).

>

> Ok, in fact I had been fooled by the code that had been added and

> thought that there was a way to do it fo which you didn't know. Sorry,

> my misunderstanding here.

> Now everything is clear, thank you.

>

> > Might be easier to use the UserComment tag perhaps, or dig a bit deeper 
> > into the code to

> > see if you can find a way to modify it in a lower level, by modifying bytes 
> > perhaps...

> >

>

Re: [imaging] Comment tag problem

[andrea antonello]

Hi Bruno, all,
a short update for the original request.

I have been able to lay my hands on the C code that was writing the
comment (to remind, a comment in the COM segment).
It runs out to be something quite simeple, if you know how to do it.

Basically, it is done by squeezing the comment into the existing image
(i.e. doing a modified copy), using the following few lines of code :

String inPath = "blah.jpg";
String outPath = "blah_out.jpg";
try (RandomAccessFile raIn = new RandomAccessFile(new File(inPath), "r");
RandomAccessFile raOut = new RandomAccessFile(new
File(outPath), "rw");) {

// first 2 bytes are the same of the original image
raOut.write(raIn.read());
raOut.write(raIn.read());

// 2 bytes to identify the comment
raOut.write(0xFF);
raOut.write(0xFE);

// define the length of the comment you are going to insert
int length = 3 + geoInfo.length();
raOut.write(length / 0x100);
raOut.write(length % 0x100);

// write the bytes of the comment
raOut.write(geoInfo.getBytes());

// add final 0
raOut.write(0);

// write the rest of the original image
int b;
while( (b = raIn.read()) != -1 ) {
raOut.write(b);
}
}

This could be done better and I have no idea if this is defined in some specs.
But it works and it might help someone in my same need.

Cheers,
Andrea



On Mon, Apr 30, 2018 at 10:34 AM andrea antonello
 wrote:
>
> Hi Bruno,
> thanks again for coming back to me.
>
> > I believe the issue is that what you are trying to do is to add a segment, 
> > not a tag.
> >
> >
> > I think what you are trying to add, is a comment in the COM segment.
>
> yes, exactly.
>
> > Have a look at this page
> >
> > [1] https://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/JPEG.html
> >
> > There you should find a table. Where you see the JPEG tags, they are the 
> > identifier of
> > JPEG segments.
> >
> > Near the bottom of that table, you will find the COM segment. It is a bit 
> > confusing
> > to speak about tags, segments, markers. So here's a practical example with 
> > exiftool,
> > which you mentioned before you used too.
> >
> > 1. This Exiv2 page has a sample image with some metadata 
> > http://www.exiv2.org/sample.html. Save it somewhere
> > 2. Run `exiftool -htmldump img_1771.jpg > before.html`
> > 3. Run `exiftool -comment=KIAORA img_1771.jpg`
> > 4. Run `exiftool -htmldump img_1771.jpg > after.html`
> >
> >
> > Now open before.html and after.html. Search for "segment" in your browser. 
> > In before.html, you should find
> > just the following:
> >
> > "APP0 JFIF segment APP1 header Exif header"
> >
> > Which if you look at [1] you should be able to compare the EXIF tags in 
> > that segment,
> > matching by tag name (e.g.FocalLength) and perhaps by group name too (e.g.
> > ExifIFD).
> >
> > You won't find the COM segment in before.html, as the Exiv2 sample image 
> > doesn't have it.
> >
> >
> > Now, if you open after.html, and search for "KIAORA", or if you have 
> > noticed before when you
> > searched by "segment", there should be now a second segment. Look again at 
> > [1], near the
> > bottom of the first table. You should find a COM segment.
> >
> > In [imaging], there is a certain distinction between tag and segment. The 
> > example I had sent before
> > was for tags, sorry. I am not aware of a way to modify the COM segment in 
> > [imaging] at the moment.
> > There is an open JIRA ticket for that (sent in my previous e-mail).
>
> Ok, in fact I had been fooled by the code that had been added and
> thought that there was a way to do it fo which you didn't know. Sorry,
> my misunderstanding here.
> Now everything is clear, thank you.
>
> > Might be easier to use the UserComment tag perhaps, or dig a bit deeper 
> > into the code to
> > see if you can find a way to modify it in a lower level, by modifying bytes 
> > perhaps...
> >
> > Feel free to chime in there and watch that ticket if you would like to see 
> > that feature
> > implemented, or give any suggestions.
> >
> >
> > Hope that helps,
>
>
> It does, thanks a lot.
>
> All the best,
> Andrea
>
> >
> > Bruno
> >
> > 
> > From: andrea antonello 
> > To: Commons Users List 
> > Sent: Monday, 30 April 2018 7:55 PM
> > Subject: Re: [imaging] Comment tag problem
> >
> >
> >
> > Hi Bruno and Martin,
> > thanks a ton for y

Re: [imaging] Comment tag problem

[andrea antonello]

Hi Bruno,
thanks again for coming back to me.

> I believe the issue is that what you are trying to do is to add a segment, 
> not a tag.
>
>
> I think what you are trying to add, is a comment in the COM segment.

yes, exactly.

> Have a look at this page
>
> [1] https://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/JPEG.html
>
> There you should find a table. Where you see the JPEG tags, they are the 
> identifier of
> JPEG segments.
>
> Near the bottom of that table, you will find the COM segment. It is a bit 
> confusing
> to speak about tags, segments, markers. So here's a practical example with 
> exiftool,
> which you mentioned before you used too.
>
> 1. This Exiv2 page has a sample image with some metadata 
> http://www.exiv2.org/sample.html. Save it somewhere
> 2. Run `exiftool -htmldump img_1771.jpg > before.html`
> 3. Run `exiftool -comment=KIAORA img_1771.jpg`
> 4. Run `exiftool -htmldump img_1771.jpg > after.html`
>
>
> Now open before.html and after.html. Search for "segment" in your browser. In 
> before.html, you should find
> just the following:
>
> "APP0 JFIF segment APP1 header Exif header"
>
> Which if you look at [1] you should be able to compare the EXIF tags in that 
> segment,
> matching by tag name (e.g.FocalLength) and perhaps by group name too (e.g.
> ExifIFD).
>
> You won't find the COM segment in before.html, as the Exiv2 sample image 
> doesn't have it.
>
>
> Now, if you open after.html, and search for "KIAORA", or if you have noticed 
> before when you
> searched by "segment", there should be now a second segment. Look again at 
> [1], near the
> bottom of the first table. You should find a COM segment.
>
> In [imaging], there is a certain distinction between tag and segment. The 
> example I had sent before
> was for tags, sorry. I am not aware of a way to modify the COM segment in 
> [imaging] at the moment.
> There is an open JIRA ticket for that (sent in my previous e-mail).

Ok, in fact I had been fooled by the code that had been added and
thought that there was a way to do it fo which you didn't know. Sorry,
my misunderstanding here.
Now everything is clear, thank you.

> Might be easier to use the UserComment tag perhaps, or dig a bit deeper into 
> the code to
> see if you can find a way to modify it in a lower level, by modifying bytes 
> perhaps...
>
> Feel free to chime in there and watch that ticket if you would like to see 
> that feature
> implemented, or give any suggestions.
>
>
> Hope that helps,


It does, thanks a lot.

All the best,
Andrea

>
> Bruno
>
> 
> From: andrea antonello <andrea.antone...@gmail.com>
> To: Commons Users List <user@commons.apache.org>
> Sent: Monday, 30 April 2018 7:55 PM
> Subject: Re: [imaging] Comment tag problem
>
>
>
> Hi Bruno and Martin,
> thanks a ton for your help.
>
> I tried the code but nothing changes.
>
> My output doesn't have a COM segment, but I noticed something.
>
> This is the info dump of the image before applying Martin's code:
>
> File Type = JPEG
> File Size = 231038
> @0=0   :  
> @0x002=2   : 0xffe0 length 16, 'JFIF'
> @0x00b=11  :  Version   = 1.2
> @0x00d=13  :  Units = 'aspect ratio'
> @0x00e=14  :  Xdensity  = 1
> @0x010=16  :  Ydensity  = 1
> @0x012=18  :  XThumbnail= 0
> @0x013=19  :  YThumbnail= 0
> @0x013=19  :
> @0x014=20  : length 67
> @0x059=89  : length 67
> @0x09e=158 : length 17, 8 bits/sample,
> components=3, width=1418, height=969
> @0x0b1=177 : length 31 table class = 0 table id = 0
> @0x0d2=210 : length 181 table class = 0 table id = 1
> @0x189=393 : length 31 table class = 1 table id = 0
> @0x1aa=426 : length 181 table class = 1 table id = 1
> @0x261=609 : length 12  start of JPEG data, 3
> components 1374042 pixels
> @0x003867c=231036  :   JPEG length 231038
> -0x003867d=231037  :  END OF FILE
> @0=0   :  Start of JPEG baseline DCT compressed primary
> image [1418x969] length 231038 (APP0)
> -0x003867d=231037  :End of JPEG primary image data
> Number of images = 1
> File Format = JPEG/APP0/JFIF
>
>
> and this is when I do apply it:
>
> File Type = JPEG
> File Size = 231183
> @0=0   :  
> @0x002=2   : 0xffe0 length 16, 'JFIF'
> @0x00b=11  :  Version   = 1.2
> @0x00d=13  :  Units = 'aspect ratio'
> @0x00e=14  :  Xdensity

Re: [imaging] Comment tag problem

[Bruno P. Kinoshita]

Hi Andrea,

I believe the issue is that what you are trying to do is to add a segment, not 
a tag.


I think what you are trying to add, is a comment in the COM segment.

Have a look at this page 

[1] https://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/JPEG.html

There you should find a table. Where you see the JPEG tags, they are the 
identifier of
JPEG segments.

Near the bottom of that table, you will find the COM segment. It is a bit 
confusing
to speak about tags, segments, markers. So here's a practical example with 
exiftool,
which you mentioned before you used too.

1. This Exiv2 page has a sample image with some metadata 
http://www.exiv2.org/sample.html. Save it somewhere
2. Run `exiftool -htmldump img_1771.jpg > before.html`
3. Run `exiftool -comment=KIAORA img_1771.jpg`
4. Run `exiftool -htmldump img_1771.jpg > after.html`


Now open before.html and after.html. Search for "segment" in your browser. In 
before.html, you should find
just the following:

"APP0 JFIF segment APP1 header Exif header"

Which if you look at [1] you should be able to compare the EXIF tags in that 
segment,
matching by tag name (e.g.FocalLength) and perhaps by group name too (e.g. 
ExifIFD).

You won't find the COM segment in before.html, as the Exiv2 sample image 
doesn't have it.


Now, if you open after.html, and search for "KIAORA", or if you have noticed 
before when you
searched by "segment", there should be now a second segment. Look again at [1], 
near the
bottom of the first table. You should find a COM segment.

In [imaging], there is a certain distinction between tag and segment. The 
example I had sent before
was for tags, sorry. I am not aware of a way to modify the COM segment in 
[imaging] at the moment.
There is an open JIRA ticket for that (sent in my previous e-mail).

Might be easier to use the UserComment tag perhaps, or dig a bit deeper into 
the code to
see if you can find a way to modify it in a lower level, by modifying bytes 
perhaps...


Feel free to chime in there and watch that ticket if you would like to see that 
feature
implemented, or give any suggestions.


Hope that helps,

Bruno


From: andrea antonello <andrea.antone...@gmail.com>
To: Commons Users List <user@commons.apache.org> 
Sent: Monday, 30 April 2018 7:55 PM
Subject: Re: [imaging] Comment tag problem



Hi Bruno and Martin,
thanks a ton for your help.

I tried the code but nothing changes.

My output doesn't have a COM segment, but I noticed something.

This is the info dump of the image before applying Martin's code:

File Type = JPEG
File Size = 231038
@0=0   :  
@0x002=2   : 0xffe0 length 16, 'JFIF'
@0x00b=11  :  Version   = 1.2
@0x00d=13  :  Units = 'aspect ratio'
@0x00e=14  :  Xdensity  = 1
@0x010=16  :  Ydensity  = 1
@0x012=18  :  XThumbnail= 0
@0x013=19  :  YThumbnail= 0
@0x013=19  :
@0x014=20  : length 67
@0x059=89  : length 67
@0x09e=158 : length 17, 8 bits/sample,
components=3, width=1418, height=969
@0x0b1=177 : length 31 table class = 0 table id = 0
@0x0d2=210 : length 181 table class = 0 table id = 1
@0x189=393 : length 31 table class = 1 table id = 0
@0x1aa=426 : length 181 table class = 1 table id = 1
@0x261=609 : length 12  start of JPEG data, 3
components 1374042 pixels
@0x003867c=231036  :   JPEG length 231038
-0x003867d=231037  :  END OF FILE
@0=0   :  Start of JPEG baseline DCT compressed primary
image [1418x969] length 231038 (APP0)
-0x003867d=231037  :End of JPEG primary image data
Number of images = 1
File Format = JPEG/APP0/JFIF


and this is when I do apply it:

File Type = JPEG
File Size = 231183
@0=0   :  
@0x002=2   : 0xffe0 length 16, 'JFIF'
@0x00b=11  :  Version   = 1.2
@0x00d=13  :  Units = 'aspect ratio'
@0x00e=14  :  Xdensity  = 1
@0x010=16  :  Ydensity  = 1
@0x012=18  :  XThumbnail= 0
@0x013=19  :  YThumbnail= 0
@0x013=19  :
@0x014=20  : 0xffe1 length 143,
'http://ns.adobe.com/xap/1.0/' - unknown format - (not dumped: use -A)
-0x0a4=164 :
@0x0a5=165 : length 67
@0x0ea=234 : length 67
@0x12f=303 : length 17, 8 bits/sample,
components=3, width=1418, height=969
@0x142=322 : length 31 table class = 0 table id = 0
@0x163=355 : length 181 table class = 0 table id = 1
@0x21a=538 : length 31 table class = 1 table id = 0
@0x23b=571 : length 181 table class = 1 table id = 1
@0x2f2=754 : length 12  start of JPEG data, 3
components 1374042 pixels
@0x003870d=231181  :   JPEG length 231183
-0x003870e=231182  :  EN

Re: [imaging] Comment tag problem

[andrea antonello]

Hi Bruno and Martin,
thanks a ton for your help.

I tried the code but nothing changes.

My output doesn't have a COM segment, but I noticed something.

This is the info dump of the image before applying Martin's code:

File Type = JPEG
File Size = 231038
@0=0   :  
@0x002=2   : 0xffe0 length 16, 'JFIF'
@0x00b=11  :  Version   = 1.2
@0x00d=13  :  Units = 'aspect ratio'
@0x00e=14  :  Xdensity  = 1
@0x010=16  :  Ydensity  = 1
@0x012=18  :  XThumbnail= 0
@0x013=19  :  YThumbnail= 0
@0x013=19  :
@0x014=20  : length 67
@0x059=89  : length 67
@0x09e=158 : length 17, 8 bits/sample,
components=3, width=1418, height=969
@0x0b1=177 : length 31 table class = 0 table id = 0
@0x0d2=210 : length 181 table class = 0 table id = 1
@0x189=393 : length 31 table class = 1 table id = 0
@0x1aa=426 : length 181 table class = 1 table id = 1
@0x261=609 : length 12  start of JPEG data, 3
components 1374042 pixels
@0x003867c=231036  :   JPEG length 231038
-0x003867d=231037  :  END OF FILE
@0=0   :  Start of JPEG baseline DCT compressed primary
image [1418x969] length 231038 (APP0)
-0x003867d=231037  :End of JPEG primary image data
Number of images = 1
File Format = JPEG/APP0/JFIF


and this is when I do apply it:

File Type = JPEG
File Size = 231183
@0=0   :  
@0x002=2   : 0xffe0 length 16, 'JFIF'
@0x00b=11  :  Version   = 1.2
@0x00d=13  :  Units = 'aspect ratio'
@0x00e=14  :  Xdensity  = 1
@0x010=16  :  Ydensity  = 1
@0x012=18  :  XThumbnail= 0
@0x013=19  :  YThumbnail= 0
@0x013=19  :
@0x014=20  : 0xffe1 length 143,
'http://ns.adobe.com/xap/1.0/' - unknown format - (not dumped: use -A)
-0x0a4=164 :
@0x0a5=165 : length 67
@0x0ea=234 : length 67
@0x12f=303 : length 17, 8 bits/sample,
components=3, width=1418, height=969
@0x142=322 : length 31 table class = 0 table id = 0
@0x163=355 : length 181 table class = 0 table id = 1
@0x21a=538 : length 31 table class = 1 table id = 0
@0x23b=571 : length 181 table class = 1 table id = 1
@0x2f2=754 : length 12  start of JPEG data, 3
components 1374042 pixels
@0x003870d=231181  :   JPEG length 231183
-0x003870e=231182  :  END OF FILE
@0=0   :  Start of JPEG baseline DCT compressed primary
image [1418x969] length 231183
-0x003870e=231182  :End of JPEG primary image data
Number of images = 1
File Format = JPEG/APP0/JFIF/APP1

It looks like what I did got into the tag: JPEG_APP1, while not
JPEG_COM has been created as in:

File Type = JPEG
File Size = 438694
@0=0   :  
@0x002=2   : length 137:
''GEO-Information,46.5640616313:11.523790723,46.5640616313:11.5093674258,46.5585048222:11.523790723,46.5585048222:11.5093674258,0.00\0''
@0x08d=141 : 0xffe0 length 16, 'JFIF'
@0x096=150 :  Version   = 1.1
[...]


Did I miss something or can something be changed to get there?

I tried to have a look at the mentioned testcase but have not been
able to understand how to switch segment or how segments are chosen in
first place.

Any idea?
Thank you,
Andrea







On Sat, Apr 28, 2018 at 3:15 AM, Bruno P. Kinoshita
<brunodepau...@yahoo.com.br.invalid> wrote:
> Hi Martin,
>
>
>>if your requirement is to insert a comment regardless of Java being installed 
>>why not insert a XMP comment into JPEG or GIF using exiv2 tool
>
>
> It's actually Andrea who is working with comments & JPEG images. I was just 
> trying to help him, assuming he wants/needs to do that in Java. He pointed 
> that he could do that with exiftool too (see previous e-mails in the thread 
> for more).
>
> @Andrea, see Martin's code in the e-mail below.
> Thanks Martin!
> Bruno
>
>
>
> 
> From: Martin Gainty <mgai...@hotmail.com>
> To: Commons Users List <user@commons.apache.org>; Bruno P. Kinoshita 
> <brunodepau...@yahoo.com.br>
> Sent: Saturday, 28 April 2018 5:38 AM
> Subject: Re: [imaging] Comment tag problem
>
>
>
> Bruno
>
> if your requirement is to insert a comment regardless of Java being installed 
> why not insert a XMP comment into JPEG or GIF using exiv2 tool
>
> http://www.exiv2.org/manpage.html
>
> Exiv2 utility manual - Image metadata library and 
> tools<http://www.exiv2.org/manpage.html>
> www.exiv2.org
> Open Source Exif, IPTC and XMP metadata library and tools with Exif MakerNote 
> and read/write support
>
>
> MG>see below
>
> ______

Re: [imaging] Comment tag problem

[Bruno P. Kinoshita]

Hi Martin,


>if your requirement is to insert a comment regardless of Java being installed 
>why not insert a XMP comment into JPEG or GIF using exiv2 tool


It's actually Andrea who is working with comments & JPEG images. I was just 
trying to help him, assuming he wants/needs to do that in Java. He pointed that 
he could do that with exiftool too (see previous e-mails in the thread for 
more).

@Andrea, see Martin's code in the e-mail below.
Thanks Martin!
Bruno




From: Martin Gainty <mgai...@hotmail.com>
To: Commons Users List <user@commons.apache.org>; Bruno P. Kinoshita 
<brunodepau...@yahoo.com.br> 
Sent: Saturday, 28 April 2018 5:38 AM
Subject: Re: [imaging] Comment tag problem



Bruno

if your requirement is to insert a comment regardless of Java being installed 
why not insert a XMP comment into JPEG or GIF using exiv2 tool

http://www.exiv2.org/manpage.html

Exiv2 utility manual - Image metadata library and 
tools<http://www.exiv2.org/manpage.html>
www.exiv2.org
Open Source Exif, IPTC and XMP metadata library and tools with Exif MakerNote 
and read/write support


MG>see below


From: Bruno P. Kinoshita <brunodepau...@yahoo.com.br.INVALID>
Sent: Friday, April 27, 2018 8:39 AM
To: Commons Users List
Subject: Re: [imaging] Comment tag problem

Hi Andrea!

Today spent some minutes with Eclipse and the code base, plus exiftool, to see 
where that comment was coming from.

That COM, or Comment, that you see in exiftool output is not exactly a metadata 
tag. It is actually a JPEG Segment. Sorry for the other suggestions.

As far as I know, we are not able to change the segments, but only the metadata 
within the TIFF/EXIF directories & tags [2].

You can still use comments if that's OK, but not sure how you would achieve 
adding the Comment in Java.
MG>testXMPInsert borrowed from JpegXmpRewriteTest.java
{
// test insert
String newXmpXml = "comment";
//subin your fileName to imageFile.getName()
File updated = createTempFile(imageFile.getName() + ".", ".jpg");
OutputStream os = null;
try
{
os = new FileOutputStream(updated);
os = new BufferedOutputStream(os);
new org.apache.sanselan.formats.jpeg..xmp.JpegXmpRewriter().updateXmpXml(
  
org.apache.sanselan.common.byteSources.ByteSourceFile(noXmpFile), os,
newXmpXml);
} finally
{
os.close();
os = null;
}

// Debug.debug("Source Segments:");
// new JpegUtils().dumpJFIF(new ByteSourceFile(updated));

String outXmp = new 
org.apache.sanselan.formats.jpeg.JpegImageParser().getXmpXml(
new ByteSourceFile(updated), params);
assertNotNull(outXmp);
assertEquals(outXmp, newXmpXml);
}

MG>please confirm this works for you
MG>required sanselanependency for pom.xml:
org.apache.sanselan
  sanselan
  0.97-incubator


Bruno
MG>?
MG>Martin-


[1] http://u88.n24.queensu.ca/exiftool/forum/index.php?topic=3893.0
Writing 
comments<http://u88.n24.queensu.ca/exiftool/forum/index.php?topic=3893.0>
u88.n24.queensu.ca
Writing comments



[2] https://issues.apache.org/jira/browse/IMAGING-55



From: andrea antonello <andrea.antone...@gmail.com>
To: Commons Users List <user@commons.apache.org>
Sent: Thursday, 26 April 2018 8:02 PM
Subject: Re: [imaging] Comment tag problem



> I normally use exiftool to compare what imaging is producing. The htmldump is 
> quite useful.

I just ran the normal info extraction and here you see the comment I
would like to reproduce (Comment):

ExifTool Version Number : 10.94
File Name   : 109_Background.jpg
Directory   : .
File Size   : 428 kB
File Modification Date/Time : 2018:03:31 11:01:51+02:00
File Access Date/Time   : 2018:04:26 08:59:06+02:00
File Inode Change Date/Time : 2018:03:31 11:01:56+02:00
File Permissions: rw-rw-r--
File Type   : JPEG
File Type Extension : jpg
MIME Type   : image/jpeg
Comment :
GEO-Information,46.5640616313:11.523790723,46.5640616313:11.5093674258,46.5585048222:11.523790723,46.5585048222:11.5093674258,0.00
JFIF Version: 1.01
Resolution Unit : inches
X Resolution: 96
Y Resolution: 96
Image Width : 1608
Image Height: 901
Encoding Process: Baseline DCT, Huffman coding
Bits Per Sample : 8
Color Components: 3
Y Cb Cr Sub Sampling: YCbCr4:2:0 (2 2)
Image Size  : 1608x901
Megapixels  : 1.4


> I thought you had to create the tag in Java, but if you can use other tools 
> and it's easier for you, then that might be the best option.

Yes, I do have to recreate it in jav

Re: [imaging] Comment tag problem

[Martin Gainty]

Bruno

if your requirement is to insert a comment regardless of Java being installed 
why not insert a XMP comment into JPEG or GIF using exiv2 tool

http://www.exiv2.org/manpage.html

Exiv2 utility manual - Image metadata library and 
tools<http://www.exiv2.org/manpage.html>
www.exiv2.org
Open Source Exif, IPTC and XMP metadata library and tools with Exif MakerNote 
and read/write support


MG>see below


From: Bruno P. Kinoshita <brunodepau...@yahoo.com.br.INVALID>
Sent: Friday, April 27, 2018 8:39 AM
To: Commons Users List
Subject: Re: [imaging] Comment tag problem

Hi Andrea!

Today spent some minutes with Eclipse and the code base, plus exiftool, to see 
where that comment was coming from.

That COM, or Comment, that you see in exiftool output is not exactly a metadata 
tag. It is actually a JPEG Segment. Sorry for the other suggestions.

As far as I know, we are not able to change the segments, but only the metadata 
within the TIFF/EXIF directories & tags [2].

You can still use comments if that's OK, but not sure how you would achieve 
adding the Comment in Java.
MG>testXMPInsert borrowed from JpegXmpRewriteTest.java
{
// test insert
String newXmpXml = "comment";
//subin your fileName to imageFile.getName()
File updated = createTempFile(imageFile.getName() + ".", ".jpg");
OutputStream os = null;
try
{
os = new FileOutputStream(updated);
os = new BufferedOutputStream(os);
new org.apache.sanselan.formats.jpeg..xmp.JpegXmpRewriter().updateXmpXml(
  
org.apache.sanselan.common.byteSources.ByteSourceFile(noXmpFile), os,
newXmpXml);
} finally
{
os.close();
os = null;
}

// Debug.debug("Source Segments:");
// new JpegUtils().dumpJFIF(new ByteSourceFile(updated));

String outXmp = new 
org.apache.sanselan.formats.jpeg.JpegImageParser().getXmpXml(
new ByteSourceFile(updated), params);
assertNotNull(outXmp);
assertEquals(outXmp, newXmpXml);
}

MG>please confirm this works for you
MG>required sanselanependency for pom.xml:
 org.apache.sanselan
  sanselan
  0.97-incubator


Bruno
MG>?
MG>Martin-


[1] http://u88.n24.queensu.ca/exiftool/forum/index.php?topic=3893.0
Writing 
comments<http://u88.n24.queensu.ca/exiftool/forum/index.php?topic=3893.0>
u88.n24.queensu.ca
Writing comments



[2] https://issues.apache.org/jira/browse/IMAGING-55



From: andrea antonello <andrea.antone...@gmail.com>
To: Commons Users List <user@commons.apache.org>
Sent: Thursday, 26 April 2018 8:02 PM
Subject: Re: [imaging] Comment tag problem



> I normally use exiftool to compare what imaging is producing. The htmldump is 
> quite useful.

I just ran the normal info extraction and here you see the comment I
would like to reproduce (Comment):

ExifTool Version Number : 10.94
File Name   : 109_Background.jpg
Directory   : .
File Size   : 428 kB
File Modification Date/Time : 2018:03:31 11:01:51+02:00
File Access Date/Time   : 2018:04:26 08:59:06+02:00
File Inode Change Date/Time : 2018:03:31 11:01:56+02:00
File Permissions: rw-rw-r--
File Type   : JPEG
File Type Extension : jpg
MIME Type   : image/jpeg
Comment :
GEO-Information,46.5640616313:11.523790723,46.5640616313:11.5093674258,46.5585048222:11.523790723,46.5585048222:11.5093674258,0.00
JFIF Version: 1.01
Resolution Unit : inches
X Resolution: 96
Y Resolution: 96
Image Width : 1608
Image Height: 901
Encoding Process: Baseline DCT, Huffman coding
Bits Per Sample : 8
Color Components: 3
Y Cb Cr Sub Sampling: YCbCr4:2:0 (2 2)
Image Size  : 1608x901
Megapixels  : 1.4


> I thought you had to create the tag in Java, but if you can use other tools 
> and it's easier for you, then that might be the best option.

Yes, I do have to recreate it in java. I was just trying to use other
tools to check what the comment tag is.
Do you have an idea on how to create the above Comment tag?

> Otherwise you can create pretty much any other metadata tag you'd like with 
> some Java coding.

That is what I would love to end up with.
Thanks a ton,
Andrea


> 
> From: andrea antonello <andrea.antone...@gmail.com>
> To: Commons Users List <user@commons.apache.org>
> Sent: Thursday, 26 April 2018 7:15 PM
> Subject: Re: [imaging] Comment tag problem
>
>
>
> Hi Bruno,
>
>> The EXIF tags in imaging should match what's in this page:
>> https://sno.phy.queensu.ca/~phil/exiftool/TagNames/EXIF.html
>>
>> Which cont

Re: [imaging] Comment tag problem

[Bruno P. Kinoshita]

Hi Andrea!

Today spent some minutes with Eclipse and the code base, plus exiftool, to see 
where that comment was coming from.

That COM, or Comment, that you see in exiftool output is not exactly a metadata 
tag. It is actually a JPEG Segment. Sorry for the other suggestions.

As far as I know, we are not able to change the segments, but only the metadata 
within the TIFF/EXIF directories & tags [2].

You can still use comments if that's OK, but not sure how you would achieve 
adding the Comment in Java.

Bruno


[1] http://u88.n24.queensu.ca/exiftool/forum/index.php?topic=3893.0
[2] https://issues.apache.org/jira/browse/IMAGING-55



From: andrea antonello <andrea.antone...@gmail.com>
To: Commons Users List <user@commons.apache.org> 
Sent: Thursday, 26 April 2018 8:02 PM
Subject: Re: [imaging] Comment tag problem



> I normally use exiftool to compare what imaging is producing. The htmldump is 
> quite useful.

I just ran the normal info extraction and here you see the comment I
would like to reproduce (Comment):

ExifTool Version Number : 10.94
File Name   : 109_Background.jpg
Directory   : .
File Size   : 428 kB
File Modification Date/Time : 2018:03:31 11:01:51+02:00
File Access Date/Time   : 2018:04:26 08:59:06+02:00
File Inode Change Date/Time : 2018:03:31 11:01:56+02:00
File Permissions: rw-rw-r--
File Type   : JPEG
File Type Extension : jpg
MIME Type   : image/jpeg
Comment :
GEO-Information,46.5640616313:11.523790723,46.5640616313:11.5093674258,46.5585048222:11.523790723,46.5585048222:11.5093674258,0.00
JFIF Version: 1.01
Resolution Unit : inches
X Resolution: 96
Y Resolution: 96
Image Width : 1608
Image Height: 901
Encoding Process: Baseline DCT, Huffman coding
Bits Per Sample : 8
Color Components: 3
Y Cb Cr Sub Sampling: YCbCr4:2:0 (2 2)
Image Size  : 1608x901
Megapixels  : 1.4


> I thought you had to create the tag in Java, but if you can use other tools 
> and it's easier for you, then that might be the best option.

Yes, I do have to recreate it in java. I was just trying to use other
tools to check what the comment tag is.
Do you have an idea on how to create the above Comment tag?

> Otherwise you can create pretty much any other metadata tag you'd like with 
> some Java coding.

That is what I would love to end up with.
Thanks a ton,
Andrea


> 
> From: andrea antonello <andrea.antone...@gmail.com>
> To: Commons Users List <user@commons.apache.org>
> Sent: Thursday, 26 April 2018 7:15 PM
> Subject: Re: [imaging] Comment tag problem
>
>
>
> Hi Bruno,
>
>> The EXIF tags in imaging should match what's in this page:
>> https://sno.phy.queensu.ca/~phil/exiftool/TagNames/EXIF.html
>>
>> Which contains the XPComment and UserComment tags you mentioned, but no 
>> equivalent to the other comment one.
>
> this is quite inetersting. Actually I have been told that the command:
>
> exiftool -comment='mycomment'
>
> creates exaclty the comment I am not able to reproduce. Do you know
> what that is?
>
>
>> If you really need to match that tag, then I think you should be able to 
>> create your own custom metadata entry.
>>
>> I think [1] the ExifRewriter and its test class have some code that shows 
>> how to rewrite metadata. Find the directory (TiffOutputDirectory.java) with 
>> the metadata fields, perhaps remove the UserComment/XPComment if necessary, 
>> and then add a new field (TiffOutputField.java), with your metadata tag 
>> (TagInfo.java)
>
> I will try again. I tried already that path, but since it asks me for
> a tag (integer) I then end up to have it named as the tag I am trying
> to substitute...
>
> Thanks,
> Andrea
>
>
>>
>>
>> Hope that helps,
>> Bruno
>>
>>
>> [1]
>> https://github.com/apache/commons-imaging/blob/master/src/main/java/org/apache/commons/imaging/formats/jpeg/exif/ExifRewriter.java
>>
>> 
>> From: andrea antonello <andrea.antone...@gmail.com>
>> To: Commons Users List <user@commons.apache.org>
>> Sent: Thursday, 26 April 2018 1:46 AM
>> Subject: Re: [imaging] Comment tag problem
>>
>>
>>
>> Hi Bruno,
>> thanks for your reply.
>>
>>> I think you tried to include screenshots? If so, it doesn't work very well 
>>> in this mailing list.
&g

Re: [imaging] Comment tag problem

[Martin Gainty]

that would work for embedding comment tag into images which conform to JPEG and 
TIFF formats


if your requirement includes embedding tag into GIF image format you will want 
to consider Adobe XMP
https://docs.oracle.com/cd/B19306_01/appdev.102/b14302/ch_metadata.htm

5 Working with Metadata in Images - 
Oracle<https://docs.oracle.com/cd/B19306_01/appdev.102/b14302/ch_metadata.htm>
docs.oracle.com
5 Working with Metadata in Images. Image files can contain information about 
the content of the images, the image rasters, and image metadata. In general, 
data about data is referred to as metadata.


HTH

Martin
___

From: Bruno P. Kinoshita <brunodepau...@yahoo.com.br.INVALID>
Sent: Thursday, April 26, 2018 2:57 AM
To: Commons Users List
Subject: Re: [imaging] Comment tag problem

Hi Andrea,

The EXIF tags in imaging should match what's in this page:
https://sno.phy.queensu.ca/~phil/exiftool/TagNames/EXIF.html
EXIF Tags - Queen's 
University<https://sno.phy.queensu.ca/~phil/exiftool/TagNames/EXIF.html>
sno.phy.queensu.ca
EXIF Tags. EXIF stands for "Exchangeable Image File Format". This type of 
information is formatted according to the TIFF specification, and may be found 
in JPG, TIFF, PNG, JP2, PGF, MIFF, HDP, PSP and XCF images, as well as many 
TIFF-based RAW images, and even some AVI and MOV videos.




Which contains the XPComment and UserComment tags you mentioned, but no 
equivalent to the other comment one.


If you really need to match that tag, then I think you should be able to create 
your own custom metadata entry.

I think [1] the ExifRewriter and its test class have some code that shows how 
to rewrite metadata. Find the directory (TiffOutputDirectory.java) with the 
metadata fields, perhaps remove the UserComment/XPComment if necessary, and 
then add a new field (TiffOutputField.java), with your metadata tag 
(TagInfo.java)


Hope that helps,
Bruno


[1]
https://github.com/apache/commons-imaging/blob/master/src/main/java/org/apache/commons/imaging/formats/jpeg/exif/ExifRewriter.java


From: andrea antonello <andrea.antone...@gmail.com>
To: Commons Users List <user@commons.apache.org>
Sent: Thursday, 26 April 2018 1:46 AM
Subject: Re: [imaging] Comment tag problem



Hi Bruno,
thanks for your reply.

> I think you tried to include screenshots? If so, it doesn't work very well in 
> this mailing list.


ohh, I didn't figure and didn't notice.

>
> Could you try adding as attachment, or upload them, or use plain text to 
> describe the issue? I recently had to work on the tags for some TIFF & JPEG 
> metadata in [imaging], so hopefully we will be able to locate the right tag.


Fantastic. I investigated further but am still not able to solve this.

The tag I would like to update is one that produces (at least this is
what I read in the imagemagick image info) a section

Properties:

and under start section I find

comment: 
GEO-Information,46.5640616313:11.523790723,46.5640616313:11.5093674258,46.5585048222:11.523790723,46.5585048222:11.5093674258,0.00

The most similar result I have been able to produce with the tags is:

exif:UserComment:GEO-Information,46.5640616313:11.523790723,46.5640616313:11.5093674258,46.5585048222:11.523790723,46.5585048222:11.5093674258,0.00

and

exif:WinXP-Comments:GEO-Information,46.5640616313:11.523790723,46.5640616313:11.5093674258,46.5585048222:11.523790723,46.5585048222:11.5093674258,0.00

both not the same as what i am looking for.


I have been able to print the following information through an
application called exifprobe:

@0x002=2   : length 137:
''GEO-Information,46.5640616313:11.523790723,46.5640616313:11.5093674258,46.5585048222:11.523790723,46.5585048222:11.5093674258,0.00\0''
@0x08d=141 : 0xffe0 length 16, 'JFIF'
@0x096=150 :  Version   = 1.1
@0x098=152 :  Units = 'dots/inch'
@0x099=153 :  Xdensity  = 96
@0x09b=155 :  Ydensity  = 96
@0x09d=157 :  XThumbnail= 0
@0x09e=158 :  YThumbnail= 0
@0x09e=158 :
@0x09f=159 : length 67
@0x0e4=228 : length 67
@0x129=297 : length 17, 8 bits/sample,
components=3, width=1608, height=901
@0x13c=316 : length 31 table class = 0 table id = 0
@0x15d=349 : length 181 table class = 0 table id = 1
@0x214=532 : length 31 table class = 1 table id = 0
@0x235=565 : length 181 table class = 1 table id = 1
@0x2ec=748 : length 12  start of JPEG data, 3
components 1448808 pixels
@0x006b1a4=438692  :   JPEG length 438694

So I think this (JPEG_COM) is not an exif tag as I had been told. I am
guessing this is reflected by the library's ComSegment class, but I
could not find any documentation or testcase which would tell me what
it is and how to rew

Re: [imaging] Comment tag problem

[andrea antonello]

> I normally use exiftool to compare what imaging is producing. The htmldump is 
> quite useful.

I just ran the normal info extraction and here you see the comment I
would like to reproduce (Comment):

ExifTool Version Number : 10.94
File Name   : 109_Background.jpg
Directory   : .
File Size   : 428 kB
File Modification Date/Time : 2018:03:31 11:01:51+02:00
File Access Date/Time   : 2018:04:26 08:59:06+02:00
File Inode Change Date/Time : 2018:03:31 11:01:56+02:00
File Permissions: rw-rw-r--
File Type   : JPEG
File Type Extension : jpg
MIME Type   : image/jpeg
Comment :
GEO-Information,46.5640616313:11.523790723,46.5640616313:11.5093674258,46.5585048222:11.523790723,46.5585048222:11.5093674258,0.00
JFIF Version: 1.01
Resolution Unit : inches
X Resolution: 96
Y Resolution: 96
Image Width : 1608
Image Height: 901
Encoding Process: Baseline DCT, Huffman coding
Bits Per Sample : 8
Color Components: 3
Y Cb Cr Sub Sampling: YCbCr4:2:0 (2 2)
Image Size  : 1608x901
Megapixels  : 1.4


> I thought you had to create the tag in Java, but if you can use other tools 
> and it's easier for you, then that might be the best option.

Yes, I do have to recreate it in java. I was just trying to use other
tools to check what the comment tag is.
Do you have an idea on how to create the above Comment tag?

> Otherwise you can create pretty much any other metadata tag you'd like with 
> some Java coding.

That is what I would love to end up with.
Thanks a ton,
Andrea


> 
> From: andrea antonello <andrea.antone...@gmail.com>
> To: Commons Users List <user@commons.apache.org>
> Sent: Thursday, 26 April 2018 7:15 PM
> Subject: Re: [imaging] Comment tag problem
>
>
>
> Hi Bruno,
>
>> The EXIF tags in imaging should match what's in this page:
>> https://sno.phy.queensu.ca/~phil/exiftool/TagNames/EXIF.html
>>
>> Which contains the XPComment and UserComment tags you mentioned, but no 
>> equivalent to the other comment one.
>
> this is quite inetersting. Actually I have been told that the command:
>
> exiftool -comment='mycomment'
>
> creates exaclty the comment I am not able to reproduce. Do you know
> what that is?
>
>
>> If you really need to match that tag, then I think you should be able to 
>> create your own custom metadata entry.
>>
>> I think [1] the ExifRewriter and its test class have some code that shows 
>> how to rewrite metadata. Find the directory (TiffOutputDirectory.java) with 
>> the metadata fields, perhaps remove the UserComment/XPComment if necessary, 
>> and then add a new field (TiffOutputField.java), with your metadata tag 
>> (TagInfo.java)
>
> I will try again. I tried already that path, but since it asks me for
> a tag (integer) I then end up to have it named as the tag I am trying
> to substitute...
>
> Thanks,
> Andrea
>
>
>>
>>
>> Hope that helps,
>> Bruno
>>
>>
>> [1]
>> https://github.com/apache/commons-imaging/blob/master/src/main/java/org/apache/commons/imaging/formats/jpeg/exif/ExifRewriter.java
>>
>> 
>> From: andrea antonello <andrea.antone...@gmail.com>
>> To: Commons Users List <user@commons.apache.org>
>> Sent: Thursday, 26 April 2018 1:46 AM
>> Subject: Re: [imaging] Comment tag problem
>>
>>
>>
>> Hi Bruno,
>> thanks for your reply.
>>
>>> I think you tried to include screenshots? If so, it doesn't work very well 
>>> in this mailing list.
>>
>>
>> ohh, I didn't figure and didn't notice.
>>
>>>
>>> Could you try adding as attachment, or upload them, or use plain text to 
>>> describe the issue? I recently had to work on the tags for some TIFF & JPEG 
>>> metadata in [imaging], so hopefully we will be able to locate the right tag.
>>
>>
>> Fantastic. I investigated further but am still not able to solve this.
>>
>> The tag I would like to update is one that produces (at least this is
>> what I read in the imagemagick image info) a section
>>
>> Properties:
>>
>> and under start section I find
>>
>> comment: 
>> GEO-Information,46.5640616313:11.523790723,46.5640616313:11.5093674258,46.5585048222:11.523790723,46.5585048222:11.5093674258,0.00
>>
>> T

Re: [imaging] Comment tag problem

[Bruno P. Kinoshita]

I normally use exiftool to compare what imaging is producing. The htmldump is 
quite useful. I thought you had to create the tag in Java, but if you can use 
other tools and it's easier for you, then that might be the best option.


Otherwise you can create pretty much any other metadata tag you'd like with 
some Java coding.

From: andrea antonello <andrea.antone...@gmail.com>
To: Commons Users List <user@commons.apache.org> 
Sent: Thursday, 26 April 2018 7:15 PM
Subject: Re: [imaging] Comment tag problem



Hi Bruno,

> The EXIF tags in imaging should match what's in this page:
> https://sno.phy.queensu.ca/~phil/exiftool/TagNames/EXIF.html
>
> Which contains the XPComment and UserComment tags you mentioned, but no 
> equivalent to the other comment one.

this is quite inetersting. Actually I have been told that the command:

exiftool -comment='mycomment'

creates exaclty the comment I am not able to reproduce. Do you know
what that is?


> If you really need to match that tag, then I think you should be able to 
> create your own custom metadata entry.
>
> I think [1] the ExifRewriter and its test class have some code that shows how 
> to rewrite metadata. Find the directory (TiffOutputDirectory.java) with the 
> metadata fields, perhaps remove the UserComment/XPComment if necessary, and 
> then add a new field (TiffOutputField.java), with your metadata tag 
> (TagInfo.java)

I will try again. I tried already that path, but since it asks me for
a tag (integer) I then end up to have it named as the tag I am trying
to substitute...

Thanks,
Andrea


>
>
> Hope that helps,
> Bruno
>
>
> [1]
> https://github.com/apache/commons-imaging/blob/master/src/main/java/org/apache/commons/imaging/formats/jpeg/exif/ExifRewriter.java
>
> 
> From: andrea antonello <andrea.antone...@gmail.com>
> To: Commons Users List <user@commons.apache.org>
> Sent: Thursday, 26 April 2018 1:46 AM
> Subject: Re: [imaging] Comment tag problem
>
>
>
> Hi Bruno,
> thanks for your reply.
>
>> I think you tried to include screenshots? If so, it doesn't work very well 
>> in this mailing list.
>
>
> ohh, I didn't figure and didn't notice.
>
>>
>> Could you try adding as attachment, or upload them, or use plain text to 
>> describe the issue? I recently had to work on the tags for some TIFF & JPEG 
>> metadata in [imaging], so hopefully we will be able to locate the right tag.
>
>
> Fantastic. I investigated further but am still not able to solve this.
>
> The tag I would like to update is one that produces (at least this is
> what I read in the imagemagick image info) a section
>
> Properties:
>
> and under start section I find
>
> comment: 
> GEO-Information,46.5640616313:11.523790723,46.5640616313:11.5093674258,46.5585048222:11.523790723,46.5585048222:11.5093674258,0.00
>
> The most similar result I have been able to produce with the tags is:
>
> exif:UserComment:GEO-Information,46.5640616313:11.523790723,46.5640616313:11.5093674258,46.5585048222:11.523790723,46.5585048222:11.5093674258,0.00
>
> and
>
> exif:WinXP-Comments:GEO-Information,46.5640616313:11.523790723,46.5640616313:11.5093674258,46.5585048222:11.523790723,46.5585048222:11.5093674258,0.00
>
> both not the same as what i am looking for.
>
>
> I have been able to print the following information through an
> application called exifprobe:
>
> @0x002=2   : length 137:
> ''GEO-Information,46.5640616313:11.523790723,46.5640616313:11.5093674258,46.5585048222:11.523790723,46.5585048222:11.5093674258,0.00\0''
> @0x08d=141 : 0xffe0 length 16, 'JFIF'
> @0x096=150 :  Version   = 1.1
> @0x098=152 :  Units = 'dots/inch'
> @0x099=153 :  Xdensity  = 96
> @0x09b=155 :  Ydensity  = 96
> @0x09d=157 :  XThumbnail= 0
> @0x09e=158 :  YThumbnail= 0
> @0x09e=158 :
> @0x09f=159 : length 67
> @0x0e4=228 : length 67
> @0x129=297 : length 17, 8 bits/sample,
> components=3, width=1608, height=901
> @0x13c=316 : length 31 table class = 0 table id = 0
> @0x15d=349 : length 181 table class = 0 table id = 1
> @0x214=532 : length 31 table class = 1 table id = 0
> @0x235=565 : length 181 table class = 1 table id = 1
> @0x2ec=748 : length 12  start of JPEG data, 3
> components 1448808 pixels
> @0x006b1a4=438692  :   JPEG length 438694
>
> So I think this (JPEG_COM) is not an exif tag as I had been told. I am
> guessing this is reflected by the library's ComSegment class, but I
>

Re: [imaging] Comment tag problem

[andrea antonello]

Hi Bruno,

> The EXIF tags in imaging should match what's in this page:
> https://sno.phy.queensu.ca/~phil/exiftool/TagNames/EXIF.html
>
> Which contains the XPComment and UserComment tags you mentioned, but no 
> equivalent to the other comment one.

this is quite inetersting. Actually I have been told that the command:

exiftool -comment='mycomment'

creates exaclty the comment I am not able to reproduce. Do you know
what that is?


> If you really need to match that tag, then I think you should be able to 
> create your own custom metadata entry.
>
> I think [1] the ExifRewriter and its test class have some code that shows how 
> to rewrite metadata. Find the directory (TiffOutputDirectory.java) with the 
> metadata fields, perhaps remove the UserComment/XPComment if necessary, and 
> then add a new field (TiffOutputField.java), with your metadata tag 
> (TagInfo.java)

I will try again. I tried already that path, but since it asks me for
a tag (integer) I then end up to have it named as the tag I am trying
to substitute...

Thanks,
Andrea


>
>
> Hope that helps,
> Bruno
>
>
> [1]
> https://github.com/apache/commons-imaging/blob/master/src/main/java/org/apache/commons/imaging/formats/jpeg/exif/ExifRewriter.java
>
> 
> From: andrea antonello <andrea.antone...@gmail.com>
> To: Commons Users List <user@commons.apache.org>
> Sent: Thursday, 26 April 2018 1:46 AM
> Subject: Re: [imaging] Comment tag problem
>
>
>
> Hi Bruno,
> thanks for your reply.
>
>> I think you tried to include screenshots? If so, it doesn't work very well 
>> in this mailing list.
>
>
> ohh, I didn't figure and didn't notice.
>
>>
>> Could you try adding as attachment, or upload them, or use plain text to 
>> describe the issue? I recently had to work on the tags for some TIFF & JPEG 
>> metadata in [imaging], so hopefully we will be able to locate the right tag.
>
>
> Fantastic. I investigated further but am still not able to solve this.
>
> The tag I would like to update is one that produces (at least this is
> what I read in the imagemagick image info) a section
>
> Properties:
>
> and under start section I find
>
> comment: 
> GEO-Information,46.5640616313:11.523790723,46.5640616313:11.5093674258,46.5585048222:11.523790723,46.5585048222:11.5093674258,0.00
>
> The most similar result I have been able to produce with the tags is:
>
> exif:UserComment:GEO-Information,46.5640616313:11.523790723,46.5640616313:11.5093674258,46.5585048222:11.523790723,46.5585048222:11.5093674258,0.00
>
> and
>
> exif:WinXP-Comments:GEO-Information,46.5640616313:11.523790723,46.5640616313:11.5093674258,46.5585048222:11.523790723,46.5585048222:11.5093674258,0.00
>
> both not the same as what i am looking for.
>
>
> I have been able to print the following information through an
> application called exifprobe:
>
> @0x002=2   : length 137:
> ''GEO-Information,46.5640616313:11.523790723,46.5640616313:11.5093674258,46.5585048222:11.523790723,46.5585048222:11.5093674258,0.00\0''
> @0x08d=141 : 0xffe0 length 16, 'JFIF'
> @0x096=150 :  Version   = 1.1
> @0x098=152 :  Units = 'dots/inch'
> @0x099=153 :  Xdensity  = 96
> @0x09b=155 :  Ydensity  = 96
> @0x09d=157 :  XThumbnail= 0
> @0x09e=158 :  YThumbnail= 0
> @0x09e=158 :
> @0x09f=159 : length 67
> @0x0e4=228 : length 67
> @0x129=297 : length 17, 8 bits/sample,
> components=3, width=1608, height=901
> @0x13c=316 : length 31 table class = 0 table id = 0
> @0x15d=349 : length 181 table class = 0 table id = 1
> @0x214=532 : length 31 table class = 1 table id = 0
> @0x235=565 : length 181 table class = 1 table id = 1
> @0x2ec=748 : length 12  start of JPEG data, 3
> components 1448808 pixels
> @0x006b1a4=438692  :   JPEG length 438694
>
> So I think this (JPEG_COM) is not an exif tag as I had been told. I am
> guessing this is reflected by the library's ComSegment class, but I
> could not find any documentation or testcase which would tell me what
> it is and how to rewrite/update it.
>
> Any help is most appreciated,
> Thanks,
>
> Andrea
>
>
>
>
>>
>> CheersBruno
>>
>>
>>   From: andrea antonello <andrea.antone...@gmail.com>
>>  To: Commons Users List <user@commons.apache.org>
>>  Sent: Wednesday, 25 April 2018 1:56 AM
>>  Subject: [imaging] Comment tag problem
>>
>> Hi, I need some help to find the right 

Re: [imaging] Comment tag problem

[Bruno P. Kinoshita]

Hi Andrea,

The EXIF tags in imaging should match what's in this page: 
https://sno.phy.queensu.ca/~phil/exiftool/TagNames/EXIF.html

Which contains the XPComment and UserComment tags you mentioned, but no 
equivalent to the other comment one.


If you really need to match that tag, then I think you should be able to create 
your own custom metadata entry.

I think [1] the ExifRewriter and its test class have some code that shows how 
to rewrite metadata. Find the directory (TiffOutputDirectory.java) with the 
metadata fields, perhaps remove the UserComment/XPComment if necessary, and 
then add a new field (TiffOutputField.java), with your metadata tag 
(TagInfo.java)


Hope that helps,
Bruno


[1] 
https://github.com/apache/commons-imaging/blob/master/src/main/java/org/apache/commons/imaging/formats/jpeg/exif/ExifRewriter.java


From: andrea antonello <andrea.antone...@gmail.com>
To: Commons Users List <user@commons.apache.org> 
Sent: Thursday, 26 April 2018 1:46 AM
Subject: Re: [imaging] Comment tag problem



Hi Bruno,
thanks for your reply.

> I think you tried to include screenshots? If so, it doesn't work very well in 
> this mailing list.


ohh, I didn't figure and didn't notice.

>
> Could you try adding as attachment, or upload them, or use plain text to 
> describe the issue? I recently had to work on the tags for some TIFF & JPEG 
> metadata in [imaging], so hopefully we will be able to locate the right tag.


Fantastic. I investigated further but am still not able to solve this.

The tag I would like to update is one that produces (at least this is
what I read in the imagemagick image info) a section

Properties:

and under start section I find

comment: 
GEO-Information,46.5640616313:11.523790723,46.5640616313:11.5093674258,46.5585048222:11.523790723,46.5585048222:11.5093674258,0.00

The most similar result I have been able to produce with the tags is:

exif:UserComment:GEO-Information,46.5640616313:11.523790723,46.5640616313:11.5093674258,46.5585048222:11.523790723,46.5585048222:11.5093674258,0.00

and

exif:WinXP-Comments:GEO-Information,46.5640616313:11.523790723,46.5640616313:11.5093674258,46.5585048222:11.523790723,46.5585048222:11.5093674258,0.00

both not the same as what i am looking for.


I have been able to print the following information through an
application called exifprobe:

@0x002=2   : length 137:
''GEO-Information,46.5640616313:11.523790723,46.5640616313:11.5093674258,46.5585048222:11.523790723,46.5585048222:11.5093674258,0.00\0''
@0x08d=141 : 0xffe0 length 16, 'JFIF'
@0x096=150 :  Version   = 1.1
@0x098=152 :  Units = 'dots/inch'
@0x099=153 :  Xdensity  = 96
@0x09b=155 :  Ydensity  = 96
@0x09d=157 :  XThumbnail= 0
@0x09e=158 :  YThumbnail= 0
@0x09e=158 :
@0x09f=159 : length 67
@0x0e4=228 : length 67
@0x129=297 : length 17, 8 bits/sample,
components=3, width=1608, height=901
@0x13c=316 : length 31 table class = 0 table id = 0
@0x15d=349 : length 181 table class = 0 table id = 1
@0x214=532 : length 31 table class = 1 table id = 0
@0x235=565 : length 181 table class = 1 table id = 1
@0x2ec=748 : length 12  start of JPEG data, 3
components 1448808 pixels
@0x006b1a4=438692  :   JPEG length 438694

So I think this (JPEG_COM) is not an exif tag as I had been told. I am
guessing this is reflected by the library's ComSegment class, but I
could not find any documentation or testcase which would tell me what
it is and how to rewrite/update it.

Any help is most appreciated,
Thanks,

Andrea




>
> CheersBruno
>
>
>   From: andrea antonello <andrea.antone...@gmail.com>
>  To: Commons Users List <user@commons.apache.org>
>  Sent: Wednesday, 25 April 2018 1:56 AM
>  Subject: [imaging] Comment tag problem
>
> Hi, I need some help to find the right tag to use to recreate a tag in a
> jpeg file.
>
> Here is the output of the info given by ImageMagick:
>
>
>
> The tag I need should be under "Properties"
> and be named: comment
>
> I have tried to use user_comment and xpcomment, but they produce something
> different, like:
>
>
>
> Can anyone tell me which tag I can use to generate the "comment" tag?
>
> Thanks for any hint,
> Best regards,
> Andrea
>
>
>

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [imaging] Comment tag problem

[andrea antonello]

Hi Bruno,
thanks for your reply.

> I think you tried to include screenshots? If so, it doesn't work very well in 
> this mailing list.


ohh, I didn't figure and didn't notice.

>
> Could you try adding as attachment, or upload them, or use plain text to 
> describe the issue? I recently had to work on the tags for some TIFF & JPEG 
> metadata in [imaging], so hopefully we will be able to locate the right tag.


Fantastic. I investigated further but am still not able to solve this.

The tag I would like to update is one that produces (at least this is
what I read in the imagemagick image info) a section

Properties:

and under start section I find

comment: 
GEO-Information,46.5640616313:11.523790723,46.5640616313:11.5093674258,46.5585048222:11.523790723,46.5585048222:11.5093674258,0.00

The most similar result I have been able to produce with the tags is:

exif:UserComment:GEO-Information,46.5640616313:11.523790723,46.5640616313:11.5093674258,46.5585048222:11.523790723,46.5585048222:11.5093674258,0.00

and

exif:WinXP-Comments:GEO-Information,46.5640616313:11.523790723,46.5640616313:11.5093674258,46.5585048222:11.523790723,46.5585048222:11.5093674258,0.00

both not the same as what i am looking for.


I have been able to print the following information through an
application called exifprobe:

@0x002=2   : length 137:
''GEO-Information,46.5640616313:11.523790723,46.5640616313:11.5093674258,46.5585048222:11.523790723,46.5585048222:11.5093674258,0.00\0''
@0x08d=141 : 0xffe0 length 16, 'JFIF'
@0x096=150 :  Version   = 1.1
@0x098=152 :  Units = 'dots/inch'
@0x099=153 :  Xdensity  = 96
@0x09b=155 :  Ydensity  = 96
@0x09d=157 :  XThumbnail= 0
@0x09e=158 :  YThumbnail= 0
@0x09e=158 :
@0x09f=159 : length 67
@0x0e4=228 : length 67
@0x129=297 : length 17, 8 bits/sample,
components=3, width=1608, height=901
@0x13c=316 : length 31 table class = 0 table id = 0
@0x15d=349 : length 181 table class = 0 table id = 1
@0x214=532 : length 31 table class = 1 table id = 0
@0x235=565 : length 181 table class = 1 table id = 1
@0x2ec=748 : length 12  start of JPEG data, 3
components 1448808 pixels
@0x006b1a4=438692  :   JPEG length 438694

So I think this (JPEG_COM) is not an exif tag as I had been told. I am
guessing this is reflected by the library's ComSegment class, but I
could not find any documentation or testcase which would tell me what
it is and how to rewrite/update it.

Any help is most appreciated,
Thanks,
Andrea




>
> CheersBruno
>
>
>   From: andrea antonello <andrea.antone...@gmail.com>
>  To: Commons Users List <user@commons.apache.org>
>  Sent: Wednesday, 25 April 2018 1:56 AM
>  Subject: [imaging] Comment tag problem
>
> Hi, I need some help to find the right tag to use to recreate a tag in a
> jpeg file.
>
> Here is the output of the info given by ImageMagick:
>
>
>
> The tag I need should be under "Properties"
> and be named: comment
>
> I have tried to use user_comment and xpcomment, but they produce something
> different, like:
>
>
>
> Can anyone tell me which tag I can use to generate the "comment" tag?
>
> Thanks for any hint,
> Best regards,
> Andrea
>
>
>

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [imaging] Comment tag problem

[Bruno P. Kinoshita]

Hi Andrea,
I think you tried to include screenshots? If so, it doesn't work very well in 
this mailing list. Could you try adding as attachment, or upload them, or use 
plain text to describe the issue? I recently had to work on the tags for some 
TIFF & JPEG metadata in [imaging], so hopefully we will be able to locate the 
right tag.
CheersBruno


  From: andrea antonello <andrea.antone...@gmail.com>
 To: Commons Users List <user@commons.apache.org> 
 Sent: Wednesday, 25 April 2018 1:56 AM
 Subject: [imaging] Comment tag problem
   
Hi, I need some help to find the right tag to use to recreate a tag in a
jpeg file.

Here is the output of the info given by ImageMagick:



The tag I need should be under "Properties"
and be named: comment

I have tried to use user_comment and xpcomment, but they produce something
different, like:



Can anyone tell me which tag I can use to generate the "comment" tag?

Thanks for any hint,
Best regards,
Andrea


   

[imaging] Comment tag problem

[andrea antonello]

Hi, I need some help to find the right tag to use to recreate a tag in a
jpeg file.

Here is the output of the info given by ImageMagick:



The tag I need should be under "Properties"
and be named: comment

I have tried to use user_comment and xpcomment, but they produce something
different, like:



Can anyone tell me which tag I can use to generate the "comment" tag?

Thanks for any hint,
Best regards,
Andrea

Re: [imaging] Apache Commons Imaging 1.0 final release ?

[Olivier Jaquemet]

Hi Bruno,

Thank for your feedback ! It's really nice to know there are still 
people actively using/working on the library.


To answer your help request ;
First a big disclaimer : I am not familiar with image processing in 
general, I have no knowledge of the Imaging API, and never coded with it 
yet.


That being said, just by looking at the issues in the bugtracker, all 
major bugs (specially parsing bugs leading to exceptions) would be the 
only things blocking a 1.0 release in my opinion.
If Imaging is mature and stable enough (is it from an API user 
perspective? I don't know yet), a 1.0 would be the most awaited feature 
:) (looking at the mailing list history also shows this expectation 
since quite a long time).
An official release with "just" bug fix, and *without* new major 
feature/improvement, would (probably) increase official adoption of the 
library, and would then be the base for future stronger feedback.


Olivier

On 28/08/2017 13:02, Bruno P. Kinoshita wrote:

Hello Olivier!
You are correct, no official release yet. Yet :)
Some days ago I spent some time working on a IIIF PoC with the Cantaloupe 
server, and decided to spend time working on commons-imaging to see what could 
be done to get a first release out.
I started triaging issues, but am far away of understanding the code base or 
understanding the current state of the project. I agree an initial release 
would be good, but I would like some good review to understand what should go 
in a 1.0 release, and what should maybe be removed or moved to a branch for a 
later release.
>From the initial triage, I found that there are some metadata issues with TIFF 
and JPEG that would impact the use of commons-imaging in IIIF. So I am planning to 
spend time on that in the next days.
Would you be interested or have time to help reviewing the current state of the 
project? Not necessarily jump and code if you don't have time, but maybe just 
provide feedback on which features you think **must** be in the 1.0 release, 
and if you found anything that would prevent this initial release.
CheersBruno

From: Olivier Jaquemet <olivier.jaque...@jalios.com>To: "user@commons.apache.org" 
<user@commons.apache.org>Sent: Monday, 28 August 2017, 9:11:08 PM NZSTSubject: [imaging] Apache 
Commons Imaging 1.0 final release ?
Hi imagers :)

As far I could find, no official release of
org.apache.commons/commons-imaging was ever published to maven.
I understand that the current snapshot build is stable and that previous
sanselan release are too.
That said, an official build would certainly increase confidence in the
library and lead to more adoption, don't you think ?

Do you plan to release version 1.0 of Apache Commons Imaging ?

Thanks,
Olivier

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org





-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [imaging] Apache Commons Imaging 1.0 final release ?

[Bruno P. Kinoshita]

Hello Olivier!
You are correct, no official release yet. Yet :)
Some days ago I spent some time working on a IIIF PoC with the Cantaloupe 
server, and decided to spend time working on commons-imaging to see what could 
be done to get a first release out.
I started triaging issues, but am far away of understanding the code base or 
understanding the current state of the project. I agree an initial release 
would be good, but I would like some good review to understand what should go 
in a 1.0 release, and what should maybe be removed or moved to a branch for a 
later release.
>From the initial triage, I found that there are some metadata issues with TIFF 
>and JPEG that would impact the use of commons-imaging in IIIF. So I am 
>planning to spend time on that in the next days.
Would you be interested or have time to help reviewing the current state of the 
project? Not necessarily jump and code if you don't have time, but maybe just 
provide feedback on which features you think **must** be in the 1.0 release, 
and if you found anything that would prevent this initial release.
CheersBruno

From: Olivier Jaquemet <olivier.jaque...@jalios.com>To: 
"user@commons.apache.org" <user@commons.apache.org>Sent: Monday, 28 August 
2017, 9:11:08 PM NZSTSubject: [imaging] Apache Commons Imaging 1.0 final 
release ?
Hi imagers :)

As far I could find, no official release of 
org.apache.commons/commons-imaging was ever published to maven.
I understand that the current snapshot build is stable and that previous 
sanselan release are too.
That said, an official build would certainly increase confidence in the 
library and lead to more adoption, don't you think ?

Do you plan to release version 1.0 of Apache Commons Imaging ?

Thanks,
Olivier

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

[imaging] Apache Commons Imaging 1.0 final release ?

[Olivier Jaquemet]

Hi imagers :)

As far I could find, no official release of 
org.apache.commons/commons-imaging was ever published to maven.
I understand that the current snapshot build is stable and that previous 
sanselan release are too.
That said, an official build would certainly increase confidence in the 
library and lead to more adoption, don't you think ?


Do you plan to release version 1.0 of Apache Commons Imaging ?

Thanks,
Olivier

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

[imaging] Apache Commons Imaging, for Android?

[Joakim Knudsen]

Hi all

I've been using "Sanselan v0.97" in my Android app, with some success.
After a lot of searching the web, reading the Exif 2.2 standard, and using
software like Phil Harvey's ExifTool, I seem to be able to read and write
EXIF and IPTC metadata to JPEG files on an Android device. However, there
are some bugs in this version, and I have since learned that Sanselan has
been moved from incubator and renamed to Apache Commons Imaging.

I'm now wondering whether I should move from Sanselan to Commons Imaging.
Does anyone have experince using Commons Imaging on Android?


Joakim

Fwd: imaging

[Eric David]

Dear sir,

I am currently using the Imaging Apache Common library in order to create
GeoTIFF images.

I succeeded to create the image and write the metadata in it
(ModelTiepointTag and ModelPixelScaleTag) but they seem not to be
recognized by GDAL or any other GIS Software. As a result my output image
is not georeferenced.

I was not able to solve that problem so far.

I attach to this mail the part of the script where I create the file. Could
you please tell me where is my mistake?

Here is the gdalinfo on the output image :

Driver: GTiff/GeoTIFF
> Files: \output.tif
> Size is 2340, 1654
> Coordinate System is `'
> Metadata:
>   TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch)
>   TIFFTAG_XRESOLUTION=72
>   TIFFTAG_YRESOLUTION=72
> Image Structure Metadata:
>   COMPRESSION=LZW
>   INTERLEAVE=PIXEL
> Corner Coordinates:
> Upper Left  (0.0,0.0)
> Lower Left  (0.0, 1654.0)
> Upper Right ( 2340.0,0.0)
> Lower Right ( 2340.0, 1654.0)
> Center  ( 1170.0,  827.0)
> Band 1 Block=2340x1 Type=Byte, ColorInterp=Red
> Band 2 Block=2340x1 Type=Byte, ColorInterp=Green
> Band 3 Block=2340x1 Type=Byte, ColorInterp=Blue



Best regards

-- 
*Eric DAVID*
06 83 22 61 96
private void writeGeoTiff(File imgFile, OutputImageFactory imageFactory) {

try {

// Create the geoMetadata
double[] modelTiePoint = new double[6];
modelTiePoint[3] = imageFactory.getPlan().getxOri();
modelTiePoint[4] = imageFactory.getPlan().getyOri();

double[] modelPixelScale = new double[3];
modelPixelScale[0] = 1 / imageFactory.getScaleX();
modelPixelScale[1] = 1 / imageFactory.getScaleY();

byte[] imageBytes = 
Imaging.writeImageToBytes(imageFactory.getOutputImage(), ImageFormats.TIFF,
new HashMap<>());

TiffImageMetadata metadata = (TiffImageMetadata) 
Imaging.getMetadata(imageBytes);

TiffOutputSet outputSet = null;
if (null != metadata) {
outputSet = metadata.getOutputSet();
}

if (null == outputSet) {
outputSet = new TiffOutputSet();
}


outputSet.getOrCreateExifDirectory().add(GeoTiffTagConstants.EXIF_TAG_MODEL_PIXEL_SCALE_TAG,
modelPixelScale);

outputSet.getOrCreateExifDirectory().add(GeoTiffTagConstants.EXIF_TAG_MODEL_TIEPOINT_TAG,
 modelTiePoint);

Map<String, Object> params = new HashMap<>();

params.put(ImagingConstants.PARAM_KEY_EXIF, outputSet);

Imaging.writeImage(imageFactory.getOutputImage(), imgFile, 
ImageFormats.TIFF, params);

} catch (IOException ioe) {
LoggerManager.debug(ioe);
} catch (ImageWriteException iwe) {
LoggerManager.debug(iwe);
} catch (ImageReadException ire) {
LoggerManager.debug(ire);
}

}
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [imaging]

[Siegfried Goeschl]

Hi Nikhil,

some thoughts along the line

* In 
https://github.com/sgoeschl/java-image-processing-survival-guide/tree/master/code/jipsg
 you find code resizing/resampling of images with a lot of open source libraries
* The library being used depends on the range of source images - how many image 
formats, image sources, etc.
* Stay clear of TIFF if possible and PDF scans - will cause endless grief
* Personally I would use https://github.com/haraldk/TwelveMonkeys and 
Thumbnailator 

Thanks in advance,

Siegfried Goeschl

Disclaimer: I’m sort of affiliated with the “TwelveMonkeys” library since 
Harald Kuhr (the creator of the library) is a friend of mine and we did a 
couple of presentations together



> On 6 Mar 2017, at 04:52, Nikhil <nikhilmac...@gmail.com> wrote:
> 
> Thanks Siegfried. Your github details are really good. It gave a lot of
> details but also confused me to find the optimal production ready approach
> for the problem. Could you pls. guide me here ?
> 
> Here are the few usecases that I have,
> 1. Convert JPEG to PNG either color or grayscale depending upon the source
> image color. (I believe I need utility to find the source image color e.g.
> if image is already B/W , Grayscale or Color )
> 2. Update metadata and also resize the image to new dpi e.g. if source
> image is 1200x1200 then upon conversion to PNG it should be 300x300 dpi
> with same physical size.
> 
> What would be best library to use for above usecases ? (I believe java
> imageIO should be good enough for these tasks...correct ?)
> What should be the steps to do above two usecases ?
> 
> Thanks for your help. Appreciate it a lot !
> 
> Thanks,
> Nikhil
> 
> 
> On Sun, Mar 5, 2017 at 8:53 AM, Siegfried Goeschl <
> siegfried.goes...@it20one.com> wrote:
> 
>> Hi Nikhil,
>> 
>> I do not know commons-image good enough to answer your questions but
>> 
>> * Do you mean changing the DPI value (metadata only) or resizing the image?
>> * While not related to Apache Commons Image the following link might help
>> - https://github.com/sgoeschl/java-image-processing-survival-guide <
>> https://github.com/sgoeschl/java-image-processing-survival-guide>
>> 
>> Thanks in advance,
>> 
>> Siegfried Goeschl
>> 
>> 
>>> On 3 Mar 2017, at 07:53, Nikhil <nikhilmac...@gmail.com> wrote:
>>> 
>>> Hi,
>>> 
>>> 
>>> 1. Does Commons Imaging support changing dpi of an image ? E.g. Changing
>>> 1200x1200 image (jpeg / png) to 300x300.
>>> 
>>>If yes, could you point me to a sample ?
>>> 
>>> 2. Can Image be converted to grayscale 4 bit or 8 bit using the Imaging
>> api
>>> ? If yes, could you point me to a sample ?
>>> 
>>> 
>>> Thanks,
>>> 
>>> Nikhil
>> 
>> 


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [imaging]

[Nikhil]

Thanks Siegfried. Your github details are really good. It gave a lot of
details but also confused me to find the optimal production ready approach
for the problem. Could you pls. guide me here ?

Here are the few usecases that I have,
1. Convert JPEG to PNG either color or grayscale depending upon the source
image color. (I believe I need utility to find the source image color e.g.
if image is already B/W , Grayscale or Color )
2. Update metadata and also resize the image to new dpi e.g. if source
image is 1200x1200 then upon conversion to PNG it should be 300x300 dpi
with same physical size.

What would be best library to use for above usecases ? (I believe java
imageIO should be good enough for these tasks...correct ?)
What should be the steps to do above two usecases ?

Thanks for your help. Appreciate it a lot !

Thanks,
Nikhil


On Sun, Mar 5, 2017 at 8:53 AM, Siegfried Goeschl <
siegfried.goes...@it20one.com> wrote:

> Hi Nikhil,
>
> I do not know commons-image good enough to answer your questions but
>
> * Do you mean changing the DPI value (metadata only) or resizing the image?
> * While not related to Apache Commons Image the following link might help
> - https://github.com/sgoeschl/java-image-processing-survival-guide <
> https://github.com/sgoeschl/java-image-processing-survival-guide>
>
> Thanks in advance,
>
> Siegfried Goeschl
>
>
> > On 3 Mar 2017, at 07:53, Nikhil <nikhilmac...@gmail.com> wrote:
> >
> > Hi,
> >
> >
> > 1. Does Commons Imaging support changing dpi of an image ? E.g. Changing
> > 1200x1200 image (jpeg / png) to 300x300.
> >
> > If yes, could you point me to a sample ?
> >
> > 2. Can Image be converted to grayscale 4 bit or 8 bit using the Imaging
> api
> > ? If yes, could you point me to a sample ?
> >
> >
> > Thanks,
> >
> > Nikhil
>
>

Re: [imaging]

[Siegfried Goeschl]

Hi Nikhil,

I do not know commons-image good enough to answer your questions but 

* Do you mean changing the DPI value (metadata only) or resizing the image? 
* While not related to Apache Commons Image the following link might help - 
https://github.com/sgoeschl/java-image-processing-survival-guide 
<https://github.com/sgoeschl/java-image-processing-survival-guide>

Thanks in advance,

Siegfried Goeschl


> On 3 Mar 2017, at 07:53, Nikhil <nikhilmac...@gmail.com> wrote:
> 
> Hi,
> 
> 
> 1. Does Commons Imaging support changing dpi of an image ? E.g. Changing
> 1200x1200 image (jpeg / png) to 300x300.
> 
> If yes, could you point me to a sample ?
> 
> 2. Can Image be converted to grayscale 4 bit or 8 bit using the Imaging api
> ? If yes, could you point me to a sample ?
> 
> 
> Thanks,
> 
> Nikhil

[imaging]

[Nikhil]

Hi,


1. Does Commons Imaging support changing dpi of an image ? E.g. Changing
1200x1200 image (jpeg / png) to 300x300.

 If yes, could you point me to a sample ?

2. Can Image be converted to grayscale 4 bit or 8 bit using the Imaging api
? If yes, could you point me to a sample ?


Thanks,

Nikhil

Re: [imaging] Changing compile baseline of library to JDK7

[Matt Sicker]

One problem with that is that Apache developers are generally not paid by
Oracle or others to extend support for Java 6 support in anything, so we
tend to stick to what is publicly supported instead. The publicly available
releases of Java 6 have been EOL for quite a while now. This is why a lot
of Apache projects have been migrating to Java 7 this year and last year.

As for preventing issues while building for Java 6 but using Java 7, I
believe you can specify a bootstrap classpath for the JDK so that the code
you compile is compiled against the JDK 6 classes while running in Java 7.
In Maven, there is the animal sniffer plugin which can fail your build if
you use any new classes or methods from JDK 7, and there's most likely a
similar plugin for Gradle.

On 12 October 2016 at 08:38, Thad Humphries <thad.humphr...@gmail.com>
wrote:

> On Wed, Oct 12, 2016 at 4:33 AM, sebb <seb...@gmail.com> wrote:
>
> > May I ask why a minium of Java 7 is a problem for some people?
> >
> > It would be useful to know this when considering other updates.
> >
>
> In my case, one of our oldest and largest customers--a Fortune 100
> company--is running Oracle WebLogic 10.3, which they purchase with Extended
> Support for Java SE 6. Oracle states that Extended Support for Java SE 6
> will be available December 2018 (
> http://www.oracle.com/technetwork/java/eol-135779.html). We have no
> indication that they will upgrade before then.
>
> Most of my development is with GWT using Gradle as my build tool. In
> addition to having to back out Commons Imaging, I am for now sticking with
> an older Gradle plugin for GWT because the alternative plugin also requires
> Java 7. I've found out the best way to avoid the accidental introduction of
> a Java 7 binary is to stick with Java 6 for the build environment, too.
>
>
> >
> > On 11 October 2016 at 17:10, Thad Humphries <thad.humphr...@gmail.com>
> > wrote:
> > > Yes. I've had to pull commons-imaging from my apps and replace it with
> > > JAI-IMAGEIO. JAI is old and unsupported, but its jar files still work
> > with
> > > Java 6. (There are also older versions of Twelve Monkeys that work with
> > > Java 6. https://github.com/haraldk/TwelveMonkeys)
> > >
> > > On Tue, Oct 11, 2016 at 11:38 AM, Sergio Matone <ser...@cedeo.net>
> > wrote:
> > >
> > >> I would like to express my disappoint since the library, which was
> > working
> > >> perfectly, is now compiled using Java 7 without issuing a version.
> > >>
> > >> I understand that the library is in SNAPSHOT, but why it wasn't issued
> > at
> > >> least a 1.0.0 version, tagging the Java 6 version.
> > >> You broke builds of several of my programs in production. That's not
> the
> > >> way Apache usually behaves.
> > >>
> > >> Sergio
> > >>
> > >
> > >
> > > --
> > > "Hell hath no limits, nor is circumscrib'd In one self-place; but where
> > we
> > > are is hell, And where hell is, there must we ever be" --Christopher
> > > Marlowe, *Doctor Faustus* (v. 121-24)
> >
> > -
> > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> > For additional commands, e-mail: user-h...@commons.apache.org
> >
> >
>
>
> --
> "Hell hath no limits, nor is circumscrib'd In one self-place; but where we
> are is hell, And where hell is, there must we ever be" --Christopher
> Marlowe, *Doctor Faustus* (v. 121-24)
>



-- 
Matt Sicker <boa...@gmail.com>

Re: [imaging] Changing compile baseline of library to JDK7

[Thad Humphries]

On Wed, Oct 12, 2016 at 4:33 AM, sebb <seb...@gmail.com> wrote:

> May I ask why a minium of Java 7 is a problem for some people?
>
> It would be useful to know this when considering other updates.
>

In my case, one of our oldest and largest customers--a Fortune 100
company--is running Oracle WebLogic 10.3, which they purchase with Extended
Support for Java SE 6. Oracle states that Extended Support for Java SE 6
will be available December 2018 (
http://www.oracle.com/technetwork/java/eol-135779.html). We have no
indication that they will upgrade before then.

Most of my development is with GWT using Gradle as my build tool. In
addition to having to back out Commons Imaging, I am for now sticking with
an older Gradle plugin for GWT because the alternative plugin also requires
Java 7. I've found out the best way to avoid the accidental introduction of
a Java 7 binary is to stick with Java 6 for the build environment, too.


>
> On 11 October 2016 at 17:10, Thad Humphries <thad.humphr...@gmail.com>
> wrote:
> > Yes. I've had to pull commons-imaging from my apps and replace it with
> > JAI-IMAGEIO. JAI is old and unsupported, but its jar files still work
> with
> > Java 6. (There are also older versions of Twelve Monkeys that work with
> > Java 6. https://github.com/haraldk/TwelveMonkeys)
> >
> > On Tue, Oct 11, 2016 at 11:38 AM, Sergio Matone <ser...@cedeo.net>
> wrote:
> >
> >> I would like to express my disappoint since the library, which was
> working
> >> perfectly, is now compiled using Java 7 without issuing a version.
> >>
> >> I understand that the library is in SNAPSHOT, but why it wasn't issued
> at
> >> least a 1.0.0 version, tagging the Java 6 version.
> >> You broke builds of several of my programs in production. That's not the
> >> way Apache usually behaves.
> >>
> >> Sergio
> >>
> >
> >
> > --
> > "Hell hath no limits, nor is circumscrib'd In one self-place; but where
> we
> > are is hell, And where hell is, there must we ever be" --Christopher
> > Marlowe, *Doctor Faustus* (v. 121-24)
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>
>


-- 
"Hell hath no limits, nor is circumscrib'd In one self-place; but where we
are is hell, And where hell is, there must we ever be" --Christopher
Marlowe, *Doctor Faustus* (v. 121-24)

Re: [imaging] Changing compile baseline of library to JDK7

[sebb]

May I ask why a minium of Java 7 is a problem for some people?

It would be useful to know this when considering other updates.

On 11 October 2016 at 17:10, Thad Humphries <thad.humphr...@gmail.com> wrote:
> Yes. I've had to pull commons-imaging from my apps and replace it with
> JAI-IMAGEIO. JAI is old and unsupported, but its jar files still work with
> Java 6. (There are also older versions of Twelve Monkeys that work with
> Java 6. https://github.com/haraldk/TwelveMonkeys)
>
> On Tue, Oct 11, 2016 at 11:38 AM, Sergio Matone <ser...@cedeo.net> wrote:
>
>> I would like to express my disappoint since the library, which was working
>> perfectly, is now compiled using Java 7 without issuing a version.
>>
>> I understand that the library is in SNAPSHOT, but why it wasn't issued at
>> least a 1.0.0 version, tagging the Java 6 version.
>> You broke builds of several of my programs in production. That's not the
>> way Apache usually behaves.
>>
>> Sergio
>>
>
>
> --
> "Hell hath no limits, nor is circumscrib'd In one self-place; but where we
> are is hell, And where hell is, there must we ever be" --Christopher
> Marlowe, *Doctor Faustus* (v. 121-24)

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [imaging] Changing compile baseline of library to JDK7

[Siegfried Goeschl]

Hi folks,

I think the latest version of TwelveMonkey supporting JDK 1.6 is 
http://search.maven.org/#artifactdetails%7Ccom.twelvemonkeys%7Ctwelvemonkeys%7C3.0.2%7Cpom
 
<http://search.maven.org/#artifactdetails|com.twelvemonkeys|twelvemonkeys|3.0.2|pom>

Cheers, 

Siegfried Goeschl

> On 11 Oct 2016, at 18:10, Thad Humphries <thad.humphr...@gmail.com> wrote:
> 
> Yes. I've had to pull commons-imaging from my apps and replace it with
> JAI-IMAGEIO. JAI is old and unsupported, but its jar files still work with
> Java 6. (There are also older versions of Twelve Monkeys that work with
> Java 6. https://github.com/haraldk/TwelveMonkeys)
> 
> On Tue, Oct 11, 2016 at 11:38 AM, Sergio Matone <ser...@cedeo.net> wrote:
> 
>> I would like to express my disappoint since the library, which was working
>> perfectly, is now compiled using Java 7 without issuing a version.
>> 
>> I understand that the library is in SNAPSHOT, but why it wasn't issued at
>> least a 1.0.0 version, tagging the Java 6 version.
>> You broke builds of several of my programs in production. That's not the
>> way Apache usually behaves.
>> 
>> Sergio
>> 
> 
> 
> -- 
> "Hell hath no limits, nor is circumscrib'd In one self-place; but where we
> are is hell, And where hell is, there must we ever be" --Christopher
> Marlowe, *Doctor Faustus* (v. 121-24)

Re: [imaging] Changing compile baseline of library to JDK7

[Thad Humphries]

Yes. I've had to pull commons-imaging from my apps and replace it with
JAI-IMAGEIO. JAI is old and unsupported, but its jar files still work with
Java 6. (There are also older versions of Twelve Monkeys that work with
Java 6. https://github.com/haraldk/TwelveMonkeys)

On Tue, Oct 11, 2016 at 11:38 AM, Sergio Matone <ser...@cedeo.net> wrote:

> I would like to express my disappoint since the library, which was working
> perfectly, is now compiled using Java 7 without issuing a version.
>
> I understand that the library is in SNAPSHOT, but why it wasn't issued at
> least a 1.0.0 version, tagging the Java 6 version.
> You broke builds of several of my programs in production. That's not the
> way Apache usually behaves.
>
> Sergio
>


-- 
"Hell hath no limits, nor is circumscrib'd In one self-place; but where we
are is hell, And where hell is, there must we ever be" --Christopher
Marlowe, *Doctor Faustus* (v. 121-24)

Re: [imaging] IptcBlock is not public

[sebb]

On 10 October 2016 at 19:26, Gupta, Tapan <tapan.gu...@washpost.com> wrote:
> We are using snapshot for commons-imaging.
> Today when we ran maven clean package we got new snapshot jar and we are now 
> getting below error
>
> org.apache.commons.imaging.formats.jpeg.iptc.IptcBlock is not public in 
> org.apache.commons.imaging.formats.jpeg.iptc; cannot be accessed from outside 
> package

Sorry, that was an error. Now fixed.
It looked like the class was not used outside the package.

Clearly the unit tests need enhancing.

> final List newBlocks = 
> metadata.photoshopApp13Data.getNonIptcBlocks();
> What is the alternative way to do above?
>
> 
> org.apache.commons
> commons-imaging
> 1.0-SNAPSHOT
> 

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

[imaging] Changing compile baseline of library to JDK7

[Sergio Matone]

I would like to express my disappoint since the library, which was 
working perfectly, is now compiled using Java 7 without issuing a version.


I understand that the library is in SNAPSHOT, but why it wasn't issued 
at least a 1.0.0 version, tagging the Java 6 version.
You broke builds of several of my programs in production. That's not the 
way Apache usually behaves.


Sergio

--
Sergio Matone
Cedeo.net
Torino - I


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

[imaging] IptcBlock is not public

[Gupta, Tapan]

We are using snapshot for commons-imaging.
Today when we ran maven clean package we got new snapshot jar and we are now 
getting below error

org.apache.commons.imaging.formats.jpeg.iptc.IptcBlock is not public in 
org.apache.commons.imaging.formats.jpeg.iptc; cannot be accessed from outside 
package

final List newBlocks = 
metadata.photoshopApp13Data.getNonIptcBlocks();
What is the alternative way to do above?


org.apache.commons
commons-imaging
1.0-SNAPSHOT

Re: [imaging] Unable to download the binary from any mirror or archive site.

[sebb]

On 6 October 2016 at 03:01, Justin Compson <justincomp...@yahoo.com> wrote:
> Understood that the code hasn't been released but I thought that users could 
> use the snapshot version?  I'm just trying to use the samples given and I'm 
> unable to even utilize the samples.

Snapshots are works in progress and may be in any state.
They are intended for developers who understand the restrictions,
limitations and risks.

> I don't recall where I got the source but I think it was here:
> https://github.com/apache/commons-imaging

That is a mirror of the current trunk, so is a work-in-progress and
may not even compile.

> I even tried the Sanselan version and was unable to get that working either.  
> Is there a place where I can get the binary version of either?  I've had 
> trouble with the import statements and then executing my test programs 
> primarily because of the taginfo class.

The Sanselan version is available from the Download link on the
Commons Imaging site which currently leads to

http://commons.apache.org/proper/commons-imaging/download_sanselan.cgi


> All I'm really trying to grab is camera make, and a few other things to 
> rename my images for personal sorting purposes and planned on using Imaging 
> as I've had other success with Apache libraries.

If you download the Sanselan source as well as the binary, it looks
like there are some samples in the test tree - there's one called
MetadataExample.java that might be suitable as a starting point.

Note that the Sanselan 0.97-incubating release is also available from
Maven Central.

> Thanks for any help.
>
> 
> On Wed, 10/5/16, sebb <seb...@gmail.com> wrote:
>
>  Subject: Re: [imaging] Unable to download the binary from any mirror or 
> archive site.
>  To: "Commons Users List" <user@commons.apache.org>, "Justin Compson" 
> <justincomp...@yahoo.com>
>  Date: Wednesday, October 5, 2016, 6:31 PM
>
>  On 27 September 2016 at
>  21:13, Justin Compson
>  <justincomp...@yahoo.com.invalid>
>  wrote:
>  > Hi,
>  >
>  > I'm trying to leverage the commons
>  imaging library but I'm unable to download the binary
>  from any mirror or archive site.
>
>  That's because the code has not yet been
>  released.
>
>  > I have found
>  some source files in other locations but I've been
>  unable to get them to work either.  I don't use an IDE,
>  I'm just using the command line in windows.
>  >
>  > I've been able to
>  successfully implement MySQL and fileuploader without issue
>  so I'm not sure what I'm doing wrong here.
>  >
>  > When I am able to
>  compile a project with what I believe is a valid .jar file
>  it still can't find all of the classes:
>
>  Where did you get the
>  source?
>
>  > Z:\Web Projects\Java
>  Code>java -cp . MetadataExample2
>  >
>  Error: A JNI error has occurred, please check your
>  installation and try again
>  > Exception in
>  thread "main" java.lang.NoClassDefFoundError:
>  org/apache/commons/imaging/formats/tiff/taginfos/TagInfo
>  > at
>  java.lang.Class.getDeclaredMethods0(Native Method)
>  > at
>  java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
>  > at
>  java.lang.Class.privateGetMethodRecursive(Class.java:3048)
>  > at
>  java.lang.Class.getMethod0(Class.java:3018)
>  > at
>  java.lang.Class.getMethod(Class.java:1784)
>  > at
>  sun.launcher.LauncherHelper.validateMainClass(LauncherHelper.java:544)
>  > at
>  sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:526)
>  > Caused by:
>  java.lang.ClassNotFoundException:
>  org.apache.commons.imaging.formats.tiff.taginfos.TagInfo
>  > at
>  java.net.URLClassLoader.findClass(URLClassLoader.java:381)
>  > at
>  java.lang.ClassLoader.loadClass(ClassLoader.java:424)
>  > at
>  sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
>  > at
>  java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>  > ... 7 more
>  >
>  > I'm convinced it
>  is just my jar file isn't setup right and I'd rather
>  use a compiled version than doing it on my own as I'm by
>  no means an expert.
>  >
>  > Please help!
>  >
>  > Thanks,
>  >
>  > Justin Compson
>  >
>  >
>  -
>  > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
>  > For additional commands, e-mail: user-h...@commons.apache.org
>  >
>

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [imaging] Unable to download the binary from any mirror or archive site.

[Justin Compson]

Understood that the code hasn't been released but I thought that users could 
use the snapshot version?  I'm just trying to use the samples given and I'm 
unable to even utilize the samples.

I don't recall where I got the source but I think it was here:
https://github.com/apache/commons-imaging

I even tried the Sanselan version and was unable to get that working either.  
Is there a place where I can get the binary version of either?  I've had 
trouble with the import statements and then executing my test programs 
primarily because of the taginfo class.

All I'm really trying to grab is camera make, and a few other things to rename 
my images for personal sorting purposes and planned on using Imaging as I've 
had other success with Apache libraries.

Thanks for any help.


On Wed, 10/5/16, sebb <seb...@gmail.com> wrote:

 Subject: Re: [imaging] Unable to download the binary from any mirror or 
archive site.
 To: "Commons Users List" <user@commons.apache.org>, "Justin Compson" 
<justincomp...@yahoo.com>
 Date: Wednesday, October 5, 2016, 6:31 PM
 
 On 27 September 2016 at
 21:13, Justin Compson
 <justincomp...@yahoo.com.invalid>
 wrote:
 > Hi,
 >
 > I'm trying to leverage the commons
 imaging library but I'm unable to download the binary
 from any mirror or archive site.
 
 That's because the code has not yet been
 released.
 
 > I have found
 some source files in other locations but I've been
 unable to get them to work either.  I don't use an IDE,
 I'm just using the command line in windows.
 >
 > I've been able to
 successfully implement MySQL and fileuploader without issue
 so I'm not sure what I'm doing wrong here.
 >
 > When I am able to
 compile a project with what I believe is a valid .jar file
 it still can't find all of the classes:
 
 Where did you get the
 source?
 
 > Z:\Web Projects\Java
 Code>java -cp . MetadataExample2
 >
 Error: A JNI error has occurred, please check your
 installation and try again
 > Exception in
 thread "main" java.lang.NoClassDefFoundError:
 org/apache/commons/imaging/formats/tiff/taginfos/TagInfo
 >         at
 java.lang.Class.getDeclaredMethods0(Native Method)
 >         at
 java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
 >         at
 java.lang.Class.privateGetMethodRecursive(Class.java:3048)
 >         at
 java.lang.Class.getMethod0(Class.java:3018)
 >         at
 java.lang.Class.getMethod(Class.java:1784)
 >         at
 sun.launcher.LauncherHelper.validateMainClass(LauncherHelper.java:544)
 >         at
 sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:526)
 > Caused by:
 java.lang.ClassNotFoundException:
 org.apache.commons.imaging.formats.tiff.taginfos.TagInfo
 >         at
 java.net.URLClassLoader.findClass(URLClassLoader.java:381)
 >         at
 java.lang.ClassLoader.loadClass(ClassLoader.java:424)
 >         at
 sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
 >         at
 java.lang.ClassLoader.loadClass(ClassLoader.java:357)
 >         ... 7 more
 >
 > I'm convinced it
 is just my jar file isn't setup right and I'd rather
 use a compiled version than doing it on my own as I'm by
 no means an expert.
 >
 > Please help!
 >
 > Thanks,
 >
 > Justin Compson
 >
 >
 -
 > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
 > For additional commands, e-mail: user-h...@commons.apache.org
 >
 

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [imaging] Unable to download the binary from any mirror or archive site.

[sebb]

On 27 September 2016 at 21:13, Justin Compson
<justincomp...@yahoo.com.invalid> wrote:
> Hi,
>
> I'm trying to leverage the commons imaging library but I'm unable to download 
> the binary from any mirror or archive site.

That's because the code has not yet been released.

> I have found some source files in other locations but I've been unable to get 
> them to work either.  I don't use an IDE, I'm just using the command line in 
> windows.
>
> I've been able to successfully implement MySQL and fileuploader without issue 
> so I'm not sure what I'm doing wrong here.
>
> When I am able to compile a project with what I believe is a valid .jar file 
> it still can't find all of the classes:

Where did you get the source?

> Z:\Web Projects\Java Code>java -cp . MetadataExample2
> Error: A JNI error has occurred, please check your installation and try again
> Exception in thread "main" java.lang.NoClassDefFoundError: 
> org/apache/commons/imaging/formats/tiff/taginfos/TagInfo
> at java.lang.Class.getDeclaredMethods0(Native Method)
> at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
> at java.lang.Class.privateGetMethodRecursive(Class.java:3048)
> at java.lang.Class.getMethod0(Class.java:3018)
> at java.lang.Class.getMethod(Class.java:1784)
> at 
> sun.launcher.LauncherHelper.validateMainClass(LauncherHelper.java:544)
> at 
> sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:526)
> Caused by: java.lang.ClassNotFoundException: 
> org.apache.commons.imaging.formats.tiff.taginfos.TagInfo
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> ... 7 more
>
> I'm convinced it is just my jar file isn't setup right and I'd rather use a 
> compiled version than doing it on my own as I'm by no means an expert.
>
> Please help!
>
> Thanks,
>
> Justin Compson
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

[imaging] Unable to download the binary from any mirror or archive site.

[Justin Compson]

Hi,

I'm trying to leverage the commons imaging library but I'm unable to download 
the binary from any mirror or archive site.  

I have found some source files in other locations but I've been unable to get 
them to work either.  I don't use an IDE, I'm just using the command line in 
windows.

I've been able to successfully implement MySQL and fileuploader without issue 
so I'm not sure what I'm doing wrong here.

When I am able to compile a project with what I believe is a valid .jar file it 
still can't find all of the classes:
Z:\Web Projects\Java Code>java -cp . MetadataExample2
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.NoClassDefFoundError: 
org/apache/commons/imaging/formats/tiff/taginfos/TagInfo
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
at java.lang.Class.privateGetMethodRecursive(Class.java:3048)
at java.lang.Class.getMethod0(Class.java:3018)
at java.lang.Class.getMethod(Class.java:1784)
at 
sun.launcher.LauncherHelper.validateMainClass(LauncherHelper.java:544)
at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:526)
Caused by: java.lang.ClassNotFoundException: 
org.apache.commons.imaging.formats.tiff.taginfos.TagInfo
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 7 more

I'm convinced it is just my jar file isn't setup right and I'd rather use a 
compiled version than doing it on my own as I'm by no means an expert.

Please help!

Thanks,

Justin Compson

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

[Imaging][TIFF]- Out Of Memory Heap issue while getting BufferedImage for a High Resolution Tiff image

[Ashok Panghal]

Hi

Attached [0] is a tiff file of size 18 MB in compressed form which inflates
to ~ 3 GB in uncompressed state.It is a high resolution image with width >
18000 px and height > 47000 px, so while using TiffImageParser it results
into outofmemory error when it tries to allocate space for pixel raster
data in a two-dimensional array in memory in ImageBuilder.java [1].
Can someone points me to an approach or further optimization to avoid heap
issues while dealing with high res tiff images. Heap issue not seen if Heap
size increased to 8 GB or so but that's not very scalable solution for
other more high res images we have almost 5 times bigger than this sample
image.

-Ashok
[0]
https://www.dropbox.com/s/xgey5orhkr2ax6q/wpf150903A.TIF?oref=e=301327099
[1]
https://github.com/apache/commons-imaging/blob/trunk/src/main/java/org/apache/commons/imaging/common/ImageBuilder.java#L78

Re: [Imaging] 1.0 Release Date?

[Benedikt Ritter]

Hi,

the main problem blocking a release ATM is the massive amount of findbugs
and PMD violations. Lot's of them probably require breaking changes to the
API, that's why we currently don't want to release it in the current state.

I've come to the conclusion that this may not be the best way to develop
the library. Maybe we should release it in the current state and then
simply push out major releases, breaking the API more often. Without a
official release, we won't attract many contributors...

just my 2 cents.
Benedikt

2015-10-28 1:44 GMT+01:00 Gary Gregory :

> Hi,
>
> There is no release date planned ATM. This is all based on volunteers being
> willing to put in the time to push this through.
>
> Gary
>
> On Tue, Oct 27, 2015 at 2:49 AM, Schalk Cronjé  wrote:
>
> > Hi folks,
> >
> > I am sure this questions has been asked before, I am just wondering if
> > there is any 1.0 release planned?
> >
> > Or is it better to stick to 0.9.7?
> >
> >
> > --
> > Schalk W. Cronjé
> > Twitter / Ello / Toeter : @ysb33r
> >
> >
> > -
> > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> > For additional commands, e-mail: user-h...@commons.apache.org
> >
> >
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>



-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

[imaging] Creating multipage tiff

[Ranjan, Ravi]

Hello Team,

I am newbie to Imaging and i am trying to create a multipage tif file from a 
list of tif files using below set of steps:


1.   Say I have two tif files.

2.   I created a TiffOutputSet

3.   Created two TiffOutputDirectory objects with type as 
DIRECTORY_TYPE_DIR_0 and DIRECTORY_TYPE_DIR_1.

4.   Filled above objects with TiffImageData from source tifs.

5.   Added both the directories to TiffOutputSet object.

6.   Wrote this to OutputStream using:

new TiffImageWriterLossy().write(os, outputSet);

Is this how I am supposed to get a multipage tif or is there a better and short 
method.
Please let me know in case sample code is required.

Thanks,
Ravi Ranjan

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.

[Imaging] 1.0 Release Date?

[Schalk Cronjé]

Hi folks,

I am sure this questions has been asked before, I am just wondering if 
there is any 1.0 release planned?


Or is it better to stick to 0.9.7?


--
Schalk W. Cronjé
Twitter / Ello / Toeter : @ysb33r


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [Imaging] 1.0 Release Date?

[Gary Gregory]

Hi,

There is no release date planned ATM. This is all based on volunteers being
willing to put in the time to push this through.

Gary

On Tue, Oct 27, 2015 at 2:49 AM, Schalk Cronjé  wrote:

> Hi folks,
>
> I am sure this questions has been asked before, I am just wondering if
> there is any 1.0 release planned?
>
> Or is it better to stick to 0.9.7?
>
>
> --
> Schalk W. Cronjé
> Twitter / Ello / Toeter : @ysb33r
>
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [Imaging] a quick resize sample needed

[Siegfried Goeschl]

Hi folks,

on GitHub I have sample code to resize images using different libraries

* ImageIO
* Thumbnailator
* TwelveMonkeys

https://github.com/sgoeschl/java-image-processing-survival-guide/tree/master/code/jipsg
 
https://github.com/sgoeschl/java-image-processing-survival-guide/tree/master/code/jipsg

Cheers,

Siegfried Goeschl

 On 16 Jun 2015, at 19:45, Thad Humphries thad.humphr...@gmail.com wrote:
 
 Do you necessarily need to use this library? There are other solutions
 (Google java resize image). For example
 
 http://www.codejava.net/java-se/graphics/how-to-resize-images-in-java
 -- or --
 http://www.thebuzzmedia.com/software/imgscalr-java-image-scaling-library/
 
 On Tue, Jun 16, 2015 at 5:32 AM, javalishixml javalishi...@163.com wrote:
 
 Hi Gurus,
 
 
 Quite a silly question this is. But I really worked for one whole day but
 still could not get any result.
 
 
 I have below codes. I just want to finish a a simple function to resize
 the original picture. But I don't know how to set  its param..
 I tried to read the doc API and read the test code. But I still could not
 figure it out how to do..
 
 
 Can you plz do me a favor? Looking forward to your early reply...
 
 
 
 
 
 --
 public class ApacheCommonImaging {
 public static void main(String[] args) {
 // TODO Auto-generated method stub
 
 
 try
 {
 //!!
 File someFile = new File(E:\\deleteMe\\image\\original.jpg);
 File file = someFile;
 BufferedImage image_3 = Sanselan.getBufferedImage(file);
 File destination = new
 File(E:\\deleteMe\\image\\commonImaging\\destination.jpg);
 ImageFormat format1 = ImageFormat.IMAGE_FORMAT_JPEG;
 Map params = new HashMap(Object, Object);   //
 Map params = new HashMap(JpegImageParser.TIFF_TAG_IMAGE_LENGTH, new
 TagInfo()); //
 Sanselan.writeImage(image_3, destination, format1, params);
 
 
 }
 catch (Exception e)
 {
 
 
 }
 }
 
 
 }
 
 --
 
 
 
 
 -- 
 Hell hath no limits, nor is circumscrib'd In one self-place; but where we
 are is hell, And where hell is, there must we ever be --Christopher
 Marlowe, *Doctor Faustus* (v. 121-24)

Re: [Imaging] a quick resize sample needed

[Thad Humphries]

Do you necessarily need to use this library? There are other solutions
(Google java resize image). For example

http://www.codejava.net/java-se/graphics/how-to-resize-images-in-java
-- or --
http://www.thebuzzmedia.com/software/imgscalr-java-image-scaling-library/

On Tue, Jun 16, 2015 at 5:32 AM, javalishixml javalishi...@163.com wrote:

 Hi Gurus,


 Quite a silly question this is. But I really worked for one whole day but
 still could not get any result.


 I have below codes. I just want to finish a a simple function to resize
 the original picture. But I don't know how to set  its param..
 I tried to read the doc API and read the test code. But I still could not
 figure it out how to do..


 Can you plz do me a favor? Looking forward to your early reply...





 --
 public class ApacheCommonImaging {
 public static void main(String[] args) {
 // TODO Auto-generated method stub


 try
 {
 //!!
 File someFile = new File(E:\\deleteMe\\image\\original.jpg);
 File file = someFile;
 BufferedImage image_3 = Sanselan.getBufferedImage(file);
 File destination = new
 File(E:\\deleteMe\\image\\commonImaging\\destination.jpg);
 ImageFormat format1 = ImageFormat.IMAGE_FORMAT_JPEG;
 Map params = new HashMap(Object, Object);   //
 Map params = new HashMap(JpegImageParser.TIFF_TAG_IMAGE_LENGTH, new
 TagInfo()); //
 Sanselan.writeImage(image_3, destination, format1, params);


 }
 catch (Exception e)
 {


 }
 }


 }

 --




-- 
Hell hath no limits, nor is circumscrib'd In one self-place; but where we
are is hell, And where hell is, there must we ever be --Christopher
Marlowe, *Doctor Faustus* (v. 121-24)

Re:Re: [Imaging] a quick resize sample needed

[javalishixml]

Thank you all.
Actually, I'm writting the resize function in Java using the different libraries
Apache Common Imaging is one of my libraries. I tried to use it, but it looks 
like too little of tutorial to how-to

Can anyone help me on this Apache Common Imaging library?



Thanks,
LS

At 2015-06-17 02:06:42, Siegfried Goeschl siegfried.goes...@it20one.com 
wrote:
Hi folks,

on GitHub I have sample code to resize images using different libraries

* ImageIO
* Thumbnailator
* TwelveMonkeys

https://github.com/sgoeschl/java-image-processing-survival-guide/tree/master/code/jipsg
 
https://github.com/sgoeschl/java-image-processing-survival-guide/tree/master/code/jipsg

Cheers,

Siegfried Goeschl

 On 16 Jun 2015, at 19:45, Thad Humphries thad.humphr...@gmail.com wrote:
 
 Do you necessarily need to use this library? There are other solutions
 (Google java resize image). For example
 
 http://www.codejava.net/java-se/graphics/how-to-resize-images-in-java
 -- or --
 http://www.thebuzzmedia.com/software/imgscalr-java-image-scaling-library/
 
 On Tue, Jun 16, 2015 at 5:32 AM, javalishixml javalishi...@163.com wrote:
 
 Hi Gurus,
 
 
 Quite a silly question this is. But I really worked for one whole day but
 still could not get any result.
 
 
 I have below codes. I just want to finish a a simple function to resize
 the original picture. But I don't know how to set  its param..
 I tried to read the doc API and read the test code. But I still could not
 figure it out how to do..
 
 
 Can you plz do me a favor? Looking forward to your early reply...
 
 
 
 
 
 --
 public class ApacheCommonImaging {
 public static void main(String[] args) {
 // TODO Auto-generated method stub
 
 
 try
 {
 //!!
 File someFile = new File(E:\\deleteMe\\image\\original.jpg);
 File file = someFile;
 BufferedImage image_3 = Sanselan.getBufferedImage(file);
 File destination = new
 File(E:\\deleteMe\\image\\commonImaging\\destination.jpg);
 ImageFormat format1 = ImageFormat.IMAGE_FORMAT_JPEG;
 Map params = new HashMap(Object, Object);   //
 Map params = new HashMap(JpegImageParser.TIFF_TAG_IMAGE_LENGTH, new
 TagInfo()); //
 Sanselan.writeImage(image_3, destination, format1, params);
 
 
 }
 catch (Exception e)
 {
 
 
 }
 }
 
 
 }
 
 --
 
 
 
 
 -- 
 Hell hath no limits, nor is circumscrib'd In one self-place; but where we
 are is hell, And where hell is, there must we ever be --Christopher
 Marlowe, *Doctor Faustus* (v. 121-24)

[Imaging] a quick resize sample needed

[javalishixml]

Hi Gurus,


Quite a silly question this is. But I really worked for one whole day but still 
could not get any result.


I have below codes. I just want to finish a a simple function to resize the 
original picture. But I don't know how to set  its param.. 
I tried to read the doc API and read the test code. But I still could not 
figure it out how to do..


Can you plz do me a favor? Looking forward to your early reply...




--
public class ApacheCommonImaging {
public static void main(String[] args) {
// TODO Auto-generated method stub


try
{
//!!
File someFile = new File(E:\\deleteMe\\image\\original.jpg);
File file = someFile;
BufferedImage image_3 = Sanselan.getBufferedImage(file);
File destination = new 
File(E:\\deleteMe\\image\\commonImaging\\destination.jpg);
ImageFormat format1 = ImageFormat.IMAGE_FORMAT_JPEG;
Map params = new HashMap(Object, Object);   //
Map params = new HashMap(JpegImageParser.TIFF_TAG_IMAGE_LENGTH, new TagInfo()); 
//
Sanselan.writeImage(image_3, destination, format1, params);


}
catch (Exception e)
{


}
}


}
--