For the size of file with which I typically deal - nominally 20 MB (5472 x 3648 pixel pictures) - it took about 5 hours to read one image. I'm looking to do better than this by a factor of 1000. I'll take a look at the pure J approach to get an idea if this is feasible.
On Sun, Apr 19, 2015 at 11:41 PM, bill lam <[email protected]> wrote: > I made a patch to accept both APP0 and APP1, but did not attempt > to process any APP1 specific tags. That said, szies of jpeg from > DC or mobile phones are typically a few MB. It may take many > hours to decode with pure J if Qt is unavailable. > > Вс, 19 апр 2015, Raul Miller написал(а): > > Oh, yeah... I was just reading about that the other day: > > > > http://en.wikipedia.org/wiki/JPEG_File_Interchange_Format#Compatibility > > > > http://en.wikipedia.org/wiki/JPEG#JPEG_files > > > > http://fileformats.archiveteam.org/wiki/JPEG#Portability > > > > But then I got bogged down in the details of the huffman coding and never > > really did get around to figuring out anything that might be useful for > > decoding the APP1 stuff that cameras tend to emit. > > > > It might be interesting, though, to take a look at one of these files and > > figure out at least enough of what they are doing to figure out how to > make > > the readjpeg code happy. > > > > But without an example to work from, I useful progress might be > difficult. > > Everything I read suggests that jpeg is not so much a standard as a bunch > > of slightly incompatible standards with ad-hoc practices that tend to > work > > but which necessarily do things outside the scope of the standards. > > > > Thanks, > > > > -- > > Raul > > > > > > On Sun, Apr 19, 2015 at 8:22 PM, bill lam <[email protected]> wrote: > > > > > I think isjpeg checked for APP0 marker (JFIF -: 74 70 73 70 {a.) > > > > http://www.fileformat.info/format/jpeg/egff.htm > > > > > > Apparently your jpeg use APP1 instead. (Exif -: 69 120 105 > > > 102{a.) which pure J jpeg decoder does not support. > > > > > > Anyways I guess Qt should be capable of handling all these formats. > > > On Apr 20, 2015 7:35 AM, "Devon McCormick" <[email protected]> wrote: > > > > > > > Here is my kluge to accommodate the header my .jpgs have: > > > > > > > > isJpeg0_jjpeg_=: 4 : 0 > > > > *./ +./x +./ . = 0 1 2 3 6 7 8 9 10 { a.&i.^:(2=3!:0) 11{.y > > > > ) > > > > isJpeg_jjpeg_=: (255 216 255 224 74 70 73 70 0,:255 216 255 225 69 > 120 > > > 105 > > > > 102 0)&isJpeg0_jjpeg_ > > > > > > > > The imagemagick idea is no good - I'm dealing w/hundreds of files > per day > > > > and have a nice J process that was working well w/.jpgs until the > attempt > > > > to move to J8 broke it. I may have to go back to the old, > unsupported > > > > methods. > > > > > > > > > > > > On Sun, Apr 19, 2015 at 6:38 PM, bill lam <[email protected]> > wrote: > > > > > > > > > Please provide details how it failed to detect a vaild jpeg file, > eg > > > > which > > > > > 9 bytes it read and what should be the 11 bytes. > > > > > > > > > > jpeg addon should automatically use Qt if available. Otherwise it > use > > > > pure > > > > > J scripts. > > > > > > > > > > You could also use platimg or image3 addons of J602, however they > are > > > no > > > > > longer maintained. > > > > > On Apr 20, 2015 3:26 AM, "Devon McCormick" <[email protected]> > wrote: > > > > > > > > > > > All - > > > > > > > > > > > > I find my efforts to move fully onto J8 stymied by the inadequate > > > > support > > > > > > for .JPG image files in the jpeg addon. When I attempt to read > a > > > > valid > > > > > > file that can be read properly by at least 2 other applications, > I > > > get > > > > > the > > > > > > error "invalid JPEG file". The proximate cause of this error is > a > > > zero > > > > > > returned by "isJpeg" which is checking for 9 of the first 11 > bytes of > > > > my > > > > > > file to have specific values. > > > > > > > > > > > > I can kluge this to accept the headers of the files it's > currently > > > > > > rejecting but, in any case, this version of "readjpeg" is > > > > excruciatingly > > > > > > slow: it takes about 30 seconds to read in a file that's well > under > > > > 300K. > > > > > > > > > > > > Does anyone have any ideas for alternatives to the existing J8 > jpeg > > > > > > reader? I'd prefer not to continue to use the old J7 gtk-based > ones > > > > but > > > > > > see no other way for now. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Devon > > > > > > > > > > > > -- > > > > > > Devon McCormick, CFA > > > > > > > > > ---------------------------------------------------------------------- > > > > > > For information about J forums see > > > http://www.jsoftware.com/forums.htm > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > For information about J forums see > http://www.jsoftware.com/forums.htm > > > > > > > > > > > > > > > > > > > > > -- > > > > Devon McCormick, CFA > > > > > ---------------------------------------------------------------------- > > > > For information about J forums see > http://www.jsoftware.com/forums.htm > > > > > > > ---------------------------------------------------------------------- > > > For information about J forums see http://www.jsoftware.com/forums.htm > > > > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > > -- > regards, > ==================================================== > GPG key 1024D/4434BAB3 2008-08-24 > gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3 > gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3 > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > -- Devon McCormick, CFA ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
