Re: tcllib jpeg package and JPEG comments ...

There is no limitation on what may appear in a comment chunk. The jpeg
fields are specified by byte length so there isnt even an ending
sequence to be careful of. I think it would be incorrect for the jpeg
module to not return the exact contents of the field, including nulls.

I think your problem could be handled with a simple string map:

set comments [string map {\r\n \n \r \n \x00 ""} [jpeg::getComments
$file]]

it would also be possible to remove all non ascii characters with a
regsub.


On May 30, 4:03 am, "MartinLemburg@UGS" <martin.lemburg....@xxxxxxx>
wrote:
Hello Uwe,

sorry, but I'm on MS Windows XP and have no running X Server to use
the XV for NT.

But I tried to examine what's going on with different applications
able to read/write JPEG comments.

1. using the utility jhead - depending on the data written to the
comment, the comment can contain any of the line end combinations like
\r\n, \n, or \r. jhead only reads and writes the first comment block.

2. using Exifer - Exifer always uses \r\n (like normal on MS Windows)
and reads/modifies only the last comment block

3. using IrfanView - IrfanView uses \r as line end, reads all comment
blocks, but modifies only the first without removing the other blocks
and appends a \0 at the end

So using the jpeg package to read comments is not necessarily the best
not knowing the comment writing application.
While it's no problem to deal with line ends, the problems are raised
by something like the \0 at the comments end or by the existence of
multiple comment blocks, where only one may be is most current -
depending on the software used to write the comments.

Perhabs it is a good enhancement for the jpeg package to deal inside
with the line ends and probably non-printable characters inside the
comments?
Or are binary comments allowed? I don't think so.

Best regards,

Martin Lemburg
----



Uwe Klein wrote:
MartinLemburg@UGS wrote:
Hello again,

I went now experimenting the other way, writing comments with the jpeg
package like this:

% package require jpeg
0.3
% puts '[jpeg::getComments $fileName]'
''
% jpeg::addComment $fileName "abc"
% jpeg::addComment $fileName "def"
% puts '[jpeg::getComments $fileName]'
'abc def'

Then I opened the JPEG file with IrfanView, saved the non-changed
comment and reread the comment inside the tcl shell:

% puts '[jpeg::getComments $fileName]'
def } def'
% puts '[string map {"\r" "\n"} [jpeg::getComments $fileName]]'
'{abc
def } def'
% scan [string index [lindex [jpeg::getComments $fileName] 0] end]
%c
0

I know, that IrfanView may handle the comments in a wrong way, but
currently I don't have any other bitmap application allowing to view
or to change the JPEG comments!

Can somebody help?

What platform? unix/cygwin:
you can try with rd|wrjpegcom from the jpeg package
---> http://www.ijg.org/files/
xv can display the comments as well.
--->http://www.trilon.com/xv/

this might be of interest:
http://netzreport.googlepages.com/hidden_data_in_jpeg_files.html

uwe- Hide quoted text -

- Show quoted text -


.

Relevant Pages

  • Re: tcllib jpeg package and JPEG comments ...
    ... using IrfanView - IrfanView uses \r as line end, ... So using the jpeg package to read comments is not necessarily the best ... 'abc def' ...
    (comp.lang.tcl)
  • Re: tcllib jpeg package and JPEG comments ...
    ... I went now experimenting the other way, writing comments with the jpeg ... % package require jpeg ... 'abc def' ... Then I opened the JPEG file with IrfanView, ...
    (comp.lang.tcl)
  • Re: tcllib jpeg package and JPEG comments ...
    ... That's the way I already deal with the JPEG comments returned from the ... if an application like IrfanView changes the ... 2,...,n th comment chunk. ... 'abc def' ...
    (comp.lang.tcl)
  • Re: tcllib jpeg package and JPEG comments ...
    ... I went now experimenting the other way, writing comments with the jpeg ... % package require jpeg ... 'abc def' ... I used IrfanView to put a comment to a JPEG file and afterwards I used ...
    (comp.lang.tcl)
  • Re: JPEG to PDF... lost of qualty
    ... The text itself is meaningless new age gibberish, but the JPEG encoding ... But the IrfanView solution isn't optimal if you actually know "a priori" ...
    (rec.photo.digital)