Issue 323 in cocotron: LZW TIFF support warning on webpage/source
codesite...@google.com
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 323 by Mat...@customcraftcreations.com: LZW TIFF support warning
on webpage/source
http://code.google.com/p/cocotron/issues/detail?id=323
After debugging my app for quite some time, trying to figure out why the
images for my IB
buttons weren't loading properly, I finally discovered it was because the
LZW compression
support for reading TIFF images is commented out.
There are no notes to this effect, but I can only guess it is to avoid
licensing issues with the LZW
algorithm.
I don't want to argue one way or another with that fact, but it would be
nice if there was either a
place on the website (a 'common issues' page, maybe?) where the lack of LZW
TIFF support
would be mentioned, or at least a better description in the code.
As an addendum, there is a (rather terse) NSLog message printed for this
error. However, it was
only after considerable digging that I found that such messages get printed
to the application
event queue, which is not exactly an easy place for finding error messages,
particularly for
debugging. Is there a way of rerouting NSLog messages to stdout so they
print out on the
console when launching from the command line? That would make debugging
considerably
easier. Thank you!
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
codesite...@google.com
Status: Started
Comment #1 on issue 323 by cocotron: LZW TIFF support warning on
webpage/source
http://code.google.com/p/cocotron/issues/detail?id=323
LZW decoding just hasn't been implemented yet, there are no other reason
for not doing it. The GIF decoder
implements it, myself or someone just needs to take the time to do it for
TIFF. The image format reading support
is somewhat limited in general and needs more work, if people have specific
needs please make issues for them.
If you add -mconsole to your "Other Linker Flags" you'll get all NSLog's in
a console window.
Andy Balholm
I have my debug build configuration set up with -mconsole in the Other
Linker Flags build setting. The app runs with a console window open,
and NSLog messages show up there. Have you tried that setting yet?
Andy Balholm
(509) 276-9718
an...@balholm.com
Markus Hitter
> The image format reading support is somewhat limited in general and
> needs more work
Wouldn't it be a good idea to import external libraries for such
things? Instead of tweaking the original libs to fit The Cocotron I'd
leave them as an untouched copy in the repository and write wrappers
to get them working. This has the advantage to make it easy to follow
updates, reinventing the wheel each time is a lot of work.
I'm thinking about libraries like libjpeg <http://www.ijg.org/files/
README>, ICU <http://site.icu-project.org/> and others with a BSD-
compatible license.
Supreme Cocotron Committee
I don't mind wrappers for external libraries as long as they are done
in a manner such that the library is strictly optional. I don't want
to create direct link dependancies on libraries which are not part of
a base OS install and force developers to include libraries they don't
use. This would involve some sort of plug-in/dynamic loading mechanism
in these subsystems that allows a developer to include the library in
their release or not, if it's there it's used, if not, the fallback
behavior is reasonable.
There are some pieces which at this point have to be wrapped such as
mDNS. Some others most likely, libxml and ICU (at least for regex's in
predicates). I don't mind image format wrappers but they have to be
optional and co-exist with the built-in ones. In some systems I
personally would rather spend time working on an implementation but I
completely understand people do want to release software and building
wrappers is fast.
So, if you want to add this, feel free, just don't make it a hard
dependancy. I'm thinking maybe build the wrappers in bundles and we
could have some sort of dependancy checks in Cocotron which loads the
bundles or not automatically ? Or get the CFBundle API's working as
they have function lookup calls in them, and use them?
Chris
Alexei Svitkine
any different than just having the code in Cocotron (from end user's
perspectives)? From the developer's perspective, they can just be
installed as part of CDT.
I think any effort spent re-implementing standard stuff such as image
decoders from scratch is wasted, as a library can be used instead
(wrapped) and that same development effort could be better spent
elsewhere on Cocotron (there are still a lot of places that need
work).
-Alexei
On Jul 5, 10:43 am, Supreme Cocotron Committee <cocot...@gmail.com>
wrote:
Markus Hitter
Am 05.07.2009 um 20:24 schrieb Alexei Svitkine:
> If the libraries get linked-in statically into Cocotron, how is
> that any different than just having the code in Cocotron
This is what I actually had in mind. I agree with Cris and you(?) on
requiring prerequisites at runtime is a bad idea.
While looking around in Cocotron's CoreGraphics (to fix image
stretching), I found it is based on OpenVG 1.0.1, but modified for
Obj-C. Updating OpenVG to the more recent 1.1 seems almost impossible
now, short of a rewrite. This is why I proposed wrappers.
Markus
Supreme Cocotron Committee
On Jul 5, 2:24 pm, Alexei Svitkine <Alexei.Svitk...@gmail.com> wrote:
> If the libraries get linked-in statically into Cocotron, how is that
> any different than just having the code in Cocotron (from end user's
> perspectives)? From the developer's perspective, they can just be
> installed as part of CDT.
build time so one could include or exclude it as they wish.
> I think any effort spent re-implementing standard stuff such as image
> decoders from scratch is wasted, as a library can be used instead
> (wrapped) and that same development effort could be better spent
> elsewhere on Cocotron (there are still a lot of places that need
> work).
implementation, so it depends on where you want to spend your time. I
personally don't want to work on wrapping image decode/encode, I'll
continue to work on the builtin implementations, but if someone else
does that is fine with me. There are some things I am interested in
wrapping, so I am not against it.
Chris
Supreme Cocotron Committee
On Jul 5, 5:19 pm, Markus Hitter <m...@jump-ing.de> wrote:
> While looking around in Cocotron's CoreGraphics (to fix image
> stretching), I found it is based on OpenVG 1.0.1, but modified for
> Obj-C. Updating OpenVG to the more recent 1.1 seems almost impossible
> now, short of a rewrite. This is why I proposed wrappers.
the basis for CoreGraphics is not suitable for use in it's original
state. The original reference implementation is meant as a guide/
sample for hardware vendors, it's not something you could drop in an
app and use, it's very abstract and really really slow. I decided to
use it as the basis for the CoreGraphics rasterizer and put a _lot_ of
effort into it so far to make it reasonably fast and work more like
CoreGraphics than OpenVG. OpenVG 1.1 is just a spec. at this point, I
don't believe the reference implementation has been updated and if it
has there really isn't anything new of use.
Chris